Xbox 360: Project Gotham Racing 3, 1024x600p and framebuffers

[Eug]

OK, correct me if I'm wrong, but my understanding is that a single 1280x720 frame without anti-aliasing is about 7 MB, which fits nicely in the Xbox 360's 10 MB embedded DRAM.

However, if you want 2X antialiasing you need twice the RAM, which means that you'd need 14 MB for 1280x720.

Now, considering that the Xbox 360 is supposed to require 1280x720 with 2xAA I'm a little confused as to why the embedded DRAM wasn't 14 or 16 MB. Would the cost be far too high?

If cost was an issue and they had to limit it to 10 MB, why not just make it 8 MB then?

I'm just a little confused, since Project Gotham Racing 3 had to resort to 1024x600 to get their 2xAA.

BTW, what is the exact size of available EDRAM? Cuz 1024x600 is actually a fair chunk below 5 MB. It's closer to 4.7 MB. 5 MB would be 1024x640.

 

[framerateuk]

I did read somewhere that the original 360 dev boxes had X800 cards in them, and there was something about the AA modes on them that wasnt compatible with the actual 360's graphics card. Hence why none of the launch games had AA.

Now the dev kits have updated cards, and the newer games now have AA enabled at the correct 720p resolution.

This could be total BS though Im not sure where i read it, but it would certainly explain the lack of AA on the launch games.

 

[zephyrprime]

1280*720*4=3686400. So it doesn't take 7MB for one frame. It takes 7.03125MB for one 2xAA frame.

I wonder exactly what all the edram does? It doesn't seem to me like just putting the frame buffer on it would be a huge performance boost.

 

[dunno99]

Originally posted by: zephyrprime
1280*720*4=3686400. So it doesn't take 7MB for one frame. It takes 7.03125MB for one 2xAA frame.

I wonder exactly what all the edram does? It doesn't seem to me like just putting the frame buffer on it would be a huge performance boost.

Actually, it depends on how the anti-aliasing is done. If the game does per-pixel anti-aliasing (i.e. sample at two difference points within the pixel), then there's no need for doubling the memory, as the additional logic on the EDRAM can handle the simple averaging of the two samples. Furthermore, you have to remember that the framebuffer also includes the z-buffer, the stencil buffer, etc..., not just RGBA color buffer.

As for what the EDRAM does? Remember that some of the most costly calculations on the GPU includes things like updating the z-buffer (with the 360, one doesn't need to read and then write...they just send it to the EDRAM and it'll handle the compare) and doing alpha blending (no more reads on the actual GPU end anymore, just send it down with the correct function, and the EDRAM will handle the blending). To be more specific, the former instance eats up a lot of memory bandwidth which the 256GB/s bandwidth offered by the EDRAM's logic easily handles (and therefore doesn't eat into texture memory bandwidth). For the latter, the additional logic on the EDRAM will handle the calculations, and won't eat into GPU cycles.

Another point to note is that the use of a fast EDRAM allows for more (full-screen) post-processing effects such as bloom. Bloom itself can eat about 400MB/s of bandwidth (linearly separable box-like Gaussian bleed filtering with a 7 to 9 pixel kernel...say for a 7 pixel kernel, that's 28 texture reads per pixel...28*1280*720*2(AA)*4*2(16-bit floating point) = 412876800 ~= 395MB/s). Given that one isn't rendering one frame a second, then multiply that 400MB/s by number of targetted frames and then subtract this figure from total memory bandwidth, and you have an idea of how much remains for other activities. On an XBox360 GPU, you get this pretty much for free, whereas for PC parts, this fights with texture/z/alpha/stencil/etc... bandwdith.

*Edited to correct for misquoting EDRAM figures.*

 

[zephyrprime]

Thanks dunno99. That was very informative.

 

[Eug]

Thanks for the explanation, even if it's over my head.

However... Maybe I am misunderstanding (which wouldn't be a surprise), but I read some different numbers here:

If you want "free" antialiasing the Back-Buffer of the frame MUST fit on the eDRAM (10 MB).

Ok, imagine you have a game with 1280x720 + 32 bits color + 32 bits Z-Buffer (3D location of one point). In this case you have:

Back-buffer = (1280x720) * (32 bits color + 32 bits Z-Buffer)
Back-buffer = (921.600) * (64 bits) = 7.372.800 bytes = 7.0 Mbytes

Perfect, it fits on eDRAM... but if you want Antialiasing you must multiply this number. For 2xMSAA you need 14.0 Mbytes and for 4xMSAA up to 28.1 Mbytes!!!

***Note: With 640x480 resolutions you allways have 4xMSAA completely free, the problem is on HD resolutions.

How can you have free antialiasing then? Well, you have two options.

1) Lowering the resolution, that is what "I think" Bizarre made:

Back-buffer = (1024x600) * (32 bits color + 32 bits Z-Buffer)
Back-buffer = (614.400) * (64 bits) = 4.915.200 bytes = 4.9 Mbytes
Back-buffer * 2xMSAA = 9.8 Mbytes!! It fits on eDRAM.

1024x600 + 2xMSAA = Free.

What's the truth?

 

[Sonikku]

Originally posted by: dunno99

Originally posted by: zephyrprime
1280*720*4=3686400. So it doesn't take 7MB for one frame. It takes 7.03125MB for one 2xAA frame.

I wonder exactly what all the edram does? It doesn't seem to me like just putting the frame buffer on it would be a huge performance boost.

Actually, it depends on how the anti-aliasing is done. If the game does per-pixel anti-aliasing (i.e. sample at two difference points within the pixel), then there's no need for doubling the memory, as the additional logic on the EDRAM can handle the simple averaging of the two samples. Furthermore, you have to remember that the framebuffer also includes the z-buffer, the stencil buffer, etc..., not just RGBA color buffer.

As for what the EDRAM does? Remember that some of the most costly calculations on the GPU includes things like updating the z-buffer (with the 360, one doesn't need to read and then write...they just send it to the EDRAM and it'll handle the compare) and doing alpha blending (no more reads on the actual GPU end anymore, just send it down with the correct function, and the EDRAM will handle the blending). To be more specific, the former instance eats up a lot of memory bandwidth which the 256GB/s bandwidth offered by the EDRAM's logic easily handles (and therefore doesn't eat into texture memory bandwidth). For the latter, the additional logic on the EDRAM will handle the calculations, and won't eat into GPU cycles.

