Bandwidth required for 720p 4xmsaa?

[MBDF]

I have a simple question... What is the amount of bandwidth needed for a 720p 4msaa image, and how do you go about calculating that..... for instance, If you've got the PlayStation3 with it's 22GB bandwidth to GDDR, how much bandwidth is required per second for 720p 4msaa output?

 

[ERP]

I have a simple question... What is the amount of bandwidth needed for a 720p 4msaa image, and how do you go about calculating that..... for instance, If you've got the PlayStation3 with it's 22GB bandwidth to GDDR, how much bandwidth is required per second for 720p 4msaa output?

(1280*720 * (bytes/color value+Bytes/Z Value) * AA Level) * Number of times the scren is overdrawn * FPS

You need to double the bytes/color or bytes/Z if you have either blending enabled or your doing a Zwrite respectively.

But that's not a useful figure....
Because you will rarely actually get peak bandwidth (closer to 50% of peak in most real world scenarios), and sometimes you will be limited by ALU calculations, so the bus is sitting idle. It doesn't count Texture fetch bandwidth and it doesn't count vertex bandwidth or Framebuffer compression, It doesn't count innefficiencies with small triangles etc etc etc.

In the end there is no way to tell.

The 256GB/s that Xenon EDRAM has is exactly enough such that at 500MHz with 8 ROPs, it will never stall the rest of the chip.

 

[MBDF]

(1280*720 * (bytes/color value+Bytes/Z Value) * AA Level) * Number of times the scren is overdrawn * FPS

You need to double the bytes/color or bytes/Z if you have either blending enabled or your doing a Zwrite respectively.

Thanks for the info; so an example would be: (1280x720x(8[64-bit HDR]+4)x4)xODx60?

How many times is the screen usually overdrawn? what contributes to overdraw? And pardon my asking but how common is blending and/or z-write?

Thanks

 

[Titanio]

You need to factor in compression too, if it's available on the chip you're using.

The answer is, though..there is no answer. It's a variable thing.

edit - also, you multiply the Zbuffer requirements also by the MSAA depth? I figured that was just for your colour buffer?

 

[ERP]

Thanks for the info; so an example would be: (1280x720x(8[64-bit HDR]+4)x4)xODx60?

How many times is the screen usually overdrawn? what contributes to overdraw? And pardon my asking but how common is blending and/or z-write?

Thanks

Depends on the application, and the target platform.
Some PS2 games have 20+ times transparent overdraw when you have dramatic explosions on screen. But OD is something PS2 does well, so software tends to explot this.

You will be able to slow a game down with lots of transparent OD on RSX, so devs will likely limit the amount of transparent OD.

 

[MBDF]

Depends on the application, and the target platform.
Some PS2 games have 20+ times transparent overdraw when you have dramatic explosions on screen. But OD is something PS2 does well, so software tends to explot this.

You will be able to slow a game down with lots of transparent OD on RSX, so devs will likely limit the amount of transparent OD.

So overdraw is like compositing transparent layers overtop? (such as smoke textures?) What would as an extreem example 20+ layers(in your example) multiply the original framebuffer bandwidth requirements by on PS2?

Thanks again

 

[Titanio]

So overdraw is like compositing transparent layers overtop? (such as smoke textures?) What would as an extreem example 20+ layers(in your example) multiply the original framebuffer bandwidth requirements by on PS2?

Overdraw is how many times you write to the same pixel, regardless of whether it's for opaque or transparent surfaces. You should really be minimising overdraw in those parts of the screen where an opaque surface is closest to the camera, though, hence why transparency is the main culprit. For a given pixel, if you have 20 transparent objects between the camera and an opaque surface in its "line of sight" so to speak, each time you render to that pixel requires sampling the current value, then blending it with the contribution from the current transparent object, and writing the value back out.

You could think of it like painting a picture, where you paint EVERYTHING back to front, even things that ultimately will be hidden. That's the "dumb" way, with lots of overdraw. Via lots of different mechanisms you can try to eliminate unnecessary overdraw (drawing objects that'll be hidden), but obviously with transparency, objects aren't hidden, just their appearance is changed, so to speak. So you have to still draw objects behind transparent surfaces, modifying their appearance as you go, basically.

 

[MBDF]

Overdraw is how many times you write to the same pixel, regardless of whether it's for opaque or transparent surfaces. You should really be minimising overdraw in those parts of the screen where an opaque surface is closest to the camera, though, hence why transparency is the main culprit. For a given pixel, if you have 20 transparent objects between the camera and an opaque surface in its "line of sight" so to speak, each time you render to that pixel requires sampling the current value, then blending it with the contribution from the current transparent object, and writing the value back out.

