Jump to content
  • Advertisement
Sign in to follow this  
chaoticbob

Barriers, Flushes and Ordering of Command Lists

This topic is 534 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi,

 

This question is in regards to the operations on a single graphics queue - not multiple queues. Would love some clarification on the example below.

 

Lets say I have two command list: cmdList0 and cmdList1. 

 

cmdList0:

  1. transitions TextureA from shader read to render target
  2. writes some stuff to TextureA 
  3. transitions TextureA from render target to shader

cmdList1:

  1. uses TextureA in some rendering operation

I submit both command lists at the same time ordered like this: ExecuteCommandList(2, [cmdList0, cmdLIst1]);

 

Knowing that command list execution can overlap, what's the expectation for the following:

  • Is there any type of execution dependency on cmdList0 by cmdList1 because of the transitions in cmdList0?
  • Alternatively, is there any type of execution dependency that's potentially caused by pipeline flushes when cmdList0 completes?
  • Should I use a fence between cmdList0 and cmdlist1 to force a dependency?

 

Thanks!

 

Share this post


Link to post
Share on other sites
Advertisement

Command lists will execute in the order they're submitted, so in your example there's no need for a fence between the two.

 

See the section "Executing command Lists" in the following link:  https://msdn.microsoft.com/en-us/library/windows/desktop/dn899124(v=vs.85).aspx

 

Edit:  Particularly, the part that applies to your question is "Applications can submit command lists to any command queue from multiple threads. The runtime will perform the work of serializing these requests in the order of submission."

Edited by WFP

Share this post


Link to post
Share on other sites

Command lists submitted on the same queue are executed sequentially. This means you can effectively treat them as if they were merged into one singular command list, with the exception that the currently bound PSO is reset at command list boundaries. So in your example, the transition barrier will ensure that the draw in cmdList1 won't start until the draw in cmdList0 has fully completed.

 

If you submit command lists onto multiple queues, then they may be processed simultaneously depending on the capabilities of the hardware. To ensure proper synchronization in the case of dependencies, you need to use a fence to make sure that work doesn't start one queue before work on another queue has finished.

Share this post


Link to post
Share on other sites
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!