Sign in to follow this  
Followers 0
Dr_Asik

What is the difference between DXGI_SWAP_EFFECT_DISCARD and DXGI_SWAP_EFFECT_SEQUENTIAL?

5 posts in this topic

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.
Edited by Asik
0

Share this post


Link to post
Share on other sites

Thank you very much. I am trying to understand the behavior of Present, i.e. under what circumstances does it block or not. This is what I could gather, please correct me if I'm wrong:

 

If SyncInterval is 0, Present always returns immediately. Rendering runs as fast as it can.

 

If SyncInterval is 1, two things can happen:

 - Either the swap chain is full, in which case Present blocks until the next vblank

 - Or the swap chain is not full, in which case Present returns immediately.

 

This effectively caps the framerate to the refresh rate of the display, but does not force the framerate to whole dividers of the refresh rate either, as described by Nvidia here. I am wondering in what circumstances is this behavior (framerate locked to whole dividers of the refresh rate, i.e. 15, 20, 30fps) observable as I can't seem to reproduce it just by playing with the buffer count and sync interval. Is this a Direct3D9 thing?

0

Share this post


Link to post
Share on other sites

Are you running in fullscreen? The behavior is different between fullscreen and windowed, since in windowed mode your backbuffer actually goes through the desktop composition system before it gets displayed on the screen.

0

Share this post


Link to post
Share on other sites

I tried both and didn't notice any difference in regards to Present's behavior.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0