CUDA DLL conflict: x86 & x64

Accelerated Computing CUDA CUDA Programming and Performance
1

Hello.

I found that there is a dll conflict under x64 system: if you try to run x64 app, it fails because it needs x86 version of the cudart.dll, but x64 version exists in the system path.

BTW, there are some ways to fix it. First and simple would be to copy CUDA runtime libraries to the system folder, which are protected by File System Redirection. Second and more correct and universal would be to give different names of runtime libraries for different platforms, e.g. cudart.dll (or cudart32.dll) for x86 applications and cudart64.dll for x64 apps.

2

i have a problem.

my cpu is x64.
i compile the sample from cuda sdk.
when i run the project.
it display this message:
“the application has failed to start because cudart.dll was not found. Re-installing the application may fix the problem.”

i think this problem related to your writings.
but i don’t know how to solve it.
Could u give me a hand??

3

CPU or OS? Because x86 OS can run on x64 cpu. Your problem’s solution is simple: just add the value of your CUDA_BIN_PATH to the PATH system environment variable.

4

OS: Windows XP Professional x64 Editiion

My CUDA_BIN_PATH :C:\CUDA\bin;C:\CUDA\open64\bin

i add it to the Path, but it doesn’t work,Q___________Q

(i remember adding “;”.)

OH NO~~~~

5

Do you have the 32-bit or 64-bit version of the CUDA toolkit?

I get the same problem when I try to run an x86 app. I have the 64-bit CUDA toolkit installed (which includes cudart.dll). As you said, there are several workarounds for this problem.

One option, which which has worked fine for me is to remove any version of CUDA, and install the 64-bit one. If you need to also compile for x86, then just copy the 32-bit toolkit to C:\CUDA\CUDA32\ for example. Then set up 2 environment variables:

CUDA_BIN_PATH_32 to C:\CUDA\CUDA32\bin

CUDA_LIB_PATH_32 to C:\CUDA\CUDA32\lib

(the CUDA_INC_PATH shouldn’t matter, as the include files are the same for both versions of the toolkit. I haven’t run into any problems using the 64-bit includes for compiling for x86)

Then when you compile for x86, make sure you call nvcc from CUDA_BIN_PATH_32, and set any dependencies to CUDA_LIB_PATH_32 in Visual Studio. The final step is to copy cudart.dll from the CUDA32\bin to your solution directory. There may be more elegant options, but this one works seamlessly with VIsual Studio.

You will need to recompile any CUDA source code when you switch platforms to rebuild the .obj, or else VS will try to link to .obj from the wrong platform.

If you have problems, just play with the settings in Visual Studio, you should be able to get it to work

Hope this helps.

In my opinion, cudart.dll x64 should just stay cudart.dl, and the 32-bit version be renamed cudart32.dll. Imagine otherwise in a few years, when 32-bit will be a thing of the past, seing files like: chess64.exe, myapp64.exe, mydll64.exe. 32-bit is slowly becoming obsolete, so the name should have the 32 suffix to indicate backwards compatibility, not vice versa.

I don’t think this will work. Open64 doesn’t have the files you need to build .obj used by VS.

6

I think that it isn’t good solution, because produces many copies of the cudart.dll and it makes CUDA update more difficultly. But as temporary solution it works, of course.

I agree with you.

7

Or, you can copy it to the 32-bit output directory. I definitely would NOT copy it into the system folder, or try to register it with regsrv32. It feels natural to have it in the output directory, since you can just copy the files from the output directroy to distribute the appplication. Of course, you would need to remember to update the files when getting a new version of CUDA.

8

Hi,

 I'm starting with CUDA using Vista 64 and VS2005. 

 I have installed drivers, tool kit and DSK for 64 bit platform. 

 I try to compile one sample form DSK to check whether mi configuration is OK or not, but I have the same problem mention in the post [url="http://forums.nvidia.com/index.php?showtopic=79412"]http://forums.nvidia.com/index.php?showtopic=79412[/url]

  In another way in this thread it show that you have installed the tool kit for 64 and 32 bit platform 

   Could you say me how to install it to avoid problem with the two tool kit to try to compile using the 32 bit version, please?

