Why do you keep reposting the same things? And as screenshots as well?

Anwhoo veriable reslution is a neat trick. And it is what allowed them to achive 1080p60 on PS3, even if it was only most of the time. There are a few others that use it for example RAGE and Ninja Gaiden 3.

yea, i think i like the trick since noticing the variable resolution chnages would be harder than noticing framedrops

The reason i keep putting those articles is just to make sure you read them, as they say they had to came up with some implementation tricks to make deffered rendering possible on those consoles by reducing the bandwidth requirements, but the cost was to use a lot power form the consoles since ps3 needed to use 5 spus for this and 360 had to use gpu parallelism +cpu. thats a lot power if you ask me and the benefit of deffered rendering should be taht you use few shader power, thats what i am talking about, in the last generation consoles this technique was possible but by sacrificing more power isntead of bandwidth, in this new generation consoles like wii u is better to use more bandwidth for this technique and save up lots of shader power for other rendering purposes, if shinen uses the same tricks these developers used in the past generation consoles then the purpose of deffered rendering will have no meaning, the primary adventage of the technique will dissappear, wii u has plenty of bandwidth and using those tricks will not improve performance but reduce it

"Better equipped" is questionable since a G-buffer which consists of multiple render targets doesn't exactly have a very small footprint to be able to fit all of the render targets on the eDRAM and the WII U doesn't exactly have a very high memory bandwidth either to help the situation ... 

Those are the tricks devs used on the PS3 and X360 but they aren't the only tricks out there. For example Battlefeild 3 and 4 use a GPU compute based aproach to tiled deferred rederer on PC (they use SPUs to do a similar implementation on PS3), a similar implementation could possibly work for the Wii U. And using the SPUs to offload GPU tasks is what they were designed to do so it's natural devs would use them for that, in fact they would be stupid not too.

for wii u edram having enough bandwidth for triple frame buffers of 720p plus a gbuffer and plus intermediate buffers and such then that means has plenty of bandwidth. seems that for the 360 they needed 12MB of edram for the g-buffer which obviously were not present and had to come up with workarounds to reduce memory bandwidth requirements, in wii us case knowing that needs about 7.2MB of edram for the 720p with double buffering and that 360 required 10MB FOR THE 720P WITH DOUBLE Buffering that would mean about 8.64MB for the g-buffer

here

http://www2.disney.co.uk/cms_res/blackrockstudio/pdf/BlackRockStudioTechnology_Deferred_Shading.pdf

and here microsoft themselves confirms that 10mb of edram was just enough for the 720p with double buffering

http://msdn.microsoft.com/en-us/library/bb464139.aspx

@

Predicated Tiling

 

Other Versions

0 out of 1 rated this helpful - Rate this topic

@

this means taht while 360 had barely neugh bandwith in those 10MB of edram for the doube buffering with 720p, wii u has almost what is required for triple buffering of 720p in 10MB, the difference is just a margin of 0.8MB. adding up a gbuffer would be just 8.64MB, which combined with triple framebuffer would be 19.44MB od edram, we still have plenty enough for the intermediate buffers and maybe other things since wii u has 32MB of main edram plus 2MB of faster edram and 1MB of sram, of course that maybe the extra edram and sram p[ools could be meant to the cpu

Better than the situation on 360 where there was only 10MB of eDRAM.

Shin'en reckon the multiple render targets fit into 32MB just fine.

Im no expert, but i think i will take Shinens word as gospel. After all they are talented devs, that know their stuff and have a lot of knowledge of what Wii U can and cant do.

I was nagged at to see this thread via Steam.

Of course it would be.
You can do multiple render targets that fit just fine into 10Mb of eDRAM, you could also fit a 30Mb G-buffer into 10Mb of eDRAM.

Sounds impossible right?

Not exactly. - You can do multiple passes and you can do tiling.

After the first tile of the G-buffer is created, you can keep the Z in-place and then proceed to light it, then you can move onto the next tile, then the next and the next... This method allows you to minimse the overhead of reloads, provided if you aren't doing anything with neighbouring pixels.

From what I can recall, Xenos will have a bandwidth cap of roughly 16GB/s during this process, hence with a 30MB G-Buffer, that would take roughly 2 ms, which is more than do-able on the Xbox 360 and with just 10Mb of eDRAM.

The WiiU just requires far less trickery to achieve the same thing, but don't think that functionally it's superior, because it's not.

Also Megafenix, after all this time you really should stop posting information that you clearly have zero idea about, you LITERALLY have no idea if it's even correct or not or what half the stuff does.

Also, cats.

Tiling is still an imperfect workaround compared to a single pass.

Multiple passes and tiling are very different approaches, that's something to keep in mind.

As for Tiling... Tiling can actually boost efficiency significantly as allot of "junk" can be thrown out before rendering is performed (I.E. Better culling.)

However, keep in mind that the Wii U can also do tiling, heck, the Nintendo 64 even did tiling, it had to out of necessity.