Jump to content
  • Advertisement
Sign in to follow this  
obhi

DX11 [DX11]Map/Unmap on resources from a separate thread

This topic is 2702 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,
Given that the resource will be exclusively used by the CPU, is it ok to Map/Unmap a resource from a thread other than the rendering thread?
Also I have been told that Map/Unmap are done on the Immediate context so it is a bit confusing.
This is what I intend to do, I have 2 vertex buffers one updating while other one rendering. The update is done in one thread and rendering in a separate one. Buffer sync's has been completely managed so the only thing remains is it possible to do the cpu to gpu mapping while the immediate context is drawing? Or does that mapping has to be done in the render thread?

Thanks for any help
-obhi

Share this post


Link to post
Share on other sites
Advertisement
Ok I did my study and now I understand that it has to be done in the render thread itself. At-least doing in a deferred context has no meaning as the real mapping will be done in the immediate context.

Share this post


Link to post
Share on other sites
This isn't quite true. You can make calls to Map/Unmap on the deffered context thread. These calls will however be executed immediately as if you were using the immediate context. The effects of this call will be queued up within the deffered context command list and become universally visible once the command list is executed.

In the background the runtime/drive will be making a temporary allocation to store these resource modifications. You can avoid that temporary cost by only using Map on the immediate conext and by making sure the resource has no outstanding reference from previously unfinished drawing.

Holding a resource in the Map/locked state has no cost on other execution or drawing commands. You could have your main thread use the immediate context to map the resource and then use another thread to copy the data if that would be more efficient for you.

Share this post


Link to post
Share on other sites

This isn't quite true. You can make calls to Map/Unmap on the deffered context thread. These calls will however be executed immediately as if you were using the immediate context. The effects of this call will be queued up within the deffered context command list and become universally visible once the command list is executed.

In the background the runtime/drive will be making a temporary allocation to store these resource modifications. You can avoid that temporary cost by only using Map on the immediate conext and by making sure the resource has no outstanding reference from previously unfinished drawing.

Holding a resource in the Map/locked state has no cost on other execution or drawing commands. You could have your main thread use the immediate context to map the resource and then use another thread to copy the data if that would be more efficient for you.



Yes! you are right..you told me that in my last post but I forgot to read that one :P
Thank you for your reply.
One more question, will the temporary allocation from a Map/Unmap will be on system mem? I am currently building a multithreaded-graphics engine and I am wraping around the actual buffer implementations with my own classes. So I have made sure that I will delay the actual mapping to be done by the immediate context and the mapping call made on my dynamic buffers at any point of time from any-thread will itself return a system mem backed temporary buffer. I have taken care of the sync that will be needed. So is this a good approach?

Thanks again for any help.
obhi

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!