Sign in to follow this  

Resource loading and multithreading

This topic is 3775 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'm not sure that this is the correct place for this thread but as it also involves DirectX I'll put it here. I currently have a problem when I load resources in my game. I have a lot of resources and also do some processing on them and all this takes time (20s on an average computer). I display a simple loading animation while this is happening and it gets updated by update calls in between different sections of the loading process. This all work fine. The problem is that as this is a single-threaded app the loading routine is causing the app to be unresponsive, as it's not processing any window messages. This was somewhat fine, until Vista. Vista is very quick to judge my game as unresponsive and the client area of the window goes blank, until the loading is finished. So I thought this was a good time to fix this problem, but I don't know how. I'm thinking about separating the message pump and the rest of the game into two threads. But is it possible to put D3D and the rest of DirectX into a separate thread? As far as I know the window message pump must be in the main thread, right? After a lot of reading I have found conflicting information about using D3D in anything but the main thread aswell. What I want to know is, is it possible to run D3D and the rest in another thread than the main one? And is this a good approach or is there a better or easier way. What I want is the be able to process window messages while loading resources, where some (most) of those are for D3D.

Share this post


Link to post
Share on other sites
It is told that using DirectX from more than one thread in parallel leads to havoc... even if the MULTITHREADED flag is set upon device creation. It is ok to access D3D from a different thread than the main thread, but due to the docs some critical functions like Device::Reset() have to be called from the main thread.

I have no personal experience on that topic, though. Brushing it up at the moment because I'm about to push resource loading to a parallel thread and I want to put the engine render pipeline at a second CPU core. Looks non-trivial.

Bye, Thomas

Share this post


Link to post
Share on other sites
It shouldn't be a problem to run D3D in worker threads, Managed DX can do it just fine.

But, if you are concerned about it, why not just "invert" your program? As in, run the UI in the main thread, and the resource loading in a worker thread. Should give the same result.

Share this post


Link to post
Share on other sites
Yes, I read about the problem, using D3D from several threads, too. But in my case, all use of D3D will be from 1 thread only, just not the main one. I wonder if D3D has a problem with that too?

Share this post


Link to post
Share on other sites
As long as you create your Device (and DX interface?) on that single other thread as well, this should work out fine. Just be sure to test on a dual core machine, even if you plan to only use D3D from a single thread. It's easy enough to have another thread start messing with D3D by accident, for me at least [smile]

Share this post


Link to post
Share on other sites
Just remember this:
Quote:
For these reasons, Direct3D is designed so that the methods IDirect3DDevice9::Reset, IDirect3D9::CreateDevice, IDirect3DDevice9::TestCooperativeLevel, or the final Release of IDirect3DDevice9 can only be called from the same thread that handles window messages.

Share this post


Link to post
Share on other sites
Ok, hope this isn't straying too far off topic...

Without using the slow MULTITHREADED flag, is it 'safe' to use different threads for different instances of D3D where:

1) Each thread would target a unique gfx card. (maybe 2 cards in PC)
2) Each thread would issue it's own create/reset etc, in fullscreen mode.

Should all threads share the same focus window?

Share this post


Link to post
Share on other sites
Evil Steve: yeah, that's the part in the doc that made me wonder if my idea really could work.

If it has to be on the same thread that handles window messages then how can I make the program responsive while loading resources and creating textures and such. The only option seems to be to somehow interrupt the resource loading to handle messages, but that could become very tricky. Especially with Vista beeing so fast to mark a program as "not responding".

Share this post


Link to post
Share on other sites
It's just these four functions that you have to call from the main thread. All drawing and presenting can still be offloaded to a different thread, as long as this thread is the only one calling D3D functions while it lasts.

Share this post


Link to post
Share on other sites
Quote:
This was somewhat fine, until Vista. Vista is very quick to judge my game as unresponsive and the client area of the window goes blank, until the loading is finished.
Maybe vista is more twitchy, but I've had several apps over the years show exactly the same symptoms on WinXP.

I solved it once by just iterating the message loop each time the progress bar was updated. Was a bit fugly at the code level but it did the job.

Quote:
Original post by Racky1275
Without using the slow MULTITHREADED flag, is it 'safe' to use different threads for different instances of D3D where:

1) Each thread would target a unique gfx card. (maybe 2 cards in PC)
2) Each thread would issue it's own create/reset etc, in fullscreen mode.

Should all threads share the same focus window?
If you're creating seperate devices then you should be fine - the multithreading flags are for a specific device being accessed across multiple threads; it's perfectly legal to have any number of devices active and in different threads or processes. They probably can't have the same focus window as they'll fight for who gets to draw.

Quote:
It's just these four functions that you have to call from the main thread. All drawing and presenting can still be offloaded to a different thread, as long as this thread is the only one calling D3D functions while it lasts.
Yes, pretty much. There were some really detailed discussions about this on the DirectXDev mailing list, but they're a bit tricky to find.

The crucial detail is that once you jump the boundary into D3D you're back to being serial/single-threaded such that having multiple threads pumping commands at it doesn't actually improve performance. This is especially the case for the number of locks you'll have to take out to ensure pipeline state when rendering. It just doesn't make any sense.

Look into using NULL-REF devices, loading into scratch pools and doing DMA copies of data between threads. Typically the expensive part of loading resources from disk is the latency that magnetic/optical drives have - so simply having your worker threads stream in BLOB's that are copied over to a central D3D thread that uses something like D3DXCreateTextureFromFileInMemoryEx() tends to get a lot of the benefit without too much effort.

hth
Jack

Share this post


Link to post
Share on other sites
Thanks Jack, it's great to have some input on this!
But it do now feel I might be stretching the boundaries of this thred if I ask a follow up question. So I'll start another... (Multithreaded fullscreen D3D for multiple cards)

Share this post


Link to post
Share on other sites

This topic is 3775 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.

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