You could think of it like painting a picture, where you paint EVERYTHING back to front, even things that ultimately will be hidden. That's the "dumb" way, with lots of overdraw. Via lots of different mechanisms you can try to eliminate unnecessary overdraw (drawing objects that'll be hidden), but obviously with transparency, objects aren't hidden, just their appearance is changed, so to speak. So you have to still draw objects behind transparent surfaces, modifying their appearance as you go, basically.

Thanks alot for the info, learning alot!... so is having blending enabled the same as having overdraw enabled, or are they seperate so that bandwidth requirements go up for each one? does enabling blending help with overdraw?

much thanks.

 

[ShootMyMonkey]

so is having blending enabled the same as having overdraw enabled, or are they seperate so that bandwidth requirements go up for each one? does enabling blending help with overdraw?

Overdraw isn't connected to blending at all, though the reverse is not true -- blending does demand overdraw. You don't really "enable" overdraw -- it just happens as a result of how you render stuff. Alpha blending is accumulative in nature so you need to know what color is there in the buffer in order to blend and know what your new color is. Some blend operations are order-independent, some are not. But either way, when you blend, you need to overdraw those pixels that actually are involved with the blend however many times.

Overdraw can still result from opaque renders where objects are drawn in such an order that you end up addressing the same pixel more than once. For instance, I can draw the terrain first and then draw all my characters. The thing is that my terrain (and sky) filled up the whole screen already, so everywhere where my characters are being drawn, those pixels will be overdrawn pixels. And it's entirely possible that some of these characters will occlude each other, so there will probably be some overdraw as a result of that.

 

[MBDF]

(my sister)

So what about the front buffer? does it require bandwidth as well?

So can it be confirmed as this?:

((720x1280x4aa)x(4bytes+4bytes))x(2x overdraw?)x2(blending)???

 

[PeterT]

You should consider the most important part of ERP's first reply, which you didn't quote:

But that's not a useful figure....
Because you will rarely actually get peak bandwidth (closer to 50% of peak in most real world scenarios), and sometimes you will be limited by ALU calculations, so the bus is sitting idle. It doesn't count Texture fetch bandwidth and it doesn't count vertex bandwidth or Framebuffer compression, It doesn't count innefficiencies with small triangles etc etc etc.

In the end there is no way to tell.

Now, I felt tempted to offer suggestions on your formula but as it will not really be any more accurate than before I'll refrain from doing that

 

[Guden Oden]

So what about the front buffer? does it require bandwidth as well?

Some bandwidth yes. In some hardware implementations the front buffer is copied and downfiltered in size when doing multisample antialiasing before being scanned out by the RAMDAC (or TMDS transmitter) and in a few others it isn't; it's just read out as is, and then downfiltered by the video hardware in realtime.

Xenos/x360 downfilters and copies its back buffer to main RAM for video scanout, so there's going to be a rather trivial amount of RAM bandwidth consumed by this task; screen height * width * depth (typically 4 bytes, but I don't know if Xenos saves the destination alpha bits or discards them, so it could be 3 bytes) * framerate in write bandwidth, and height * width * depth (typically 3 bytes, as the video hardware has no use for dest alpha) * video refreshrate in read bandwidth (typically 60Hz in HDTV mode; 50 or 60Hz in SDTV). As both read and write operations are treated the same by regular DRAM it's merely a technicality distinguishing them, but as a game might not update the front buffer on every video frame, it's still neccessary to separate between them if an accurate calculation is to be done...

((720x1280x4aa)x(4bytes+4bytes))x(2x overdraw?)x2(blending)???

Well, x2 overdraw assumes there is one level of overdraw, and x2 blending assumes there's one level of blending for each level of overdraw; neither of which may be the actual case! It could be more, or less, depending on the actual situation.

It's probably best to leave out overdraw and alpha blending completely, as these are highly variable from scene to scene. Just the matter of looking down at the ground in a game is going to totally change the load on the GPU, and often games handle indoors and outdoors situations in different manners.

 

[MBDF]

Thanks for all the info everyone...

So is it the ROP's that "paint" the layers of the picture which is then sent over the bus to memory where it is combined and then sent to the ramdac?

The reason I ask all these questions is because I'm trying to figure out what the typical load will be like for the RSX to memory interface... I know nothing is an exact science and it varies wildly, I'm just looking for a ballpark figure.... I did not know that usually peak bandwidth is about 50% theoretical maximum though, interesting.


I'm still trying to find out how GPU's work, I've heard there are some good articles on this site.

also, you multiply the Zbuffer requirements also by the MSAA depth? I figured that was just for your colour buffer?

