Can't you just keep some of that in the embedded ram? I.e the specific buffer you might be working on at that point, or he ones that get accessed the most? You wouldn't necessarily need to keep the final frame buffer for instance
On PS4 and PC it doesn't really matter because all ram is the same speed so you can clump it all together as one big buffer, but inevitably I think devs will start splitting it up for Xbox one. A pain at first but I'm sure it'll become simpler as time goes on.
Yup that's right. And most games do this.
However the g-buffer rendering pass is typically very bandwidth heavy. And the when generating the g-buffer, you are writing the entire buffer in on go - so it's naturally going to be a very heavy process.
A simplified render path for a deferred renderer may be:
render z-prepass (render depth) -> render g-buffer (render full g-buffer, depth) -> render lighting buffer using g-buffer for materials, etc (render just a lighting buffer, but read the full g-buffer) -> render transparents into lighting buffer, etc -> mess with lighting buffer and apply post processing, etc -> copy to frame buffer
Each of those has different demands on the GPU both in terms of memory, bandwidth, alu, etc. The g-buffer render is one of the bigger hits for bandwidth, so it'd makes sense to keep all the g-buffer render targets in ESRAM. And as they all get equal usage, mixing and matching memory location probably is quite detrimental. It may be that after the g-buffer is written, some of the less important buffers can be copied to DDR after this point, (to make room for shadow maps during the lighting pass, etc).
Certainly things like the frame buffer make no sense at all being in ESRAM.
It's not uncommon for a game to be pushing 300MB of render targets when all said and done, so juggling what goes where is going to be quite tricky for XB1 devs.
