By: Simon Farnsworth (simon.delete@this.farnz.org.uk), August 1, 2016 4:00 am
Room: Moderated Discussions
Gionatan Danti (g.danti.delete@this.assyoma.it) on August 1, 2016 3:20 am wrote:
> Dan (dzhang50.delete@this.hotmail.com) on August 1, 2016 3:12 am wrote:
> > David Kanter (dkanter.delete@this.realworldtech.com) on August 1, 2016 12:01 am wrote:
> > > This is my first new article in a while, but its a treat. It's the first video I've done for the site.
> > >
> > > Starting with the Maxwell and Pascal architectures, Nvidia high-performance GPUs use tile-based
> > > immediate-mode rasterizers, instead of conventional full-screen immediate-mode rasterizers. Using
> > > simple DirectX shaders, we demonstrate the tile-based rasterization in Nvidia's Maxwell and Pascal
> > > GPUs and contrast this behavior to the immediate-mode rasterizer used by AMD.
> > >
> > > http://www.realworldtech.com/tile-based-rasterization-nvidia-gpus/
> > >
> > > I look forward to the discussion.
> > >
> > > David
> >
> > What are the pros/cons to using tile-based rasterizers vs. conventional rasterizers?
> > Tile-based seems to be more power efficient, but what's the tradeoff?
>
> The problem with tile based deferred rendering is that both applications
> and APIs are really meant for immediate mode rendering.
>
> In other word, you (as a graphic company) need to invest massive amount of work/money
> in a software driver capable of hiding the chip's deferred nature in a manner that
> do not break classical application (read: without visual artifact).
>
How does Vulkan change this? ImgTec say it makes Vulkan and PowerVR a much better fit than OpenGL ES was; their claims summarize down to:
1. Most dynamic state stored in explicit pipeline objects available at shader compile time; no need to consider which state affects the shader binaries.
2. Explicit synchronization enables them to easily tile geometry while they're waiting for the previous rasterization run to complete; if that's not safe, there's a primitive to stall geometry handling while they wait for rasterization.
3. Ahead of time command buffer construction allows them to reorder commands in a buffer to match tiles, so that submission time has very little work to do. Plus, because of threading support, command buffers can be prepared in a background thread, thus not blocking the rendering.
4.Render passes disallow unpredictable flushing on tilers - and describe the memory visibility of pass inputs and outputs. Thus, you can avoid flushing out the parts of tile memory that aren't needed by later passes (saving memory bandwidth), and you can avoid having to flush mid-pass.
My gut instinct is that all of them hold true for tilers, and 1, 2, 3 are all beneficial to immediate mode renderers, too, but I'm sufficiently ignorant that my gut instinct could be completely wrong.
> Dan (dzhang50.delete@this.hotmail.com) on August 1, 2016 3:12 am wrote:
> > David Kanter (dkanter.delete@this.realworldtech.com) on August 1, 2016 12:01 am wrote:
> > > This is my first new article in a while, but its a treat. It's the first video I've done for the site.
> > >
> > > Starting with the Maxwell and Pascal architectures, Nvidia high-performance GPUs use tile-based
> > > immediate-mode rasterizers, instead of conventional full-screen immediate-mode rasterizers. Using
> > > simple DirectX shaders, we demonstrate the tile-based rasterization in Nvidia's Maxwell and Pascal
> > > GPUs and contrast this behavior to the immediate-mode rasterizer used by AMD.
> > >
> > > http://www.realworldtech.com/tile-based-rasterization-nvidia-gpus/
> > >
> > > I look forward to the discussion.
> > >
> > > David
> >
> > What are the pros/cons to using tile-based rasterizers vs. conventional rasterizers?
> > Tile-based seems to be more power efficient, but what's the tradeoff?
>
> The problem with tile based deferred rendering is that both applications
> and APIs are really meant for immediate mode rendering.
>
> In other word, you (as a graphic company) need to invest massive amount of work/money
> in a software driver capable of hiding the chip's deferred nature in a manner that
> do not break classical application (read: without visual artifact).
>
How does Vulkan change this? ImgTec say it makes Vulkan and PowerVR a much better fit than OpenGL ES was; their claims summarize down to:
1. Most dynamic state stored in explicit pipeline objects available at shader compile time; no need to consider which state affects the shader binaries.
2. Explicit synchronization enables them to easily tile geometry while they're waiting for the previous rasterization run to complete; if that's not safe, there's a primitive to stall geometry handling while they wait for rasterization.
3. Ahead of time command buffer construction allows them to reorder commands in a buffer to match tiles, so that submission time has very little work to do. Plus, because of threading support, command buffers can be prepared in a background thread, thus not blocking the rendering.
4.Render passes disallow unpredictable flushing on tilers - and describe the memory visibility of pass inputs and outputs. Thus, you can avoid flushing out the parts of tile memory that aren't needed by later passes (saving memory bandwidth), and you can avoid having to flush mid-pass.
My gut instinct is that all of them hold true for tilers, and 1, 2, 3 are all beneficial to immediate mode renderers, too, but I'm sufficiently ignorant that my gut instinct could be completely wrong.