Another point to note is that the use of a fast EDRAM allows for more (full-screen) post-processing effects such as bloom. Bloom itself can eat about 400MB/s of bandwidth (linearly separable box-like Gaussian bleed filtering with a 7 to 9 pixel kernel...say for a 7 pixel kernel, that's 28 texture reads per pixel...28*1280*720*2(AA)*4*2(16-bit floating point) = 412876800 ~= 395MB/s). Given that one isn't rendering one frame a second, then multiply that 400MB/s by number of targetted frames and then subtract this figure from total memory bandwidth, and you have an idea of how much remains for other activities. On an XBox360 GPU, you get this pretty much for free, whereas for PC parts, this fights with texture/z/alpha/stencil/etc... bandwdith.

*Edited to correct for misquoting EDRAM figures.*

I'm not quite sure what you just said, but logic dictates that with that much credibility, you can't not know what you're talking about.

 

[Eug]

^

 

[dunno99]

Originally posted by: Eug
Thanks for the explanation, even if it's over my head.

However... Maybe I am misunderstanding (which wouldn't be a surprise), but I read some different numbers here:

If you want "free" antialiasing the Back-Buffer of the frame MUST fit on the eDRAM (10 MB).

Ok, imagine you have a game with 1280x720 + 32 bits color + 32 bits Z-Buffer (3D location of one point). In this case you have:

Back-buffer = (1280x720) * (32 bits color + 32 bits Z-Buffer)
Back-buffer = (921.600) * (64 bits) = 7.372.800 bytes = 7.0 Mbytes

Perfect, it fits on eDRAM... but if you want Antialiasing you must multiply this number. For 2xMSAA you need 14.0 Mbytes and for 4xMSAA up to 28.1 Mbytes!!!

***Note: With 640x480 resolutions you allways have 4xMSAA completely free, the problem is on HD resolutions.

How can you have free antialiasing then? Well, you have two options.

1) Lowering the resolution, that is what "I think" Bizarre made:

Back-buffer = (1024x600) * (32 bits color + 32 bits Z-Buffer)
Back-buffer = (614.400) * (64 bits) = 4.915.200 bytes = 4.9 Mbytes
Back-buffer * 2xMSAA = 9.8 Mbytes!! It fits on eDRAM.

1024x600 + 2xMSAA = Free.

What's the truth?

I think what the author meant by "free" is the blend operation of the two fragments belonging to the same pixel. In this case, the additional logic on the EDRAM itself will generate the blend. However, since blending is cheap (relative to more complex shaders), I'm not sure why devs really need to worry about getting it to fit on the EDRAM.

Furthermore, shouldn't both the back and front buffers have to lie within the EDRAM. Which means for 720p, one would come close to 10MB with both a front buffer without Z and a backbuffer with Z. So I don't even know where the second samples for each pixel would reside.

I guess what I'm saying it, what you quoted seems to be speculation (and the math somehow doesn't work out), or I don't know enough about XBox 360 hardware specs. I hope I can find some info in the future to clarify.