Jump to content
  • Advertisement
Sign in to follow this  
Evil Steve

Debug D3DX uses 22 threads on a dual core CPU?

This topic is 4575 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 recently upgraded my AMD 64 to an AMD 64 X2; a dual core CPU. I've been trying to work out what on earth D3DX is doing. It seems to create 22 threads to handle a call to D3DXCreateTextureFromFileInMemoryEx, but only on this dual core system. I've tried using SetThreadAffinityMask() to force it to only use one core, but that still results in a bunch of threads being created. I'm guessing that there's these threads being created, because I get 22 of these lines when the function is called: The thread 'Win32 Thread' (0xd50) has exited with code 0 (0x0), each one with a different thread ID. I'm loading a bitmap image (24-bit), and my texture format is D3DFMT_A8R8G8B8, so there should be a minimum of conversion going on, certainly not enough to merit 22 threads. Creating all those threads is actually making the code over 16 times slower on my dual core system (0.163 seconds on my AMD64 X2 3800 vs 0.010 seconds on my AMD64 3500). I'm using the April 2006 SDK (Same effect with the February 2006 SDK), with the debug runtimes and the debug output bumped up to maxiumum. If I use the release runtimes, it behaves as expected, and doesn't create any extra threads. Has anyone else come across this before? Anyone know what D3DX is doing behind the scenes?

Share this post


Link to post
Share on other sites
Advertisement
That is very, very interesting behavior. I have a quad-core Intel machine, so it would be very interesting to determine what is happening on this hardware. Do you have a benchmarking utility set up, so that maybe we can compare?

I would definitely escalate this by emailing directx@microsoft.com. Hopefully they have something to say about it, whether it is a bug in D3DX or some other explanation.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by Evil Steve
I recently upgraded my AMD 64 to an AMD 64 X2; a dual core CPU. I've been trying to work out what on earth D3DX is doing. It seems to create 22 threads to handle a call to D3DXCreateTextureFromFileInMemoryEx, but only on this dual core system. I've tried using SetThreadAffinityMask() to force it to only use one core, but that still results in a bunch of threads being created.

I'm guessing that there's these threads being created, because I get 22 of these lines when the function is called: The thread 'Win32 Thread' (0xd50) has exited with code 0 (0x0), each one with a different thread ID.

I'm loading a bitmap image (24-bit), and my texture format is D3DFMT_A8R8G8B8, so there should be a minimum of conversion going on, certainly not enough to merit 22 threads. Creating all those threads is actually making the code over 16 times slower on my dual core system (0.163 seconds on my AMD64 X2 3800 vs 0.010 seconds on my AMD64 3500).

I'm using the April 2006 SDK (Same effect with the February 2006 SDK), with the debug runtimes and the debug output bumped up to maxiumum. If I use the release runtimes, it behaves as expected, and doesn't create any extra threads.

Has anyone else come across this before? Anyone know what D3DX is doing behind the scenes?





Try doing it without DEBUG and see what the difference is. There might be a ton of monitoring processes added (and even more with the multiple cores involved).

Share this post


Link to post
Share on other sites
I can think of a few things they could be doing. Generating MIP maps -- perhaps one per thread. Mixing sound (if you're also doing that in your program). Doing file I/O (as I/O completion port handlers). I wouldn't worry about it, unless you know for a fact that this has some bad effects.

Also, do you think it spawns the threads in parallel, or could it be creating them one at a time and then retiring them (a la IOCP without the thread re-use part)?

Share this post


Link to post
Share on other sites
Quote:
Original post by hplus0603
I wouldn't worry about it, unless you know for a fact that this has some bad effects.

Personally, I would dig into it based on the 16x speed decrease alone.

Share this post


Link to post
Share on other sites
Quote:
Original post by circlesoft
Quote:
Original post by hplus0603
I wouldn't worry about it, unless you know for a fact that this has some bad effects.

Personally, I would dig into it based on the 16x speed decrease alone.


Giving the fact that this is only in debug mode should mean the end result either way wouldn't be much of an issue unless he plans heaven forbid, release what he's making in debug mode, but this is very interesting none the less.

I had a test run on my friend's dual core machine, and I didn't notice extensive thread generation. I wonder what could be the cause.

Share this post


Link to post
Share on other sites
Yeah, it only does this with the debug runtimes installed (D3D runtimes, not D3DX). I haven't tried with the release D3DX runtimes, I'll try that when I get home.

All 22 threads are comming from this one function call, I'm using the debugger to stop over the function call. The function doesn't generate any mip-maps, and the data is all in a memory buffer (no disk access). I've no idea how the threads are getting used (In parallel or whatnot).

I'll try knocking up a very simple test app when I get home, just something basic to duplicate the functionality.

Thanks for the replies,
Steve

Share this post


Link to post
Share on other sites
Not having a multi-core/cpu set up I cant really test it (I only ever get 1 of those messages you quoted), but if you break on that particular call - does the VStudio 'threads' window contain anything useful?

I don't know if it'll pick up threads related, but not directly created, by your application. Maybe you can get some more details as to what they're upto and/or what they're doing?

Cheers,
Jack

Share this post


Link to post
Share on other sites
Ok, I have a test ap up and running. It's only creating 4 threads this time, I don't know why - I'll look into this in a bit.

This version takes 0.000243 seconds on my AMD64 3500, and 0.011224 seconds on my AMD64 X2 3800, still a fairly big difference.

Again, it only happens with the debug DirectX runtimes, not the release runtimes. Changing the D3DX library from debug to retail doesn't make any difference.

You can download the test project as a VC2005 workspace Here. You'll need to run it in the debugger to check the threads created of course.

Share this post


Link to post
Share on other sites
Ok, I ran it on a quad-core Intel 3.2ghz machine and a single-core AMD 2600 machine. The results were generally the same (around 0.0008). These profiles are in no way robust, but they do give us an idea what machines are experiencing this behavior. So it seems that multi-core Intel machines do alright with it.

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!