Video memory usage

In the past, you'd be mostly interested in resolution, because the framebuffer was by far the largest resource. Today the resolution is generally not a very big factor in the total memory consumption. Although with huge resolutions and excessive MSAA it could matter. At 2560x1600 8xMSAA you need 281MB for the back buffer, front buffer and depth buffer. Normal settings will of course only be a fraction of that. Like 1600x1200 4xMSAA is 66MB, which is not much on a 512MB card. The things you should look for when it comes to memory these days is texture settings and geometric detail.

 

multiple render targets too :O

 

AA does consume memory. The compression techniques used for MSAA are primarily designed to save bandwidth, not memory. AF doesn't take extra memory.

 

In DX9 you can't use MRTs with AA, but in DX10 you can, so you can imagine that AA memory usage can become very high in some cases.

 

I shudder to think of the time when devs will be using 8 MRTs with AA support with FP16+

 

I'm curious about what results you can get from that, and what can a 9600GT with 2GB do that a 4870 with 512MB can't.

 

What about tripple buffering, am I right in thinking it increases framebuffer memory usage by 50% (or is it 100%?). I can't stand tearing so I always have triple buffering enabled for the performance boost, so at 1080p with 4xmsaa, are we talking around the 100MB mark? That's decent chunk of memory on a 512MB card.

 

You only triple buffer the flip chain, not the AA buffers.

Also keep in mind that the depth buffer will need AA as well.

 

How much video memory does each driver bunny take up?

 

If I understand how it works, memory usage for triple-buffered 1080p with 4xMSAA breaks down like this:
Backbuffer: 1920*1080pixels * 4bytes * 4samples
Front buffer: 1920*1080pixels * 4bytes
Triple buffer: 1920*1080pixels * 4bytes
Depth: 1920*1080pixels * 4bytes * 4samples (assuming 32F)

Total: ~79MB.

If you're doing something like HDR, you're going to need an extra floating-point render target to render the HDR scene to - which can eat up another chunk of your memory (~65MB just for a 1080p, 64-bit, 4xAA HDR rendertarget).

Feel free to correct my calculations if I made a mistake somewhere.

 

You're close. For triple buffering at 1920x1080 w/ 4x MSAA @ 32bpp you need:
3x 1920x1080 32bpp "back" buffers
1x 1920x1080 32bpp MSAA color buffer
1x 1920x1080 32bpp (or whatever your depth format size is) MSAA depth buffer
1x 1920x1080 depth buffer (explained below)

Now, why do you need 3x back buffers *plus* the MSAA buffer? Because you need both the MSAA buffer and the buffer you're going to resolve to available at the same time at some point, hence you can't rely on the MSAA buffer as your third buffer.

Also, why do you need a point-sampled depth buffer? Because many render-to-texture effects are computed without anti-aliasing and apps often use the same depth buffer as the MSAA depth buffer (this is possible in DX9, but the debug runtime will complain).

I gave this equation a while ago:

Code:

Memory usage for AA on flip chain =
w * h * (((num back buffers) + (num AA samples)) * (bytes per pixel) +
              (1 + (num AA samples) * (depth buffer bytes per pixel)))

I hope that's somewhat comprehensible! Of course, this is a simple example that doesn't account for cases of multiple AA buffers or AA on other render targets.

For your example of 1920x1080 32bpp w/ 4x MSAA and triple buffering, you actually use up to 95 MB.

 

95MB? That's definitely a large chunk out of a 512MB pool, especially if HDR brings it upto as much as 160MB. Its easy to see how a modern game could eat through all of that if your gaming at 1080p or above.

 

By that time we'll probably also have 8x the memory available.

256KB.

Keep in mind that if you use HDR your HDR buffer replaces your regular MSAA buffer rather than being in addition to it, so it's only an addition of 32MB. If you do shader based resolves you don't need any extra resolve target. And in case you use built-in resolve, that buffer is going to be without MSAA, so it's another 8MB for a total of 40MB.

Well, that's correct if you're in fact triple buffering. But triple buffering is of questionable value anyway if you're doing MSAA since the MSAA buffer is a separate buffer anyway and you won't be stalling waiting for the flip but can continue rendering the next frame to the MSAA buffer anyway. Only when you need to resolve it to your backbuffer do you need to wait for the frontbuffer to become available, which would normally be pretty close to the end of the frame. So you effectively get something like "2.8x buffering" if it's only the last 20% of the frame that's on the backbuffer, provided that the game doesn't do anything stupid like clearing the backbuffer the first thing in the frame.

You example is not a universal figure. I wouldn't include a non-MSAA depth buffer in that equation because it's game specific. Not all games will need it.

So I would count it like this for a well written game at 1080p 4xAA:
Main color buffer: 1920*1080 * 4 * 4
Main depth buffer: 1920*1080 * 4 * 4
Front buffer: 1920*1080 * 4
Back buffer: 1920*1080 * 4

Total: 79MB

And with HDR:
Main color buffer: 1920*1080 * 8 * 4
Main depth buffer: 1920*1080 * 4 * 4
Front buffer: 1920*1080 * 4
Back buffer: 1920*1080 * 4

Total: 111MB

In addition to that there will be game specific render targets which are resolution dependent, including for example the non-MSAA depth buffer (+8MB), posteffect buffers (2-16MB). For deferred shading you can count on another 32-64MB depending on how many attributes you need to store and format choice.

 

Not insignificant, but compared to maybe 250MB static textures and 150MB vertex and index buffers it's not the most important factor in the equation.