LoadImage and Dual Core Processors

[wdolson]

Are there any known problems with LoadImage and dual core processors? I'm working on an update to a legacy game engine and we're seeing very slow speeds when graphics are loading on Intel dual core machines. Single core and AMD dual core machines have no problems, though I have seen some intermittant slowing on an AMD dual core, it's much less than what's been seen on the Intel dual cores.

I saw hessitations of less than a second on the AMD dual core doing things that some people said took 8-10 seconds on an Intel dual core. On a single core, the delay is almost imperceptible.

We're using a version of DirectX 9, though the libraries mostly start with d3xxxx, so they may be DirectX 3 compatible.

I'm somewhat new to DirectX, so I'm not sure of their nomenclature.

Is there a better way to be loading images? We're getting near our relaese date, so I can't do major surgery on the code at this point, but I'm hoping to be able to do something to improve this problem.

Bill

[bitshifter420]

If you are using LoadImage i have to assume you are using 24bit bitmap images for your game.
A .bmp has all kinds of extra crap it doesnt need inside.
All you really need to describe a 24 or 32 bit image is its width/height/bpp.
For this reason i use .raw images in my engine which include an 8byte header, like...

typedef struct {
   char magic[3];
   short width;
   short height;
   char bpp;
} ImageHeader;

[TheCPUWizard]

Issues such as this can only be resolved by carful measurements on the machine(S) exhibiting the symptom.

BitShifter's point is valid, but I have NEVER seen this type of performance issue because of it.

What IS COMMON is a failure to understnd the dynamics of a multi-core machine. The first thing to remember is that LoadImage is single threaded (will not utilize more than one core) and contains a mix of CPU and IO intensive operations.

1) In most cases the clock speed of a dual-core is lower than a single core. This will translate to a decrease in performance.

2) By having a second core, other programs are competeing using a different "dynamic" on a than on a single core. This means that the analysis MUST include ALL of the procsses that are running on the machine.

[wdolson]

Converting the files to raw image files at this point is not going to happen. We have hundreds of them and conversion is both impractical and it sounds like it's of little benefit.

I don't think it's a clock speed issue. I have tested this on some pretty old machines and they run fairly quick compared to the dual cores.

I wasn't sure if LoadImage was single threaded or not. I'm not that familiar with the inner workings of DirectX. The program does often load several images back to back. I guess it could be posible that one core tries to load one image and the other one gets stopped waiting for the drive resource to be freed. I don't know if another thread is being launched for each instance of loading an image.

Bill

[bitshifter420]

One thing to watch out for is the cxDesired and cyDesired arguments.
If they are not zero then the image is resized internally by LoadImage.
Also, if zero not to use LR_DEFAULTSIZE in the fuLoad parameter.
What i mean is the images should be the desired size before loading.
Im not sure if this applies for you but i thought it was worth mentioning.

[wdolson]

All the calls to LoadImage are identical:

hbm=(HBITMAP)LoadImage(NULL,path,IMAGE_BITMAP,0,0,LR_LOADFROMFILE|LR_CREATEDIBSECTION);

[Lindley]

We're using a version of DirectX 9, though the libraries mostly start with d3xxxx, so they may be DirectX 3 compatible.

Could be that's a reference to Direct3D, the graphics portion of DirectX.

[bitshifter420]

You can make a faster bitmap loader by not using LoadImage and GetObject.
These functions were designed to be easy to use and not designed for speed.
I would use CreateFile,ReadFile,Etc... to get the bitmaps data.
Usually if i need to load more than one texture i will prepare a buffer first.
This buffer should be large enough to hold the largest texture of the group.
This saves us from allocating hundreds of thousands of bytes each load.
So it would go something like...
InitTextureBuffer();
LoadSomeTextures();
KillTextureBuffer();

[MikeAThon]

You mention the LoadImage() function, but you also mention DirectX, so everyone here might not be talking about the same things. So ...

When you mention LoadImage(), are you talking about the GDI resource function named LoadImage() and described here: http://msdn.microsoft.com/en-us/library/ms648045.aspx . Look carefully to be certain.

Or maybe you are talking about something else, such as the IDXSurfaceFactory::LoadImage method, which creates a DirectX surface object (DXSurface) and is described here: http://msdn.microsoft.com/en-us/libr...08(VS.85).aspx

Let us know.

Incidentally, why do you think the issue is related to dual-core vs. single-core? Could it be something else on the suspect machine, such as a defective or outdated video driver or card?

Mike

[DrCoolSanta]

This might not be an exact solution for this, but you could try giving it yo others for beta testing. If it is going to be free then put it on CG or something or try to give it to your friends and all.
It is better to see the results of more people with totally different hardware than to check it with a few people you know, who 'may' have similar or outdated hardware.

The suggestion of converting it to raw might be possible if you can find some program that can do it from the command line. THa ways you can generate batch files which do the work for you.

[VladimirF]

Incidentally, why do you think the issue is related to dual-core vs. single-core?

I am with Mike on that.
You should first prove that this is a dual-core issue. Try to disable multi-processor mode as described here :

Go to start and click on run.
Type in msconfig.
Click on the BOOT.INI tab.
Click on the Advanced Options... button.
Check the /NUMPROC= box.
Click ok and restart.

If that fixes your problem, I would look for updates to Windows, DirectX and your drivers.

[wdolson]

You mention the LoadImage() function, but you also mention DirectX, so everyone here might not be talking about the same things. So ...

When you mention LoadImage(), are you talking about the GDI resource function named LoadImage() and described here: http://msdn.microsoft.com/en-us/library/ms648045.aspx . Look carefully to be certain.