thanks in advance,
GUAN

9

Hi,

 I'm starting with CUDA using Vista 64 and VS2005. 

 I have installed drivers, tool kit and DSK for 64 bit platform. 

 I try to compile one sample form DSK to check whether mi configuration is OK or not, but I have the same problem mention in the post [url="http://forums.nvidia.com/index.php?showtopic=79412"]http://forums.nvidia.com/index.php?showtopic=79412[/url]

  In another way in this thread it show that you have installed the tool kit for 64 and 32 bit platform 

   Could you say me how to install it to avoid problem with the two tool kit to try to compile using the 32 bit version, please?

thanks in advance,
GUAN

10

Sorry

I had a problem with my IE, it is not my intention to send 3 time the post, so sorry

GUAN

11

Guan,

Try compiling the SDK samples for x64 and see if that works.

If you compile the project for 32-bit, but have the 64-bit toolkit, the .obj built by nvcc will be 64-bit, while the .obj s built by VS will be 32-bit, so this will cause an “different machine type” error at link time.

If all you need to do is build 32-bit apps, then I suggest going the easiest route, and uninstalling the 64-bit toolkit and installing the 32-bit version. IF you need to build for 32 and 64 bits, then you will need both versions of the tookit, and the tricks I mentioned above.
The toolkit installer will only let you install one version at a time, so you need to

  • install the 32-bit toolkit,
  • copy the C:\CUDA folder to a different location and rename it CUDA32
  • uninstall the 32-bit toolkit
  • install the 64-bit toolkit(make sure the 64-bit version is installed last)

Now that you have the 64-bit toolkit installed, and the files from the 32-bit, you can set up the environment variables and dependencies as I’ve described earlier. Basically all you have to do, is look through your project properties in VS, and wherever you see a CUDA_BIN_PATH or CUDA_LIB_PATH, add a _32.

Hope this helps.

12

Thanks for all Mr Nuke,

Installing CUDA and the SDK for 32 bit I made work the samples xD.

Now I have installed CUDA and SDK for both platform, I only need to check if for 64 bit this works too.
The unique thing that I don’t understand is why in the SDK for 64 bit there are samples for 32 bit !?.

Well, another question.
To translate a .cu make for 32 bit to 64 bit, what are the step to do ?

If I program a “normal aplication” the changes between two platform are too considerable. Changes SHE uses, Frame stack , … but in CUDA?

I don’t know if I only need to change the Eviorment Variables to point to the right address for compling and linking or it is something more.

Thanks,
GUAN

13

  1. The samples all share the same source code. All you have to do is choose to compile for x64 from VS(depending on which toolkit you have installed).

  2. Well, to port .cu to 64-bit all you have to do is follow the same steps you would follow when porting any application. If you follow good programming practices (use size_t for indexing, mainly), then your code should compile without warning on both x86 and x64.

Here’s how .cu files are compiled. nvcc takes the source file, makes a few runs around it, adds a bit of code, then passes it to a few other applications to add their code (cudafe, cudafe++, etc). Then the device and global functions are compiled into GPU machine code. That GPU code is the kernel that will be passed to the GPU. It is the same regardless of wether you are compiling for x86 or x64; the GPU only knows 32-bit. The host code that’s left is passed to the Visual Studio compiler. In this stage actual x86 or x64 code is generated. The 64-bit toolkit calls the x64 compiler, and the 32-bit toolkit calls the WIN32 compiler (other than cudafe crashing more often on x86, I haven’t found any other difference). The linking and everything else is left to VS.

So, if you set up your VS environment correctly, all you have to do is select WIN32 or x64 configuration and build. There is no need to “translate” .cu files

  1. I think this also answers your third question. All the changes that would occur from a “normal application” are actually there, and are handled by VS. The GPU has an independent instruction set, and couldn’t care less whether it is running on a 32-bit or 64-bit OS, so there is no “change” in GPU code; the GPU is the “same platform”.

Hope this answers your questions.

14

