Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


What is the difference between DXGI_SWAP_EFFECT_DISCARD and DXGI_SWAP_EFFECT_SEQUENTIAL?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
5 replies to this topic

#1 Asik   Members   -  Reputation: 136

Like
0Likes
Like

Posted 05 July 2013 - 02:36 PM

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, 05 July 2013 - 03:01 PM.


Sponsor:

#2 MJP   Moderators   -  Reputation: 11781

Like
3Likes
Like

Posted 05 July 2013 - 04:05 PM

It's pretty simple. If you use DISCARD, then as soon as you call Present the contents of the backbuffer are wiped away. If you use SEQUENTIAL, then the contents of the back buffer remain after calling Present. The order of what you see on the screen is the same in both modes, it's always the same order in which you call Present.

As for your refresh rate question, that depends on what you pass as the SyncInterval parameter of IDXGISwapChain::Present. If you pass 0, then the device never waits and always presents to the screen as soon as the GPU is ready to do so. If you happen to present outside of the VBLANK period then you will get tearing. If you pass 1, then the device waits until the next VBLANK period to flip buffers. So in your 90fps scenario, the device would then effectively be locked at 60Hz since that's the fastest that the display can output to the screen. If you pass 2, then the device waits for the 2nd VBLANK period which would cap you at 30Hz.



#3 Asik   Members   -  Reputation: 136

Like
0Likes
Like

Posted 05 July 2013 - 04:28 PM

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?



#4 Asik   Members   -  Reputation: 136

Like
0Likes
Like

Posted 09 July 2013 - 10:56 AM

Anyone?



#5 MJP   Moderators   -  Reputation: 11781

Like
0Likes
Like

Posted 09 July 2013 - 03:32 PM

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.



#6 Asik   Members   -  Reputation: 136

Like
0Likes
Like

Posted 09 July 2013 - 03:39 PM

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






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS