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?

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).

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.

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

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.