Jump to content
  • Advertisement
Sign in to follow this  
andhow

Multithreaded DirectX, but not really

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

I have a situation where I may or may not need to use the D3DCREATE_MULTITHREADED behavior flag, and I cannot find enough information from the MSDN documentation. First, for everyone who will say "you don't need multithreading in games" because they think I'm a newb, yes, I do, its for doing file i/o, heavy frame-independent computation, and other blocking operations. Things are loaded as needed (aka no loading screen) so obviously the above operations need to happen during gameplay, but not in the main thread. With that out of the way.... The IDirect3DDevice9 is used in multiple threads, so that would initially indicate that the D3DCREATE_MULTITHREADED behavior flag is necessary. However, the device is never actually accessed simultaneously from both threads (the synchronization occurs at a higher level and is therefore unnecessary). So my question is this: does the D3DCREATE_MULTITHREADED flag affect more than just sychronization but perhaps usage of Thread Local Storage or something else? Microsoft APIs tend to have odd (but I suppose efficient) thread requirements like "PeekMessage can only be called in the thread that created the HWND". Based on the SDK, it only mentions a critical section and possible performance loss (due to contention), which would make me think that if you sychronize the device yourself, then you don't need the flag. Does anyone know whether or not sychronizing access to the device is sufficient to drop the D3DCREATE_MULTITHREADED flag? Thanks

Share this post


Link to post
Share on other sites
Advertisement
If you're doing the synchronisation yourself, I don't think you'll need the multithreaded flag. Certain D3D funcions can only be called from the thread used to create the device (E.g. Reset()).
If I were you, I'd try it with the multithreaded flag, I doubt it'll make much of a performance impact. Then you could try removing that flag later on and see if it all still works.

It might be worthwhile keeping D3D calls to one thread. You could implement a sort of render queue, so other threads can post messages into the render threads queue, and the render thread will make all of the D3D calls for you. That keeps things tidier, and I believe that's what a lot of multithreaded renderers do.

Share this post


Link to post
Share on other sites
I've never noticed any performance problems from setting the multithreaded flag. The debug libraries send a warning if you don't set it in a threaded application. You could just set it on for extra safety if it doesn't make things slower...

Share this post


Link to post
Share on other sites
Thanks for the replies. Thats what I was hoping to hear. If all that flag does is wrap calls in a global CRITICAL_SECTION, then I'm fine. Anyhow CRITICAL_SECTIONs are supposed to be extremely fast in no-contention situations, so the overhead of using D3DCREATE_MULTITHREADED shouldn't be bad even if its not needed.

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!