Threading
Author
I'm trying to create textures in seperate threads, thus, I need my d3d device to be used in a seperate thread. D3D debugging will complain if I don't use the D3DCREATE_MULTITHREADED flag when creating the device, but do I necessarily need to use this flag if I guarantee the texture will not be used until fully created?
You still need to use that flag. The device could be doing something completely different while you try to create the texture, and could cause all sorts of problems.
If you're going to be using any D3D interfaces in more than one thread, you need the D3DCREATE_MULTITHREADED flag.
If you're going to be using any D3D interfaces in more than one thread, you need the D3DCREATE_MULTITHREADED flag.
It is possible, with a little clever thinking, to split D3D-related resource loading into another thread without using that flag and still keeping D3D entirely in a single thread.
Check out the Coding for Multiple Cores presentation from GDC'06. I can't remember it off the top of my head, but I think its mentioned that D3DCREATE_MULTITHREADED can knock quite a hefty chunk out of your performance.
hth
Jack
Check out the Coding for Multiple Cores presentation from GDC'06. I can't remember it off the top of my head, but I think its mentioned that D3DCREATE_MULTITHREADED can knock quite a hefty chunk out of your performance.
hth
Jack
Author
Quote:Original post by jollyjeffers
Check out the Coding for Multiple Cores presentation from GDC'06. I can't remember it off the top of my head, but I think its mentioned that D3DCREATE_MULTITHREADED can knock quite a hefty chunk out of your performance.
I've read that. In fact, I've been taught by the guy (Dawson). He says not to use the flag. I don't like the flag, but D3D Debugging wants me to use it. Unless there is some way to load a texture without using D3D Device, deubugging will complain that the device is being used to multiple threads.
Evil Steve, are you sure? I've read some random posts online about ignoring the debug warning. I think the flag is used for trying to render from 2 seperate threads. Its hard to find info online.
anyways, thanks for the replies.
Quote:Original post by blaze02I was sure, I'm not any more [lol] That presentation doesn't mention ignoring that warning, but it does suggest passing a pointer to locked data to a worker thread for decompression / loading, which is something I never thought of.Quote:Original post by jollyjeffers
Check out the Coding for Multiple Cores presentation from GDC'06. I can't remember it off the top of my head, but I think its mentioned that D3DCREATE_MULTITHREADED can knock quite a hefty chunk out of your performance.
I've read that. In fact, I've been taught by the guy (Dawson). He says not to use the flag. I don't like the flag, but D3D Debugging wants me to use it. Unless there is some way to load a texture without using D3D Device, deubugging will complain that the device is being used to multiple threads.
Evil Steve, are you sure? I've read some random posts online about ignoring the debug warning. I think the flag is used for trying to render from 2 seperate threads. Its hard to find info online.
anyways, thanks for the replies.
I'd imagine it's not a good idea to ignore the warning however, despite what various Internet sources may say.
The DirectXDev mailing list is full of wisdom - run a search on it and you'll find lots of discussion about the pro's and con's of getting the API to handle multithreading or handling it manually...
A couple of choice posts from a search of my local DirectXDev archives:
Tom Forsyth seems to know everything, and he posted:
Supported by Chuck:
A couple of choice posts from a search of my local DirectXDev archives:
Quote:the application should primarily be concerned about the overhead incurred at each API entry point where we acquire a crit-sec before accessing member data, then release the crit-sec before returning to the application. This overhead is roughly 100 clock cycles or so. So, add that onto each estimate in the Accurately Profiling Direct3D Appendix documentation in MSDN to calculate a rough percentage. You should naturally be also be concerned about the time when two threads actually are in contention. Naturally, one thread will have to wait for the other, for some duration of time for such cases.
Tom Forsyth seems to know everything, and he posted:
Quote:In general, using D3D from multiple threads is a bad idea. It's also usually a waste of time. Only one CPU can talk to the driver at a time, so you're basically just spending lots of time handing a single mutex back and forth between CPUs.
I would see if you can keep all your D3D calls on one thread, and the rest of the game on the other thread. This is almost always the best way to do things.
Supported by Chuck:
Quote:Actually, we've had several games come through our performance labs that have thread sync as the top two of three hotspots in the application, causing ntdll.dll (where these routines reside) to take up significant portions of the CPU time. Using D3DCREATE_MULTITHREADED requires the API take a conservative approach and take a critical section on almost every call. It is much better for performance to not use this flag, and instead ensure that any place you are talking to D3D is via a single thread. Using your own critical section to pass resulting pointers off to worker threads for I/O is a good idea if done on a coarse level.
-Chuck Walbourn
SDE, Windows Gaming & Graphics
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
