TBDR\\IMR Based GPU Achitecture Topic

predaking

从Function角度来说，TBDR可以更好的做到Depth Peeling

从Performance角度来说TBDR可以比IMR更好的避免无效的PS启动，也可以比Explicity Early-z Culling更好的避免无效的VS启动

从Gate Count以及Transistor Cost角度来说，TBDR可以避免Hierarchical Z和Z Compression/Decompression等复杂的ROP逻辑。


为什么现在的Graphics Card都不用TBDR呢？Texture Cache的Data Locality问题？还是PS启动时候Shader Program过多？还是因为Sort-middle的时候Bandwidth过大？等等？

Edison

兼容性问题呀，现在的很多游戏和应用都是 IMR-based 的，在 TBDR 上难免出现一些问题。

还有成本问题， TBDR 大都需要一块不小的片上 buffer。

predaking

这倒是，Synchronization和lock会使得TBDR失效，不得不退回到IMR方式，使得Performance大幅降低。这个问题在GMX里就已经体现出来了，那个还仅仅是Zone Rendering，还不是TBDR……

不过这就是给SW工程师惯坏了~ Application就不应该那么写。

predaking

SW工程是实在是大脑积水，不给用TBDR自己却费尽去做Deferred Shading……而且Second Pass的时候还必须得做Shader Program Merge，有的时候还Merge不了。……

Asuka

AMD下一代mobile芯片就是TBDR的

面对现在的怪物高端，这个玩意带给设计者的优势似乎是更容易做到更好的能效比

predaking

所有的高功耗都是由于Memory Access的Latency引起的~~ 如何优化这个，是如何获得Low Power的关键~~

TBDR只是个权宜之计，通过避免无效的PS能节约一定Power，但是不能根本上解决Latency引起的power问题。

AMD的那个有文章么，推荐以下？或者谈谈 “这个玩意带给设计者的优势似乎是更容易做到更好的能效比” ？？

predaking

兼容性问题呀，现在的很多游戏和应用都是 IMR-based 的，在 TBDR 上难免出现一些问题。

还有成本问题， TBDR 大都需要一块不小的片上 buffer。
Edison 发表于 2009-3-9 17:52

那个Tile base Frame Buffer on chip总计算下来比Early-z还有Zbuffer cache、 Colorbuffer Cache要节省很多Gate Count。 而且HW Design/Verification的成本都要节省很多，SW那边成本会增加，不过还好~~

predaking

这是老外给出来的解释，欢迎继续探讨

The problem with this deferred rendering approach is the fact that the entire scene must be cached before rendering. This "scene buffer" effectively takes the place of the z-buffer. The objection I have to this approach is that the size of the scene buffer is unknown before rendering, and so there are always going to be possible buffer overflow issues which could drastically impact performance. By contrast, the z-buffer's size is well-known prior to rendering. Immediate-mode renderers (pretty much any GPU available today) also have a number of techniques that improve efficiency, so I don't see a reason to go "all the way" to deferred rendering to solve problems that, in my mind, don't really need solving given today's rendering performance

predaking

上面说Scenebuffer是有可能Overflow，我认为这个是个别的极端情况。比如现在的IMR Applicaiton都是针对IMR声明的Texture Resource，而如果Driver要做Tile base Rendering，那有可能在一个Tile内的Triangle需要访问超过Video memory的Texture，从而Overflow。这个对性能影响是很大，这个问题估计会同样困扰着LRB。不过好在LRB有大于4G的 Video Memory。

predaking

通过切割Tile，我想还是可以解决的~~ 。不过这种Overflow情况应该不常见吧，一个Tile本身就很小了，而且只启动Visible Fragment的PS，应改用不到太多的Texture Resource~~

不过话说回来。假如有人要在PS里做RT之类的变态行为，那除了Application Engineer以外，谁也帮不上忙~~

Edison

不仅仅是纹理的问题吧，三角形的 binning 本身就可能需要几遍，这就需要若干倍于 IMR 方式的空间、带宽。

predaking

这个实际上就相当一个Index Triangle Fetch的意思，不会特别占用很多的Memory Addr Spaces，而且根据LRB Paper，大多数Triangle会被包含在一个Binning内，具体数据我忘了，可以查一下。至于Bandwidth，还是比IMR要节省很多的，这包括depth/stencil/Color Read&Write以及Unvisible Texture Fetch等等。而且Binning可以支持Brust Transfer

predaking

AMD的我看了下，那个只能算是TBR不能算是TBDR，因为每次Tile计算的时候VS都要从新计算。
http://ati.amd.com/developer/gdc ... e_TileBasedGpus.pdf