As AnandTech put it best in this 2009 article:

In render ahead, frames cannot be dropped. This means that when the queue is full, what is displayed can have a lot more lag. Microsoft doesn't implement triple buffering in DirectX, they implement render ahead (from 0 to 8 frames with 3 being the default).

The major difference in the technique we've described here is the ability to drop frames when they are outdated. Render ahead forces older frames to be displayed. Queues can help smoothness and stuttering as a few really quick frames followed by a slow frame end up being evened out and spread over more frames. But the price you pay is in lag (the more frames in the queue, the longer it takes to empty the queue and the older the frames are that are displayed).

As I understand it, DirectX "Swap Chain" is merely a render ahead queue, i.e. buffers cannot be dropped; the longer the chain, the greater the input latency. At the same time, I find it hard to believe that the most widely used graphics API would not implement such fundamental functionality correctly. Is there a way to get proper triple buffered vertical synchronisation in DirectX?

  • 3
    \$\begingroup\$ OpenGL actually doesn't support triple buffering, even in the various platform-specific binding APIs and extensions, and it's both the older API and (counting mobile) the more widely used API. You shouldn't be surprised by graphics API being awful. Instead, assume they suck and then be pleasantly surprised in the instances where they don't. \$\endgroup\$ Commented Jul 2, 2013 at 19:53

3 Answers 3


As mh01 says, DirectX does support a form of triple buffering. It works around one downside of double buffering, which is that with double buffering and vsync on your frame rate drops from 60 to 30 to 20 (assuming 60Hz refresh rate). There's nothing in between because you don't have a free back buffer to render to until after the vsync. Triple buffering allows it to have up to three frames on the go at once:

  1. The frame being displayed - the front buffer.
  2. The frame to be displayed at the next vsync (one back buffer).
  3. The frame currently being rendered (the other back buffer).

I think what the Anandtech article is saying is that if your game is rendering frames much faster than the vsync it would reduce latency if D3D could drop a previously rendered frame. That is, if while one frame is being displayed you manage to render both the next frame and the one after (so you run out of back buffers) then D3D could choose to drop the oldest of those two frames and proceed to render the next frame immediately.

What D3D actually does is to block waiting for the vsync, which reduces CPU and GPU load, but increases latency a little. And it can be worse than that because what D3D does when the CPU is producing frames faster than the GPU can render them is to let the game queue up three frames worth of GPU commands, and then block, giving you more latency.

That three frame CPU queue can be avoided either in the game software (the easiest option is issuing and waiting for queries with the appropriate delay in between), or with driver settings (it's there on Nvidia drivers, not sure about AMD).

The main advantage of that three frame command queue is that if you have more than one GPU then when there's more than one frame in the queue you can give one to each GPU and improve performance. It can also help smooth out an uneven frame rate a bit.

  • \$\begingroup\$ So you're basically saying AnandTech is correct, D3D's "Triple-Buffering" is a render ahead queue that smoothes out the framerate but increases latency with every additional buffer. It causes the program to wait when the queue is full rather than continue rendering. What is the option of NVIDIA drivers you're talking about? \$\endgroup\$
    – Asik
    Commented Jul 3, 2013 at 1:44
  • \$\begingroup\$ The setting is called "maximum pre-rendered frames". forums.anandtech.com/showthread.php?t=2322148 \$\endgroup\$
    – Adam
    Commented Jul 3, 2013 at 23:38
  • 1
    \$\begingroup\$ This answer was not entirely accurate even at the time it was written. The flip presentation model was added to D3D9Ex in Windows 7 and D3D11 in Windows 8. This model is capable of flipping between 3 (or more) buffers and always displaying the latest; it relies largely on the Desktop Window Manager. NVIDIA has added this to their recent drivers for Pascal GPUs and calls it "Fast SYNC." \$\endgroup\$ Commented Aug 18, 2016 at 20:38

Yes, see D3DPRESENT_PARAMETERS structure and the description of the "BackBufferCount" member for D3D9, or DXGI_SWAP_CHAIN_DESC for DXGI, for example.

Note that this is not a render-ahead mechanism as described by the AnandTech article; this is managed by a separate API, such as IDirect3DDevice9Ex::SetMaximumFrameLatency or IDXGIDevice1::SetMaximumFrameLatency. Note that in both cases the BackBufferCount (or BufferCount for DXGI) is still set separately during device creation.

I'm not sure how AnandTech managed to get the impression that this wasn't implemented or that it was somehow different, as it has been documented in every DirectX SDK.

  • \$\begingroup\$ I'm afraid that doesn't answer the question. Yes, I'm aware D3D implements a queue of buffers, the question is whether this is a render ahead queue (i.e. buffers cannot be dropped and necessarily introduce latency) or a proper ping-pong setup where the program continuously bounces between two back buffers while waiting for the next vsync. The D3D documentation you link to suggests the former. \$\endgroup\$
    – Asik
    Commented Jul 3, 2013 at 1:43
  • \$\begingroup\$ Why do you assume the other method is "proper" ? There are downsides to what you're suggesting in terms of smoothness, which is what most game players care about. \$\endgroup\$ Commented Jul 3, 2013 at 6:38
  • \$\begingroup\$ I've edited this answer to clarify. \$\endgroup\$ Commented Jul 3, 2013 at 7:54
  • \$\begingroup\$ What are the smoothness downsides of triple buffering as compared with a 3-frame FIFO queue? I can't see how there are any, and unless there are then triple buffering is strictly better than a 3-frame FIFO queue. \$\endgroup\$
    – user57368
    Commented May 27, 2014 at 22:42

The behavior of the Direct3D swapchain has, traditionally, been a FIFO queue. Windows 7 addressed this problem in Direct3D 9 Ex by advancing the read target that the Desktop Window Manager uses for composition each time a frame is presented. It matters not how far behind the GPU is, the DWM always scans-out the most recent finished frame and drops late frames.

This is referred to by Microsoft as the Flip Presentation Model. It is available in Windows 7 in D3D9Ex devices if the Desktop Window Manager is enabled. In D3D11, this feature is part of DXGI 1.2 (Windows 8); it should be available in Windows 7 with Platform Update but I have had very limited success getting that to work.

For games that use neither D3D9Ex nor DXGI 1.2 in order to use the Flip Presentation Model, NVIDIA's recent drivers expose "Fast SYNC" on Pascal GPUs. This violates the D3D sequential presentation design and has to be enabled in the driver because it is not technically correct VSYNC behavior. NVIDIA touts this as a hardware feature unique to Pascal GPUs, but that simply is not true.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .