Jump to content
  • Advertisement
Sign in to follow this  
CGEngine

DX12 Questions regarding swap chains in D3D12

Recommended Posts

Hi,

I'm reading https://software.intel.com/en-us/articles/sample-application-for-direct3d-12-flip-model-swap-chains to figure out the best way to setup my swapchain but I dont understand the following:

1 - In "Classic Mode" on the link above, what causes the GPU to wait for the next Vsync before starting working on the next frame?

2_classicgamemode.png

(eg: orange bar on the second column doesn't start executing right after the previous blue bar)

Its clear it has to wait because the new frame will render to the render target currently on screen, but is there an explicit wait one must do in code? Or does the driver force the wait? If so, how does the driver know? Does it check which RT is bound, so if I was rendering to GBuffer no wait would happen?

2 - When Vsync is off, what does it mean that a frame is dropped and what causes it?

Thanks!!

Edited by CGEngine

Share this post


Link to post
Share on other sites
Advertisement

1. The D3D12 runtime in conjunction with DXGI enforces this wait, by inspecting which RTV descriptors are being used.

2. The DWM (desktop window manager) that composes the desktop decides to drop frames if the app has presented multiple times since the last time it composed. If your app is covering the screen and using the DXGI_PRESENT_ALLOW_TEARING flag, or has called SetFullscreenState(TRUE), instead of skipping frames, the OS will tear instead of skipping frames.

Share this post


Link to post
Share on other sites

You can also make the wait explicit ( and put it at the front instead of at the end ) by using DXGI_SWAP_CHAIN_FLAG_FRAME_LATENCY_WAITABLE_OBJECT. This flag let you wait on a swap chain buffer to be ready to be filled for next frame.

Advantages are :

* You can use the cpu for other task while waiting instead of having a dead thread stuck in Present

* It reduce the latency ( mostly because you do not aggressively queue frames, but push them instead when they are needed, closer to the actual moment they gonna be display )

* You control the number of allowed queued frame explicitly and so the exact behavior ( depends if your cpu update+render + gpu frame  fit in one vsync or two basically ).

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  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!