Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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?

share|improve this question
3  
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. –  Sean Middleditch Jul 2 '13 at 19:53

2 Answers 2

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.

share|improve this answer
    
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? –  Asik Jul 3 '13 at 1:44
    
The setting is called "maximum pre-rendered frames". forums.anandtech.com/showthread.php?t=2322148 –  Adam Jul 3 '13 at 23: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.

share|improve this answer
    
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. –  Asik Jul 3 '13 at 1:43
    
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. –  Sean Middleditch Jul 3 '13 at 6:38
    
I've edited this answer to clarify. –  Darth Satan Jul 3 '13 at 7:54
    
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. –  user57368 May 27 at 22:42

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.