Or maybe you are talking about something else, such as the IDXSurfaceFactory::LoadImage method, which creates a DirectX surface object (DXSurface) and is described here: http://msdn.microsoft.com/en-us/library/aa753508(VS.85).aspx

It's the GDI function. IDXSurfaceFactory isn't used.

Let us know.

Incidentally, why do you think the issue is related to dual-core vs. single-core? Could it be something else on the suspect machine, such as a defective or outdated video driver or card?

Mike

We have about 20 people on the team including the beta testers. All of the people with Intel dual core machines are seeing long pauses in display when the program needs to load images. One person has reported up to 8 second delays. Those with single core machines are seeing no perceptible delays. On a dual core AMD machine, I saw a slight pause of about 1/2 second.

People are reporting these delays with different hardware, some are desktops, some are laptops. The only consistent thing is the Intel Dual cores.

A couple of days ago I got feedback from someone who was able to shut off one of his cores in BIOS and he found delays that were similar to when both cores were active. This may be some kind of bus architecture problem.

Bill

[wdolson]

This might not be an exact solution for this, but you could try giving it yo others for beta testing. If it is going to be free then put it on CG or something or try to give it to your friends and all.
It is better to see the results of more people with totally different hardware than to check it with a few people you know, who 'may' have similar or outdated hardware.

The suggestion of converting it to raw might be possible if you can find some program that can do it from the command line. THa ways you can generate batch files which do the work for you.

This is a commercial product and there are about 20 people total between developers and beta testers.

I will look into other ways to load the images. I would prefer to keep the images in a standard format because users have been known to change images and I don't want to make it more difficult for them.

The current version of the game has a very active mod community, which is how this rewrite project got started. Some people from the IT world negotiated to ge the source code and set up a team to make a new version.

Bill

[VladimirF]

...I will look into other ways to load the images.

Before you do that, could we do a little experiment?
That 8-10 seconds delay - how many images were loaded at that time? How big are they?
If you write a simple program that ONLY loads those images - how fast (slow) would it be? For delays measured in seconds you could use GetTickCount() API.
Could you post one image that takes substantial time to load on your dual-core system here for others to test?
Have you noticed a problem with quad core?
The reason for my questions: I am very curious to see how LoadImage() might be affected by extra CPU cores. Obviously, no one here has ever heard about such problem.
Frankly, I suspect that your problem is elsewhere. Dual-core processors are known to expose synchronization issues that go unnoticed in a single-core environment.

[VladimirF]

I would like to volunteer and establish a benchmark here.
The following code loads the same 1920x1174 24-bit image (cloned) 10 times:

#include <stdio.h>
#include <tchar.h>
#include <windows.h>

int _tmain(int argc, _TCHAR* argv[])
{
	DWORD dwTickCount0 = ::GetTickCount();
	HBITMAP hbm0 = (HBITMAP)::LoadImage(NULL, _T("C:\\LoadImageTest0.bmp"), IMAGE_BITMAP, 0, 0, LR_LOADFROMFILE|LR_CREATEDIBSECTION); 
	HBITMAP hbm1 = (HBITMAP)::LoadImage(NULL, _T("C:\\LoadImageTest1.bmp"), IMAGE_BITMAP, 0, 0, LR_LOADFROMFILE|LR_CREATEDIBSECTION); 
	HBITMAP hbm2 = (HBITMAP)::LoadImage(NULL, _T("C:\\LoadImageTest2.bmp"), IMAGE_BITMAP, 0, 0, LR_LOADFROMFILE|LR_CREATEDIBSECTION); 
	HBITMAP hbm3 = (HBITMAP)::LoadImage(NULL, _T("C:\\LoadImageTest3.bmp"), IMAGE_BITMAP, 0, 0, LR_LOADFROMFILE|LR_CREATEDIBSECTION); 
	HBITMAP hbm4 = (HBITMAP)::LoadImage(NULL, _T("C:\\LoadImageTest4.bmp"), IMAGE_BITMAP, 0, 0, LR_LOADFROMFILE|LR_CREATEDIBSECTION); 
	HBITMAP hbm5 = (HBITMAP)::LoadImage(NULL, _T("C:\\LoadImageTest5.bmp"), IMAGE_BITMAP, 0, 0, LR_LOADFROMFILE|LR_CREATEDIBSECTION); 
	HBITMAP hbm6 = (HBITMAP)::LoadImage(NULL, _T("C:\\LoadImageTest6.bmp"), IMAGE_BITMAP, 0, 0, LR_LOADFROMFILE|LR_CREATEDIBSECTION); 
	HBITMAP hbm7 = (HBITMAP)::LoadImage(NULL, _T("C:\\LoadImageTest7.bmp"), IMAGE_BITMAP, 0, 0, LR_LOADFROMFILE|LR_CREATEDIBSECTION); 
	HBITMAP hbm8 = (HBITMAP)::LoadImage(NULL, _T("C:\\LoadImageTest8.bmp"), IMAGE_BITMAP, 0, 0, LR_LOADFROMFILE|LR_CREATEDIBSECTION); 
	HBITMAP hbm9 = (HBITMAP)::LoadImage(NULL, _T("C:\\LoadImageTest9.bmp"), IMAGE_BITMAP, 0, 0, LR_LOADFROMFILE|LR_CREATEDIBSECTION); 
	DWORD dwTickCount1 = ::GetTickCount();
	printf("%d\n", dwTickCount1-dwTickCount0);
	return 0;
}

The time is 0.109 - 0.125 seconds, consistent in both Debug and Release builds; so in 10 seconds I would load ~1,000 of such images.
My system is Core 2 Quad @3GHz, with fast hard drives.
Could you please test this on your system? And with your images?
My test image is attached.