Is it possible to use jcuda with java 32 bit on a 64 bit computer?
I want to add cuda functionality to a larger application which runs that way (executes as 32 bit application also on 64 bit computers) and can’t be converted to java 64bit.
mogel is right, that should definitely possible. The important thing is that you use a 32bit JVM, but when you are already using other 32bit DLLs, then this should already be the case.
Note that in the latest version (0.6.0) of the “mavenized-jcuda”, the 64bit libraries accidentally slipped into the 32bit repository directory. So if you are using this, you’ll receive an error saying “Can’t load IA 32-bit .dll on a AMD 64-bit platform”. (I think MysterionRise is already about to fix that, according to this post). It should be possible to simply replace the DLLs with those from the archive at the download site: http://jcuda.org/downloads/downloads.html
If you still encounter problems, I can run another test with the 32bit version on a 64bit system on monday.
I am seeing this error: “Can’t find dependent libraries” when loading library “JCudaRuntime-windows-x86”
I just tried JCuda v. 0.5.5 with the same error as with the version 0.6.0.
The Cuda SDK (64bit version) is installed and PATH is up to date: PATH=C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v6.0\bin;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v6.0\libnvvp;
Yes, I am using 32bit JVM, with a lot of other 32 bit DLLs which are in the same folder (jre\bin) as all JCuda dlls.
it will help to cure your classpath errors easily. Also, I could try to help you with manual switch to 32 bit instead of 64 bits
*** Edit ***
You could try to text in 0.5.5 by cloning my project and manually set needed profile from my POM file (http://maven.apache.org/guides/introduction/introduction-to-profiles.html)
Or you could update pom.xml from my project to your needs by adding string true to 32 bit windows profile - windows-x86
and remove everything else in profile section, so, there is no any other profiles. It will remove flexibility from this project, but you could be able to build 32 bit JCuda app.
I don’t have classpath problems. All my java code compiles fine. The problem is only with loading native libraries. And since I did this so many times with other dlls (also my own jni code) then I can’t think of anything else to try.
Thanks for the offer, but I doubt your project could help me. I have never used maven and I have no experience with it, so it is a little bit too much for me to learn about it.
I use Eclipse, if you have an Eclipse project I would be happy to try it.
Jarek, this is what my project is solving - loading of native libraries
C’mon it’s 21 century, who writes project, that are tight with IDE? Maven could solve this cross-IDE issue.
Also, your doubts about Maven - you don’t need to learn too much. You just need to run several commands, that I’ve already type in README.md
Now that you mentioned the message “Can’t find dependent libraries”: I’m pretty sure that it will not work with the 64bit version of the CUDA SDK, and according to the path that you mentioned…
(Not being “Program Files (x86)” !) it seems that you are using the 64bit version of the SDK. The native JCuda DLL depends on the CUDA DLL, so when there is a mismatch between 32/64bit, it will most likely not work.
It might be a bit fiddly to install a 64bit AND a 32bit CUDA SDK on one system at the same time (but hope that it is at least possible to install a 32bit SDK on a 64bit system at all).
Yes, I did have to install the 64 bit version of Cuda SDK, because the 32 bit installer didn’t let me do it. So my first thought was the same as yours.
But then I opened code samples which come with the above SDK (for Visual Studio), and they compile as 32 bit programs. And all work fine (I can compile and run). So I was hoping that maybe the 64 bit SDK can also support 32 bit binding.
I know little about Windows libraries, so I could be wrong.
Ah, yeah. I finally got the challength. Since we assume by default in Java - Write Once, Run Everywhere paradigm. JCuda code will be same, but Cuda libs (will be different and the only way to try it is to install 64 bits on 32 bits and vice-versa). But it will create constraints on execution env as well
I spent some time comparing Cuda samples with JCuda Visual Studio projects, and I found one significant difference:
They use cudart_static.lib to link instead of cudart.lib
I am not sure if that is only allowed for programs (and not dlls). But I tried that and after recompilation of JCudaRuntime project I get one step further, there is no more error about dependent libraries, but now I see this error (when the JCudaRuntime library is being loaded):
Originally, it was not possible to statically link CUDA, but when there now is an explicit cudart_static.lib, I’ll have to take another look on that. In doubt, the library that the Runtime API depends on should only be cudart.dll, and this can actually be redistributed freely. I can upload it somewhere for you tomorrow, so you can give it a try - particularly now when installing the 32bit SDK on the 64bit machine does not work at all.