Re-post from the other thread, since it's really much more appropriate here:
Now that I've actually finished reading it, there's a lot of interesting tidbits in there. It still leaves me with a bunch of questions though.
ESRAM is fully integrated into our page tables and so you can kind of mix and match the ESRAM and the DDR memory as you go
This confirms that the ESRAM is absolutely not a cache but a developer-controlled scratchpad, which renders the Intel 32MiB EDRAM cache size arguments irrelevant.
"If you're only doing a read you're capped at 109GB/s, if you're only doing a write you're capped at 109GB/s," he says. "To get over that you need to have a mix of the reads and the writes but when you are going to look at the things that are typically in the ESRAM, such as your render targets and your depth buffers, intrinsically they have a lot of read-modified writes going on in the blends and the depth buffer updates. Those are the natural things to stick in the ESRAM and the natural things to take advantage of the concurrent read/writes."
This still doesn't really explain it to me. Unless there's some special purpose hardware there that can do a read-modify-write on the ESRAM side the of the 1024-bit bus, there's just no way to send more than 1024-bits per cycle, which tops out at 109GB/s at 853MHz.
"Everybody knows from the internet that going to 14 CUs should have given us almost 17 per cent more performance," he says, "but in terms of actual measured games - what actually, ultimately counts - is that it was a better engineering decision to raise the clock. There are various bottlenecks you have in the pipeline that can cause you not to get the performance you want if your design is out of balance."
This is really telling. This is an admission that the CUs can (and do) starve due to deficiencies elsewhere in the GPU pipeline. It's too bad that the bottlenecks aren't actually elaborated.
"But we also increase the performance in areas surrounding bottlenecks like the drawcalls flowing through the pipeline, the performance of reading GPRs out of the GPR pool, etc. GPUs are giantly complex. There's gazillions of areas in the pipeline that can be your bottleneck in addition to just ALU and fetch performance."
The GPR comment is pretty weird. GPRs allocation for shaders is done during compilation of the shader, and the only real rule is to minimize them without having to resort to spilling to some sort of scratch buffer. What he could mean, instead of allocation, is just filling them in the first place (loading uniforms and the like). That's a sort of difficult problem, but one I would hope that they have a handle on.
You can use the Move Engines to move these things asynchronously in concert with the GPU so the GPU isn't spending any time on the move. You've got the DMA engine doing it.
"From a power/efficiency standpoint as well, fixed functions are more power-friendly on fixed function units," adds Nick Baker. "We put data compression on there as well, so we have LZ compression/decompression and also motion JPEG decode which helps with Kinect. So there's a lot more to the Data Move Engines than moving from one block of memory to another."
The GCN DMA engines are part of what they're calling a Data Move Engine? Is the Data Move Engine really just a bunch of other bits of fixed function that they've grouped together even though they're actually separate?
Microsoft's approach to asynchronous GPU compute is somewhat different to Sony's - something we'll track back on at a later date. But essentially, rather than concentrate extensively on raw compute power, their philosophy is that both CPU and GPU need lower latency access to the same memory. Goosen points to the Exemplar skeletal tracking system on Kinect on Xbox 360 as an example for why they took that direction.
"Exemplar ironically doesn't need much ALU. It's much more about the latency you have in terms of memory fetch, so this is kind of a natural evolution for us," he says. "It's like, OK, it's the memory system which is more important for some particular GPGPU workloads."
Here comes latency. Are talking about the GDDR5 vs. DDR3 latency, or ESRAM vs. main memory, or something else entirely?
