Hi there:
Its been sometime since shinen mentioned that Wii U has plenty of bandwidth and that with just 16MB of edram was enough for the 1080p framebuffer with duble buffering, still many doubted the wii u edram bandwidth despite the fact that xbox 360 edram of internal 256GB/s normally used for render targets like the framebuffer is just enough for the 720p with double buffering without msaa and in wii u with simple calculations you know that 7.1MB of edram is enough for the 720p with double buffering.
Well, right now shinen is taking adventage of the wii u edram bandith and using it for the g buffer on fast racing neo for the deffered rendering and likely the post processing effetcs(g buffers arent limited to the deffered rendering, they also can be used for the post processing effects); you may not know this but gbuffers take large aount of bandwidth(it was rarely used in xbox 360 and ps3 due to the bandwidth limitations and develpers couldnt do it the conventional way but instead came up with ideas using the cpu-gpu interaction on 360 and the spus on ps3 but the implementation still had limits and could only use one gbuffer) to the point that even Ryse for the xbox one couldnt have msaa to the fullest eventhough microsoft has mentioend in his article about predictable tiling that msaa requires far less bandwidth than framebuffer, 2xmsaa en xbox 360 edram would be just about 2.5MB, this was due that the framebuffer of 1600*900(this is about 50% more than 720p but they are likely using double buffering not triple as they dont specify it) and the gbuffer for the deffered rendering and post processing effects were already consuming must of the bandwidth available(from what i read they used temporal antialaising since has almost 2x better performance and bandwidth requirements werent as expensive as msaa, i also heard that seems like msaa is not possible to implement along with deffered rendering and thats why we have this other option available). Wii U edram on the other hand seems to have no problems with andwidth to the point that shinen can use triple buffering for the framebuffer requiring only 3.6MB for each buffer which makes it 10.8MB, and they still use the rest of the edram for the gbuffer, intermediate buffers and other things. The g buffer is also large, in xbox 360 develoeprs wanted to use it but needed 12MB of edram besides the 10MB for the 720p with double buffering
http://www2.disney.co.uk/cms_res/blackrockstudio/pdf/BlackRockStudioTechnology_Deferred_Shading.pdf
Since wii u requires 7.2MB of edram for 720p with double buffering and 360 needs 10MB, with some calculations that would mean that a gbuffer on wii u edram coul be around the 8.64MB, which combined with the 10.8MB of edram for the triple buffering with the framebuffer is 19.44MB out of the 32MB of edram and the 3MB of faster edram+sram, noe thats plenty of bandwidth
here
@HylianCIA We have a couple of failbacks to keep it stable. Triple Buffering also helps to get rid of peaks before anyone can notice.
And here is the comment from crytek about the bandwidth limits on xbox one esram for the deffered rendering
http://www.eurogamer.net/articles/digitalfoundry-crytek-the-next-generation
"
Cevat Yerli: We put our most accessed render targets like the G-Buffer targets into ESRAM. Writing to ESRAM yields a considerable speed-up. While 32MB may not be enough to use something like MSAA to the fullest, with a smart memory management strategy it is possible to deal with that.
"
Ok, so whats so cool about deffered rendering?
The primary adventage is performance, unlike the classic forward rendering, the deffered rendering uses far less shader power to render multiple lights on the escene, of course that has some issues speically the fact that bandwidth requirments are larger then the other technique, but when you consider that in the worst case the forward rendering could require shader power equal to objects*lights to render the lights and deffered rendering would require shader power only about lighst+objects then the tradeoff looks promising if you have good amount of memory bandwidth
here
http://www.ogre3d.org/tikiwiki/tiki-index.php?page=Deferred+Shading
"
What is Deferred Shading?
Deferred shading is an alternative approach to rendering 3d scenes. The classic rendering approach involves rendering each object and applying lighting passes to it. So, if an ogre head is affected by 6 lights, it will be rendered 6 times, once for each light, in order to accumulate the affection of each light.
Deferred shading takes another approach : In the beginning, all of the objects render their "lighting related info" to a texture, often called the G-Buffer. This means their colours, normals, depths and any other info that might be relevant to calculating their final colour. Afterwards, the lights in the scene are rendered as geometry (sphere for point light, cone for spotlight and full screen quad for directional light), and they use the G-buffer to calculate the colour contribution of that light to that pixel.
See the links in Further Reading section to read more about it. It is recommended to understand deferred shading before reading this article, as the article focuses on implementing it in ogre, and not explaining how it works.
Deferred Shading Advantages
The main reason for using deferred shading is performance related. Classing rendering (also called forward rendering) can, in the worst case, require num_objects * num_lights batches to render a scene. Deferred shading changes that to num_objects + num_lights, which can often be a lot less.
Another reason is that some new post-processing effects are easily achievable using the G-Buffer as input. If you wanted to perform these effects without deferred shading, you would've had to render the whole scene again.
Deferred Shading Disadvantages
There are several algorithmic drawbacks with deferred shading - transparent objects are hard to handle, anti aliasing can not be used in DX9 class hardware, additional memory consumption because of the G-Buffer.
In addition to that, deferred shading is harder to implement - it overrides the entire fixed function pipeline. Pretty much everything is rendered using manual shaders - which probably means a lot of shader code.
"
As you can see, wii u edram may not just have more memory bandwidth than the xbox one(perhaps the rumor about the 500GB/s to the terabyte of bandwidth may be true) but also developers could take profit of it so that the lights in the escene would cost far less shader power than they did in the past generation and so use the extra shader power that was saved up for other things
Currently Online 
