Nicolas Capens (nicolas.capens@gmail.com) on 2/23/11 wrote:
---------------------------
>Brett (ggtgp@yahoo.com) on 2/20/11 wrote:
>---------------------------
>>Nicolas Capens (nicolas.capens@gmail.com) on 2/19/11 wrote:
>>---------------------------
>>>Brett (ggtgp@yahoo.com) on 2/17/11 wrote:
>>>---------------------------
>>>>Today yes, that is looking true, but the RAM is moving on chip, bandwidth is about to explode by 1,000 times.
>>>>An Intel CPU with 1,000 times the bandwidth would only be twice as fast, the ATI
>>>>chip will become a ~hundred times faster.
>>>
>>The difference is that a GPU would tile this RAM per pipeline to multiply the bandwidth,
>>and get you the 1000 times bandwidth for 1000 pipelines.
>
>One problem with that is you also need 1000 memory controllers. For comparison,
>a GTX 580 has 6 x 64-bit memory controllers, which take up considerable die space.
>Even though eDRAM controllers can be somewhat smaller because they don't need the
>high power to go off-chip, they still need deep buffers to handle requests for the duration of the latency.

I am talking about adding a 4k to 16k local memory to each ATI pipeline. (Think Cell.)
Which of course would be running at L1 cache speeds.
Not much benefit to moving centralized bulk RAM on chip, as we both agree.

>>If you are smart (and ATI/NVidia are) you only need about one meg that is streamed.
>
>What do you mean by streaming? Going off-chip again? How is that different from
>today, with GPUs having ~1 MB of cache memory?

The bottleneck in graphics is that 100 megs of frame buffers in DRAM,
and the fact that most of those values are temporary,
and have no need to be purged to main DRAM.

The video out circuit only needs the end result frame buffer in DRAM.
(Soon it will also need the zbuffer for 3D, but that is just peanuts times two.)

Just 4k used for 8x8 tiles gives you 16 frame buffers.
Enough so you can work on two full tile sets at once, as one may be stalled.
A quad pipeline vector would compute all results to completion in the
local cache and the only write to DRAM would be the end result frame tile.

1600 pixels high divided by 8 means 200 quad pipelines for a single vertical slice.
You really need at least 4 wide due to sharing bottlenecks.

The big problem is full screen effects like blur that need data from neighboring tiles.
Each tile processor would be told who the 8 neighbors are, as they are allocated.
So each tile engine can make a direct request for data, and set up a
Cell like request early, and stall if not available in time.

Note that 4k times 800 quad pipelines is only 3 megs of RAM.
Fits with ease on any die that could hold 32,000 pipelines.
External DRAM bandwidth needs drop from 100+ megs to 16, even for my 30 inch display.

More realistically you would add a 4 meg global buffer on die so you could get by with only 4,000 pipelines.
The global buffer would hold ~128x128 intermediate tiles.
External bandwidth to DRAM still drops to the same 16 megs.

Things like generated shadow maps either go to the global buffer, or all the way out to DRAM.
Textures still come from DRAM, a shadow map is a texture.

There is a Stanford talk on the limits of power, 10 picowatts(?) for a register read cost as much as an FPU operation, 100 pW for L1 read, 1000 pW for L3 read, 10,000 pW for DRAM read.

Local data gives you orders of magnitude power reduction.
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.)