*spin-off* Battlefield 3 on Consoles

[sebbbi]

Would be interesting to see how well the 360 cope with a full Deferred Renderer with FP16 HDR and AA. Wonder if they'll get away with it by tiling or simply go the route of 1152 x 720.

You do not need 16 bit for the g-buffer surface albedo color. It doesn't require high dynamic range. With dxt compressed source textures, you would just be wasting bandwidth by storing surface texture colors in 16 bit precision.

You only need a high dynamic range buffer when you output your lighting, but at that point the g-buffers have already been rendered and resolved to textures. As BF3 utilizes tiled deferred rendering, it doesn't need a z-buffer either in the lighting pass. 4 x 16 bit float 720p light accumulation buffer would easily fit the edram (it's 7 megabytes).

However the smallest possible g-buffer layout requires 4+4+4=12 bytes per pixel (two 8888/10-10-10-2 color buffers + depth buffer). And that would require 10.54 megabytes of edram. So you either have to drop the resolution by 6% or do tiling.

Also BF3 is using post process AA, so the AA doesn't bring any extra edram/tiling concerns. In the post process pass you just need to have a single 8888 output buffer in edram, and that's fine without tiling (even at 1080p).

 

[Ruskie]

Edit.

Oh my...wrong thread.It was meant for BF3 console spin off.Sry

ModEdit: Just copying the original post back in here to fit with the order of posts & followup -AlS

You do not need 16 bit for the g-buffer surface albedo color. It doesn't require high dynamic range. With dxt compressed source textures, you would just be wasting bandwidth by storing surface texture colors in 16 bit precision.

You only need a high dynamic range buffer when you output your lighting, but at that point the g-buffers have already been rendered and resolved to textures. As BF3 utilizes tiled deferred rendering, it doesn't need a z-buffer either in the lighting pass. 4 x 16 bit float 720p light accumulation buffer would easily fit the edram (it's 7 megabytes).

However the smallest possible g-buffer layout requires 4+4+4=12 bytes per pixel (two 8888/10-10-10-2 color buffers + depth buffer). And that would require 10.54 megabytes of edram. So you either have to drop the resolution by 6% or do tiling.

Also BF3 is using post process AA, so the AA doesn't bring any extra edram/tiling concerns. In the post process pass you just need to have a single 8888 output buffer in edram, and that's fine without tiling (even at 1080p).

Hey Sebbbi! Can you guess g buffer size from looking at what DICE had in presentation? I remember Laa Yosh mention something like that,here.

Yeah, it's all very impressive and also gives me great hope that the console versions will look very similar to the PC.

Also interesting how fat the G-buffer is, 5 x 4 bytes altogether with the Z/stencil. It must be using tiling on the X360 but it fits in 20MB so it only has to re-send once. Gives you the impression that they've layed it out like this exactly with the EDRAM in mind...

Mind you tiling is not confirmed yet but it's the only way I can see such a big G-buffer working for them, so it's a safe bet.
And yeah it looks like they've said, "so we're gonna have to tile because of the extra RGBA radiosity buffer, then at least make full use of the doubled EDRAM size and fill out the rest of the memory with useful info". Hence the different extra channels associated with material properties and the lack of trickery with the surface normal channels.

 

[AlNom]

5x1280x720 32-bpp (4-byte) buffers would be 18MB.

 

[sebbbi]

Hey Sebbbi! Can you guess g buffer size from looking at what DICE had in presentation?

The chart title states [R8 G8 B8 A8] so it must be 32 bits per buffer. Z-buffer + four 32 bit g-buffers = 18MB (like AlStrong said above). Assuming they generate all that data in a single pass. If that diagram presents all the data they generate during their whole rendering process, then it's impossible to say how much render target memory they need (unless we have more detailed information about their rendering pipeline).

 

[Ruskie]

Thanks.So that kind of confirms tiling,right?

 

[sebbbi]

Thanks.So that kind of confirms tiling,right?

Yes, assuming they generate all that data in a single pass.

 

[Ruskie]

Ok,I slowly got it Thanks guys for answers.

 

[AlNom]

I'm curious though. The render targets on 360 require padding to 80x16 pixel tiles (no AA). Is there a way to take this into consideration for TBDS instead of using a custom tile size?

----

I guess the two tiles can be either 1280x400 + 1280x320 for a horizontal split or 720x720 + 560x720 for a vertical split.

 

[Laa-Yosh]

We haven't seen too many titles pushing the X360 while using tiling so far, so it's about time IMHO to have someone look into that.

 

[Ruskie]

We haven't seen too many titles pushing the X360 while using tiling so far, so it's about time IMHO to have someone look into that.

Yea,although couple of them were. NFS:HP used deferred rendering and it was 720p 2xMSAA,Blur too(that was actually 4xMSAA,never dropped a frame).

Other than that I think GTA IV and RDR should be mentioned,those titles looked pretty damn impressive on my 360(also DR with MSAA).

 

[Devious]

Yea,although couple of them were. NFS:HP used deferred rendering and it was 720p 2xMSAA,Blur too(that was actually 4xMSAA,never dropped a frame).

