• Advertisement
Sign in to follow this  

Debug D3DX uses 22 threads on a dual core CPU?

This topic is 4310 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
Quote:
Original post by circlesoft
Ok, I ran it on a quad-core Intel 3.2ghz machine

Stop saying that. You make me feel all envious. :)

Share this post


Link to post
Share on other sites
Well, this is odd. D3DXCreateTextureFromFileInMemoryEx() creates 22 threads, but D3DXCreateTextureFromFileEx() creates a mere 16 (Loading the same image as that sample app)

I'm still trying to find out what boosts it from 4 threads to 16 or 22 though.

Share this post


Link to post
Share on other sites
Quote:
Original post by ET3D
Quote:
Original post by circlesoft
Ok, I ran it on a quad-core Intel 3.2ghz machine

Stop saying that. You make me feel all envious. :)

Ok sorry. So I uhh...ran it on my old Apple II (porting it = [sick]), and it only made 1 thread and finished in a brisk 35.000 seconds. You should see this baby play FarCry:

Share this post


Link to post
Share on other sites
Are you some kind of masochist? As long as release mode works as expected, I'd rather not know the details of what the debugging code was doing, as long as the debugging code worked.

Share this post


Link to post
Share on other sites
Quote:
Original post by circlesoft
Does that beast have hardware D3D10 support? If so, chalk me up for one.

Jack

Share this post


Link to post
Share on other sites
Quote:
Original post by jollyjeffers
Does that beast have hardware D3D10 support? If so, chalk me up for one.

Of course! What kind of scam do you think I'm running here? It even comes with a free copy of Duke Nukem: Forever!

Share this post


Link to post
Share on other sites
Quote:
Original post by Mastaba
Are you some kind of masochist? As long as release mode works as expected, I'd rather not know the details of what the debugging code was doing, as long as the debugging code worked.
Yes [smile]

It's mainly because it's poluting my debug output - I can't see a damn thing. The last time I ran this app I counted over 150 lines of "The thread 'Win32 Thread' (0xe04) has exited with code 0 (0x0).". At least it's exiting with code 0 I suppose :P
EDIT: I just noticed I turned a bit of my code off. Wit hmy code running normally, it loads 5 screens in 256x256 chunks, over a 1024x768 resolution. That's 1320 lines in my debug output filled with crap >_<

I'm giving up for now. I've tried to replicate the same conditions in my test app and my main app, but there's not much more I can do without ripping the whole guts out. The only thing left to try is to just set up a device with predefined formats, and then try to create a texture and see what happens...

EDIT: Nope, that didn't work either. I still can't get both apps to have the same number of threads :/

Share this post


Link to post
Share on other sites
Quote:
Original post by circlesoft
Quote:
Original post by jollyjeffers
Does that beast have hardware D3D10 support? If so, chalk me up for one.

Of course! What kind of scam do you think I'm running here? It even comes with a free copy of Duke Nukem: Forever!


Duke Nukem: Forever! There goes any shreds of plausibility that this had!

Share this post


Link to post
Share on other sites
You could always write a debug logging system. My current system logs a ton of the stuff that Direct3D does and without all of the nonsense (it logs renderstate changes and values, texturestagestate changes and values, sampler state changes and values, texture creation and creation parameters, device creation, and optionally hardware enumeration. I'm still working on vertex/indexbuffers, shaders, and a few other things.) If you design the system around the Direct3D classes you can do a simple debug switch conditional to get rid of the extra logging:

#ifdef _DEBUG
class VertexBuffer
{
public:
HRESULT FreePrivateData(REFGUID refguid);
HRESULT GetDesc(D3DVERTEXBUFFER_DESC *pDesc);
HRESULT GetDevice(IDirect3DDevice9 **ppDevice);
// etc
};
#else
typedef IDirect3DVertexBuffer9 VertexBuffer;
#endif





Here's an example of my log:

Is obviously a LOT slower (since I'm using about 20 overloaded functions to get the string version of types) but its helps a lot when tracking down bugs.

Edit: Also, I want one of those Apples too!

Edit 2: Yeah, I just realized that my response isn't very helpful, since the debug isn't the problem its the thread situation, sorry!

[Edited by - Programmer16 on May 8, 2006 6:31:16 PM]

Share this post


Link to post
Share on other sites
Programmer16, thats a pretty neat set of log-file output. I've read a few threads about using the private-data stuff to get extra debugging information but never bothered to implement it myself.

Quote:
It's mainly because it's poluting my debug output - I can't see a damn thing. The last time I ran this app I counted over 150 lines of "The thread 'Win32 Thread' (0xe04) has exited with code 0 (0x0).".
I think you can turn it off.

I get the same crap with my copy of VS'05 pro, including loads of "symbol not found" messages at start up... but way back when Vista worked and I was using VSTS instead *none* of those messages ever showed up. It was just pure D3D/D3DX debug output.

VSTS cant be that different from VS'05 pro in this sense. Maybe just a different default setting somewhere...?

Cheers,
Jack

Share this post


Link to post
Share on other sites
Quote:
Original post by Programmer16
You could always write a debug logging system. My current system logs a ton of the stuff that Direct3D does and without all of the nonsense (it logs renderstate changes and values, texturestagestate changes and values, sampler state changes and values, texture creation and creation parameters, device creation, and optionally hardware enumeration. I'm still working on vertex/indexbuffers, shaders, and a few other things.) If you design the system around the Direct3D classes you can do a simple debug switch conditional to get rid of the extra logging:
*** Source Snippet Removed ***

Here's an example of my log: *** IMAGE REMOVED ***

Is obviously a LOT slower (since I'm using about 20 overloaded functions to get the string version of types) but its helps a lot when tracking down bugs.

Edit: Also, I want one of those Apples too!

Edit 2: Yeah, I just realized that my response isn't very helpful, since the debug isn't the problem its the thread situation, sorry!


Sorry for this being completely off the topic, but what is the name of the XP theme you're using? That looks nice.

Share this post


Link to post
Share on other sites
Turning the output off would be the easy way [smile] I'm more interested in what D3DX is doing really. I know I'm being stubborn [smile]. I'll try posting on the DX private newsgroup when I get home tonight.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement