What is the difference between DXGI_SWAP_EFFECT_DISCARD and DXGI_SWAP_EFFECT_SEQUENTIAL?

Question

I have difficulty understanding the difference between those two values of the DXGI_SWAP_EFFECT enumeration. MSDN documentation states:

DXGI_SWAP_EFFECT_DISCARD

Use this flag to specify the bit-block transfer (bitblt) model and to specify that DXGI discard the contents of the back buffer after you call IDXGISwapChain1::Present1. This flag is valid for a swap chain with more than one back buffer, although, applications only have read and write access to buffer 0. Use this flag to enable the display driver to select the most efficient presentation technique for the swap chain.

DXGI_SWAP_EFFECT_SEQUENTIAL

Use this flag to specify the bitblt model and to specify that DXGI persist the contents of the back buffer after you call IDXGISwapChain1::Present1. Use this option to present the contents of the swap chain in order, from the first buffer (buffer 0) to the last buffer. This flag cannot be used with multisampling.

So, Sequential is for displaying the contents of the chain "in order", in other words, in the same order as you called Present(). If so, is Discard not in order? Obviously an older picture should never be shown before a newer one. What kind of "most efficient presentation technique" would this flag enable then?

What if your monitor's refresh rate is 60fps and your code is able to render at 90fps. In this case, every one out of two Presents, the queue will be full. What happens then? Does Present block until the next vsync, capping your rendering rate to 60fps and introducing input lag, or does it discard the oldest buffer in the queue with the new one and allows you to go on with your rendering code as fast as you can? Do these DXGI_SWAP_EFFECT flags have any bearing on the issue?

Thanks.

Answer 1

Both techniques will always render frames in the correct order. The key difference is that once you have Present()ed enough frames to get back to a buffer you've already rendered, _SEQUENTIAL will guarantee that the contents are the same as what you presented. With _DISCARD, however, it could be garbage.

This relates to the larger "discard" semantics of modifiable surfaces in D3D. As an example, on some hardware architectures, rendering is done in "tile" chunks, with a lot of the intermediate color data stored in a cache. When a new frame is rendered, if the hardware needs to guarantee correctness for incremental rendering (i.e. _SEQUENTIAL), it has to flush this cache to main memory after the Present() call. If _DISCARD is used, however, this flush can be omitted, but main memory will not be updated with the cached values (they are discarded). If you are always re-rendering the entire scene every frame, this won't be a problem.