Hi Rohit,

Rohit (@.) on 2/25/11 wrote:
---------------------------
>>What you're describing is tile-based deferred rendering (TBDR). This approach is
>>used by PowerVR's architectures (as you mention below), but hasn't proven to be
>>the silver bullet for high-end GPU scaling. The problem is that while storing frame
>>buffer tiles on-chip is easy, you also need vast amounts of gradient and rasterization
>>data. You can't afford to re-process primitives for every tile.
>
>You do realize that both swiftshader and LRB1.0 use a variant of tile-based rendering, don't you?

I'm the lead developer of SwiftShader. I know the techniques it uses.

The first iteration of Larrabee's driver may have used tile-based rendering, but there's no telling what it will use once it hits the consumer market. That's the beauty of a software renderer. It can use whatever approach works best, and even switch between them dynamically.

That said, you didn't address the gradient and coverage data storage issue.

>>What you're forgetting is that local data is accessed a lot more often. For ever
>>pixel written to DRAM, the shader probably accessed several hundred registers and
>>accessed a dozen textures. So just saving the power consumption of writing the pixel
>>to DRAM doesn't save you much. Especially when you consider that it requires additional
>>on-die storage and thus lowers the compute density, saving power by reducing performance
>doesn't seem that useful to me.
>>
>
>Having local data saves BW, saves power and reduces effective latency. So it is
>VERY useful if it increases perf/W/mm on the whole. We don't need more flops, we
>need better flops. Which is why better local storage is the future.

Effective performance is the product of theoretical FLOPS and efficiency. You can't neglect one or the other. In any case continuing to add more or faster (larger) local storage is not the answer.

A GPU advances the program counter roughly 100 times slower than a CPU. To compensate for that it runs thousands of strands, but that means it needs 100 times more storage for the same task. As the tasks get bigger and more complex, that's just not feasible. Note for instance that the Fermi architecture has a stack of 1 kB per strand, while a CPU typically uses a stack of 1 MB.

And it's not just the code kernels getting more complex, the data parallelism isn't increasing as fast as the theoretical FLOPS. This means even more storage is required for task parallelism.

You don't want the majority of the chip to consist of storage, just so you can stick to the same architecture. Instead, the storage needs can be dramatically reduced by making sure the program counter can be advanced more quickly. This requires things like a bypass network and out-of-order execution. While that may sound expensive, we're approaching the point where it's cheaper than requiring 100 times more storage to complete the tasks efficiently. NVIDIA already went superscalar.

>>>The PowerVR graphics chip in the iPhone is a tile engine, as opposed to the ATI/NVidia stream engines.
>>>Tile engines are the future, today streaming is faster/simpler/easier if you can afford the power cost.
>>>(The PowerVR tile engine has some serious flaws, its not the future yet.)
>>
>>What makes you think that PowerVR's architecture can be scaled into a high-end
>>GPU, and the "serious flaws" are actually fixable? Note that Direct3D 11 has tesselation
>>so you need a way to manage a lot of geometry. I don't see TBDR going anywhere.
>I would love to be proven wrong though.
>
>Actually, almost every programmer I have spoken with seems to think, for whatever
>reason, that tile based rendering is the future.

Could you please ask them for the solution of the gradient and coverage data storage issue?

Thanks,

Nicolas