How many render targets deferred renderers usually need? In my limited understanding deferred renderering engines might have some struggles on limited frame buffer size
4 or so, I think. 5 including the final framebuffer.
The thing is, though, to produce the final framebuffer you need to sample from the preceding 4. So in an eDRAM situation, if it's like 360's eDRAM, you need to copy those buffers back to main memory and then sample them from there when rendering the final frame.
So eDRAM size wouldn't actually be that big of a deal in this case. You'd render the buffers one at a time, only one would need to be in eDRAM at a time.
The slightly annoying thing with 360 eDRAM - I am told - was the copy-back to main memory for sampling in the final pass.
If the eDRAM is so big that it can hold all the buffers together, and the GPU can sample from the eDRAM directly, it would get around that issue.
There's talk in Durango's case that there'll be a hardware blitting unit that will let an application copy data from eDRAM back to main memory without needing the CPU's attention edit - see below for correction. That's reportedly one of the '3 blocks' of custom hardware. Having dedicated hardware to do that means you wouldn't have to wait for CPU thread to be ready, and so it should be faster than with 360. This would be useful if the eDRAM is of limited capacity and you're doing multi pass rendering of any kind...and a lot of newer lighting and other techniques are quite heavy on multiple passes.
edit - apparently the GPU handled the copy-back in 360, not the CPU. But the point still stands that there's a stall while you wait for that copy-back to complete if the next pass depends on data generated by the previous. I'm presuming if a hardware blitter is present in Durango that it works out faster than the copy-back system in 360.
