I have a library written on top of CUDA 2.0 on a WinXP 32-bit platform.
I want to deploy this library on WinXP 64-bit platform having the same CUDA and VS version. (VS version being the same rules out any CRT related issues).
But I am wondering if this would work seamlessly OR Will I hit any CUDA related issues? I am not sure if CUDA libraries link statically or dynamically. I think it loads dynamically… So, In such a case, will a 64-bit CUDA library work fine with my DLL??
Diss what I found in the net: 64-bits could mean 2 things in Intel
Intel Xeon 64-bit – which can run native 32-bit apps as quick as any fast CPU
Intel Itanium – Runs 32-bit applications using a hardware-software combo emulator @ 400 Mhz speed.
I am not interested in Itanium at all…
I am interested to know what kind of dynamic linking problems can be expected @ run-time – especially CUDA related.
Since my app is linekd with 32-bit CUDA DLL, will it work fine on 64-bit machine with “CUDA on 64-bit” ??
Is it possible to isntall “CUDA for Windows XP” on a Windows XP 64-bit box? I understand that these 64-bit boxes NEED 64-bit drivers. So, Is it possible to install 64-bit driver for WinXp-64 and install toolkit and SDK from Normal WinXP??
I have the same problem here. Even if I cudafree all memory mallocs, my Apps stops working after it was run several times.( one after each other, not simultansiosly).
CudaMalloc gives back NULL and also cudaGLMapBufferObjectstarts to fail. If this happens no other Cuda App (even apps from the SDK) are working anymore and i have to restart.
I am now going to test it with cuda sdk apps, too. Howver even if it is a programming mistack in my app it should not affect proccesses which are called later when the faulty process is already gone.
Win32 bit App with 32bit cuda on a Windows XP x64 Platform.
If you don’t mind rewriting a bit of your app, you could take a slightly different approach…
I’m mostly a .NET programmer, so I interface all my CUDA dll’s into .NET via Interop Services. I’ve been doing something like the following:
Compile CUDA code to PTX
Embed PTX strings for various kernels into my .NET application.
Load whatever data is necessary onto the card using driver functions + .NET interop services
Call the kernel via the driver API + .NET interop services (there is function that you can just pass a string containing PTX instructions, which will run that kernel)
Retrieve results from card memory via driver API + .NET interop
This makes things a bit simpler, since you don’t need to recompile .NET apps for different platforms, and if you only compile your kernels to PTX code, that is portable as well (across any OS/architecture). You also get the benefit of .NET technology, so you can easily do things like retrieve/store data from a database or SOAP services, etc.
Thanks for your inputs. I have a long standing question on .NET… What is .NET? Why was it introduced? What problem does it solve? – Can you give a small gist? Appreciate your time on this.
I am not conversant with the driver API. I am more OK for the RunTime API. It saves time and its cool. I wont mind using cudaRT for production code. I dont see any change in speedups despite cudaMalloc, memcpy etc… But what you have said is a very very valid point for beginners.
Do you use GASS for your .NET - CUDA interoperability?
btw, I do the following to please my .NET master… -->
My DLL code is in C++ and my customer expects it in C#. So, I ship
A C# bridge DLL that bridges my DLL entry points with c# using Interop services