Other than that I think GTA IV and RDR should be mentioned,those titles looked pretty damn impressive on my 360(also DR with MSAA).

Though wasn't Blur using Light Pre-pass rendering? IIRC from the Digital Foundry interview, 720p & 4xMSAA for Blur took up 7MB of eDRAM.

 

[AlNom]

IIRC from the Digital Foundry interview, 720p & 4xMSAA for Blur took up 7MB of eDRAM.

Blur used a packed depth buffer to reduce the amount of render target memory. I'd consider it a special case where the game didn't have much need for hi precision depth or just had low depth complexity.

I'd actually wonder about fighting games doing something similar...

 

[(((interference)))]

So the 360 will be doing more geometry processing anyway due to the tiling overhead - that makes sense then.

Though wasn't Blur using Light Pre-pass rendering? IIRC from the Digital Foundry interview, 720p & 4xMSAA for Blur took up 7MB of eDRAM.

Yea, but light pre pass is apparently more expensive than fully deferred since you have to do two geometry passes - so at 720p with 20 cars on track and 4xMSAA means a lot of tiles (4?) so Blur is processing a lot of geometry.

 

[Devious]

Ah, thanks for clearing that up and schooling my ¿"noobitivity"?

 

[ultragpu]

You do not need 16 bit for the g-buffer surface albedo color. It doesn't require high dynamic range. With dxt compressed source textures, you would just be wasting bandwidth by storing surface texture colors in 16 bit precision.

You only need a high dynamic range buffer when you output your lighting, but at that point the g-buffers have already been rendered and resolved to textures. As BF3 utilizes tiled deferred rendering, it doesn't need a z-buffer either in the lighting pass. 4 x 16 bit float 720p light accumulation buffer would easily fit the edram (it's 7 megabytes).

However the smallest possible g-buffer layout requires 4+4+4=12 bytes per pixel (two 8888/10-10-10-2 color buffers + depth buffer). And that would require 10.54 megabytes of edram. So you either have to drop the resolution by 6% or do tiling.

Also BF3 is using post process AA, so the AA doesn't bring any extra edram/tiling concerns. In the post process pass you just need to have a single 8888 output buffer in edram, and that's fine without tiling (even at 1080p).

Thanks Sebbi, it's getting technical but I think I kinda get it.

 

[MJP]

Yea, but light pre pass is apparently more expensive than fully deferred since you have to do two geometry passes

That's never something you could say as a definitive statement, especially on the 360 where fat G-Buffers have certain disadvantages from a performance point of view. It depends on the game, and the hardware.

 

[kagemaru]

We haven't seen too many titles pushing the X360 while using tiling so far, so it's about time IMHO to have someone look into that.

I wonder if the processing overhead for tiling is too great for any game to really "push" the 360 while tiling. Looks like most developers find greater benefits by doing what they could to avoid tiling.

 

[Ruskie]

I found this blog post from the guy working on Despair Engine(FEAR 3),with his reasons of taking deferred shading over deferred lighting.He says that first they were DL on all platforms,than they went fully deferred shading on PS3 since the guy responsible for that version said it would be better for performance reasons.It was, and PS3 version was on par.

Than they ported deferred shading on 360 and PC version and as he says they went from no tiling(assume sub hd) to tiling on 360 version and performances on GPU were marginaly slower(assuming they ran it at higher resolution,meaning more pixel to draw) than their optimized DL solution,but CPU gain was actually big. Well,this is only one example but its quite interesting one,fully deferred on 360.

Here is the rest
http://gameangst.com/?p=141

 

[kagemaru]

I found this blog post from the guy working on Despair Engine(FEAR 3),with his reasons of taking deferred shading over deferred lighting.He says that first they were DL on all platforms,than they went fully deferred shading on PS3 since the guy responsible for that version said it would be better for performance reasons.It was, and PS3 version was on par.

Than they ported deferred shading on 360 and PC version and as he says they went from no tiling(assume sub hd) to tiling on 360 version and performances on GPU were marginaly slower(assuming they ran it at higher resolution,meaning more pixel to draw) than their optimized DL solution,but CPU gain was actually big. Well,this is only one example but its quite interesting one,fully deferred on 360.

Here is the rest
http://gameangst.com/?p=141

Great find!

 

[sebbbi]

Than they ported deferred shading on 360 and PC version and as he says they went from no tiling(assume sub hd) to tiling on 360 version and performances on GPU were marginaly slower(assuming they ran it at higher resolution,meaning more pixel to draw) than their optimized DL solution,but CPU gain was actually big. Well,this is only one example but its quite interesting one,fully deferred on 360.

You don't need to go sub HD if you do light prepass (the original two pass version). You only need one (32 bit per pixel) render target, since you only need normal vector and specular exponent for the lighting pass. Color is added in a secondary geometry pass. Secondary geometry pass is the reason why light prepass requires more CPU cycles and GPU cycles (vertex transform twice).

However you can do light prepass in a single pass. That is pretty much comparable to fully deferred. It has slightly less light overdraw cost (color is composited after lights) compared to fully deferred, but the lighting formula is more restricted (single color specular, etc).