I think the answer to that is here: http://www.beyond3d.com/articles/xenos/index.php?p=05#tiled

About half-way down the page, it seems so.

 

[j^aws]

Thanks for all the info everyone...

So is it the ROP's that "paint" the layers of the picture which is then sent over the bus to memory where it is combined and then sent to the ramdac?

Effectively, yes. Th ROPs modify, i.e. read/write/update pixels in the backbuffer. The backbuffer stores the current 'state' of what is about to be displayed on your sceen...

The reason I ask all these questions is because I'm trying to figure out what the typical load will be like for the RSX to memory interface... I know nothing is an exact science and it varies wildly, I'm just looking for a ballpark figure.... I did not know that usually peak bandwidth is about 50% theoretical maximum though, interesting.

There was a thread discussing this before...

720p 64bit framebuffer size? Educated guesses here please

...and a rough estimate with 5x overdraw and FP16,

http://www.beyond3d.com/forum/showpost.php?p=502341&postcount=44

EDIT: fixed url...

 

[MBDF]

Awsome, thank you!

And I would be remiss if i didn't ask this but, would increasing the number of ROP's increase fill rate, or on modern games does the shader fill rate not yet saturate the ROP's?

 

[j^aws]

Awsome, thank you!

And I would be remiss if i didn't ask this but, would increasing the number of ROP's increase fill rate,

Yes, increasing ROPs increases fillrate. However, if bandwidth to your backbuffer isn't scaled accordingly, then you'll be bandwidth bound...

or on modern games does the shader fill rate not yet saturate the ROP's?

I don't think shader fill rate is the right term but I know what you mean. Shaders are getting longer, and Flops power is increasing faster than bandwidth. So if you scaled the number of ROPs as 1:1 with the number of fragment shader units ( aka PS units), you'll probably find ROPs waiting around for finished fragments. Hence, you'll generally find ROPs are now decoupled from PS units for high/ medium end cards...e.g. 7800 GTX has 24 PS units but only 16 ROPs...

 

[MBDF]

Wow, ok, thanks for the info.... interesting suff...

so it seems that 1080p with 2xmsaa is roughly equal to 720p with 4xmsaa under the same conditions , howerver, I suppose that cuts the pixel shader ops down to about half? Then there's the matter of HDR and msaa yet to be determined, so aside form NAO32 I suppose givin the info it would be best to go with 1080p with slight jaggies I can live with, or 720p, prettier graphics, and noticible jaggies.

ahh it would be very nice to have some more RSX info.

 

[London Geezer]

Wow, ok, thanks for the info.... interesting suff...

so it seems that 1080p with 2xmsaa is roughly equal to 720p with 4xmsaa under the same conditions , howerver, I suppose that cuts the pixel shader ops down to about half? Then there's the matter of HDR and msaa yet to be determined, so aside form NAO32 I suppose givin the info it would be best to go with 1080p with slight jaggies I can live with, or 720p, prettier graphics, and noticible jaggies.

ahh it would be very nice to have some more RSX info.

Well i guess that depends on what TV you have. I guess those 2 or 3 people with 1080p TVs will generally tend to at least try to input a 1080p signal to the TV all the time, if they have a choice, cause that's the native resolution of the screen and bound to look better than a lower resolution that needs to be upscaled, even with AA. But as i said many times, different eyes like different things, therefore someone might like the look of 720p with a little bit of AA and someone lese might like the look of the higher resolution 1080p even if it doesn't have AA. To me 4x AA doesn't make enough difference, so i'd choose 1080p any day, but that's just me. Oh and i probably won't have a 1080p TV any time soon - say, a dog year - so i won't have much of a choice anyway, i'll be 720p-ing it all the way and i'll be very happy...

 

[Shifty Geezer]

I guess those 2 or 3 people with 1080p TVs will generally tend to at least try to input a 1080p signal to the TV all the time, if they have a choice, cause that's the native resolution of the screen and bound to look better than a lower resolution that needs to be upscaled

My friend who was checking out HDTVs has decided to avoid the current Pioneer as the summer update is releasing at 1080 native resolution (versus 1024 x 1024 I think of the current model). If most content is going to be 720p, not only is it a waste of money, but also should give inferior image quality to 720p native. And yet, if you stick with 720p, if you DO get the option of 1080. you're missing out.

One of these days, like the 'good old days', humanity will get back to defining standards and sticking to them...

 

[London Geezer]

One of these days, like the 'good old days', humanity will get back to defining standards and sticking to them...

Back?

When was there ever a standard for humanity, for anything? Hell, people still stick to absolutely stupid imperial measurements, instead of using the metric standard, which is by any accounts the easiest and most used system used in the world...