Triple Buffering takes ram?

[tigersty1e]

I always play games with vsync turned off, but some games sometimes have bugs and set vsync to always on, so I've always had triple buffering ticked on in my ati control panel.

But I've read somewhere that ticking it actually takes up space in the video card ram.

Can anyone confirm this?

 

[Scali]

Yes, normally you have two framebuffers. The one that is currently displayed on screen, the 'frontbuffer', and the one the next frame is being rendered to, the 'backbuffer'.
At the first vsync after it's done rendering, the buffers are swapped, and the next frame will be rendered into the new backbuffer.

With triple buffering, you introduce a second backbuffer, which takes up extra video card memory.
The advantage being that you don't have to wait until the vsync after a frame has completed rendering. You can start rendering in the second backbuffer immediately after the first one is completed.

 

[Ben90]

I don't believe adding an extra framebuffer will add too much extra RAM needed as if my math is correct a 1920x1200x24bit framebuffer is only about 7MB. Unless you have a lowend card without a lot of memory I think that 7MB is worth the tradeoff for the advantages of triple buffering.

What Scali said is completely correct, and a more in-depth look can be found here:
http://www.anandtech.com/show/2794/1

 

[Scali]

I don't believe adding an extra framebuffer will add too much extra RAM needed as if my math is correct a 1920x1200x24bit framebuffer is only about 7MB.

Yes, however, we don't use 24-bit framebuffers (three byte alignment is nasty).
So in this scenario you'd have 32-bit pixels, which comes down to about 9 MB.
And in the case of HDR, you might have 32-bit float per pixel, so that would give you about 35 MB for a framebuffer.

I think there can also be cases where both backbuffers are multisampled surfaces (if you leave multisample resolve to the hardware), which would mean it would blow up by the amount of AA you apply... eg 4xAA would lead to about 140 MB.
Although I suppose any reasonable implementation would resolve AA directly after rendering, and then store the resolved result in the backbuffer.

 

[BFG10K]

I don't believe adding an extra framebuffer will add too much extra RAM needed as if my math is correct a 1920x1200x24bit framebuffer is only about 7MB.

You're forgetting Z/stencil along with AA and FP render targets.

 

[Scali]

You're forgetting Z/stencil along with AA and FP render targets.

You don't need multiple z/stencil surfaces in most cases.
The z/stencil surface doesn't need to be displayed on screen, so it can be re-used as soon as a frame has completed rendering.

In most cases you would allocate only a single z/stencil surface, and make it as large as the largest rendertarget that you will be using (the size doesn't have to match 1:1), and then you re-use that single surface for all rendertargets (including render-to-texture operations).

In fact, same goes for FP targets as for AA resolve... you can do the tonemapping to a regular surface in the triple buffer, so you only need one 'working copy' of an FP/AA rendertarget, and thee regular 32-bit framebuffers.

 

[Ben90]

Thanks for correcting me Scali/BFG. Learn something new everyday.