Jump to content
  • Advertisement
Sign in to follow this  
Mr_Fox

Is it a good idea to give each cmdlistallocator a different fence?

This topic is 1056 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

It seems directx12 fence is just a uint64 in GPU, and any cmdlistallocator need to make sure all its cmdlists are finished in GPU to be able to call allocator reset, and we achieve this by inserting fence in cmdqueue.  So my question is:  Is there any extra cost to have bunch of different fences than just have one and do all sync based on proper global fence value? (since it will be much easier to programming if we could just give each cmdallocator a different fence, instead of calculating the proper fence value for one global fence).    

 

 

Share this post


Link to post
Share on other sites
Advertisement
I'd say go ahead and make multiple fences if that's easier for you. It really depends on the GPU and driver as to whether there's any noticable cost to having multiple fences, so you'd have to test to be sure. But I'd be surprised if it made any difference, since as you said it's just a uint64.

Share this post


Link to post
Share on other sites

Does "waitforsingleobject" used in conjunction with fences sleep the thread or just not return until the fence triggers?  I've been pondering the exact same questions in regards to fences, commandlists, and command allocators.

Share this post


Link to post
Share on other sites

Does "waitforsingleobject" used in conjunction with fences sleep the thread or just not return until the fence triggers?  I've been pondering the exact same questions in regards to fences, commandlists, and command allocators.

 

The Wait family of functions in the windows API should all suspend the active thread, meaning it won't do a busy wait (i.e. spinning until a flag is set to true for example).

Share this post


Link to post
Share on other sites

Thanks.

 

BTW does anyone know if it is wise to use more than one command list with an command allocator?  Or is it frowned upon?

 

Is there any scenario you're seeing which would actually require this? The only thing that would happen is that your command allocator would take up more and more space for each command list you use with it, and you'd want to keep this in mind for any following resets you'd do on this allocator. Remember that command allocators repurpose already allocated memory when they get reset, they do not free it until the allocators themselves get destroyed.

 

What you could do is record multiple smaller command lists on a command allocator which was previously used to record one large command list as to reuse memory optimally. It seems like this would complicate your allocator management quite a bit though, so you'd have to weight the pros and cons to see whether this would be worth it.

Share this post


Link to post
Share on other sites


Is there any scenario you're seeing which would actually require this?

No just musing on how to setup things.  I know warm allocators are faster than cold ones and I was thinking averaging usage over multiple lists would be easier than finding lists of a similar size for reuse.

Share this post


Link to post
Share on other sites

 


Is there any scenario you're seeing which would actually require this?

No just musing on how to setup things.  I know warm allocators are faster than cold ones and I was thinking averaging usage over multiple lists would be easier than finding lists of a similar size for reuse.

 

 

Smells somewhat like a premature optimization to me, wouldn't worry about it too much until you're actually seeing memory get wasted due to inefficient use of command allocators. You should be able to change the behavior of such a system fairly easily later on if you do run into trouble.

Share this post


Link to post
Share on other sites


Smells somewhat like a premature optimization to me, wouldn't worry about it too much until you're actually seeing memory get wasted due to inefficient use of command allocators. You should be able to change the behavior of such a system fairly easily later on if you do run into trouble.

Just trying to extend the advice given in this document on slides 28-29.

http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/Getting-the-best-out-of-D3D12.ppsx

 

It not about memory wasted its about speed/cpu utilization.  I don't consider it optimization... I consider it good design/architecting.  Besides I still wrapping my mind around the multi-threaded sample, and have time to muse until I start coding something major.

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!