OK It is now more clear thanks, but I tried it and I had some problems with the compilation.

Is it allowd to attach images in the post?

Maybe, in this way I can explain better my steps and show you the error that VS gave me.

To test my CUDA configuration I am using QueryDevice sample form DSK. I have not started to program myself yet.

15

Source code, images, any file, anything you need to…

16

Ok

Then, first of all I put my Enviorment Variable:

32 bit platform
;***********************************************
CUDA_BIN_PATH = C:\CUDA\bin
CUDA_INC_PATH = C:\CUDA\include
CUDA_LIB_PATH = C:\CUDA\lib
NVSDKCUDA_ROOT = C:\Program Files (x86)\NVIDIA Corporation\NVIDIA CUDA SDK

64 bit platform
;***********************************************
CUDA_BIN_PATH_64 = C:\CUDA_64\bin
CUDA_INC_PATH_64 = C:\CUDA_64\include
CUDA_LIB_PATH_64 = C:\CUDA_64\lib
NVSDKCUDA_ROOT_64 = C:\Program Files (x86)\NVIDIA Corporation\NVIDIA CUDA SDK 64

My Path: C:\PROGRA~2\Borland\CBUILD~1\Bin;C:\PROGRA~2\Borland\CBUILD~1\Projects\Bpl;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;C:\Python25;C:\CUDA\bin

To follow a video that I found by Internet I copy the sample deviceQuery form the DSK 64 and copy all the director

Now, the test proyect is lacate in this address:
C:\Borrar\deviceQuery

Into the VS2005

File DeviceQuery.cu => Property => Custom Build Step => General

Command line= “$(CUDA_BIN_PATH_64)\nvcc.exe” -ccbin “$(VCInstallDir)bin” -c -D_DEBUG -DWIN32 -D_CONSOLE -D_MBCS -Xcompiler /EHsc,/W3,/nologo,/Wp64,/Od,/Zi,/RTC1,/MTd -I"$(CUDA_INC_PATH_64)" -I./ -I"$(NVSDKCUDA_ROOT_64)common/inc" -o $(ConfigurationName)\deviceQuery.obj deviceQuery.cu

In this step I don’t sure whether the Variable -DWIN32 must be keep or not.

In DeviceQuery => Property => Linker => General

Output File = $(ConfigurationName)/deviceQuery.exe
Additional Library Directories = $(CUDA_LIB_PATH_64);$(NVSDKCUDA_ROOT_64)/common/lib

In DeviceQuery => Property => Linker => Input
Additional Dependence = cudart.lib cutil64D.lib ; <= I changed cutil32D.lib for cutil64D.lib

If In the configuration Management I change the platfor to x64 it is imposible to reopen the property windows for DeviceQuery and deviceQuery.cu has you can see in the file attachment.

IF I try to compile with this configuration I have the next error.

1>Performing Custom Build Step
1>nvcc fatal : Visual Studio configuration file ‘(null)’ could not be found for installation at ‘C:/Program Files (x86)/Microsoft Visual Studio 8/VC/bin’
1>Linking…
1>LINK : fatal error LNK1181: cannot open input file ‘.\debug\deviceQuery.obj’
1>Build log was saved at “file://c:\Borrar\deviceQuery\Debug\BuildLog.htm”
1>deviceQuery - 1 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

I am using VS2005 Profesional Edition with SP1

Well This is my fight and currently I’m losing :(

GUAN
Error.png

ConfManager.png
ConfManager.png716×445 32.2 KB

17

This looks like a configuration problem. There is a post post that talks about it, but it doesn’t provide a solution.
Can you zip and attach your entire solution directory, so I can have a look at it? If you don’t want to attach the code, you can simply delete all the code in deviceQuery.cu. I am interested in the configuration.

18

Thanks for the link fix my problem xD

The mistake was in the instalation of VS2005. I checked VC for instaling and I thought that the 64 tools was instaling too. I now install the 64 bit tool and all is under wheel :)

Thanks for all Mr Nuke

GUAN

19

I’m glad your problem is fixed :). Happy CUDA programming!