Thank you for all the responses from my previous threads. I have been successful in fully incorporating JCuda into my application and I am currently working on releasing the code to the public. The main objective is to release the code without the user having to install the cuda toolkit.
I am having an issue with linking the JCudaDriver-windows dll file. I added the dlls to my project and with the cuda toolkit install, I can use JCuda. I tried this on a laptop, which has not installed the toolkit, but has an NVIDIA GPU. Unfortunately, it was unable to load the dll file due to “UnsatisifiedLinkError: Can’t find dependent libraries”
I added the cuda.lib, cudart.lib, and cufft.lib to my project from my cudatoolkit v5.0 into the project. Am I missing anything to include in the project so I can link to the JCuda api? Also the laptop I’m running on has an NVIDIA GPU and the System32 folder contains the nvcuda.dll files.
I am going to try installing the latest NVIDIA drivers from the NVIDIA site (that way I’m not using the window’s installed drivers) and report back.
Thanks for any help with this. It has been making me pull my hair out for the past day or so as I try to get a good library loader working.
*** Edit ***
Quick followup:
Installed the latest gfx drivers from the support page and unfortunately no luck there.
I tried to use nm -g on the dll files but I am unable to view the library. Which compiler was used to create the windows dll’s? Thus far I have tried cygwin, mingw, and vs2010(not sure which compiler vs2010 uses…).
Admittedly, I have not yet tested whether this is possible, but I think it should be.
The JCuda driver dll was compiled with VS2010. The only (non-Windows) dependency for this DLL should be the “nvcuda.dll”:
C:\...>dumpbin /DEPENDENTS JCudaDriver-windows-x86.dll
Microsoft (R) COFF/PE Dumper Version 9.00.21022.08
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file JCudaDriver-windows-x86.dll
File Type: DLL
Image has the following dependencies:
nvcuda.dll
KERNEL32.dll
Summary
4000 .data
F000 .rdata
3000 .reloc
1000 .rsrc
1B000 .text
so there should be no additional dependencies to CUDA DLLs).
So if this DLL is present, either in a path that is visible via the PATH environment variable, or when it is in the same directory as the JCuda DLL, then it should be possible to load it.
In any case, you will not need any LIB files, but the DLL. Admittedly, I wonder where the nvcuda.dll on your laptop comes from, since I think that it is NOT installed together with the driver, but I’m not sure about this (do NOT delete or overwrite it in any case ;)). But… are you sure that the “nvcuda.dll” that is present on you laptop is the right version? A first quick check could be comparing the file size or modification date of the nvcuda.dll from you laptop, and the one from the system where everyhing is working.
I wanted to test this for myself for quite a while now. I don’t have a PC without CUDA toolkit here, but maybe I can find one in my office (otherwise, I’d have to uninstall all toolkits to test it, and re-install them afterwards… I’d like to do this only when it is really necessary). Maybe I can already run a quick check tomorrow, but can’t promise that ATM.
OK, I just ran a short test on a PC that does not have the CUDA Toolkit installed. It also had the nvcuda.dll, so it seems like this is really installed together with the driver. The test worked so far, so my first guess would be that the nvcuda.dll on your laptop might (!) have a wrong version, although I’m not sure about the versioning scheme for this file, and how it relates to CUDA versions.
I will do some more extensive tests with the dlls. And if indeed we do not need any lib files, then that is fantastic. It is encouraging to see that you were able to get a version working without the toolkit present.
I will report back with updates as I fiddle with things.
In doubt, I can upload the “mini-test” that I created, although it really does not do very much - just allocate some data to see whether it is working at all. Is this 32 or 64 bit Windows?
I am running 64-bit Windows. That would be helpful to have a basic test case from you to see if I can get it working on my box without the toolkit installed.
Also, what is your path variables set to and is there a good method for storing the jcuda libraries in a program. If I store them in the base directory of my application, I am able to load the library without a problem. Ideally I would like to store them in a lib directory. I have a workaround that enables storing them in the lib directory using the following:
...
addDir(".\\lib")
...
public static void addDir(String s) throws IOException {
try {
// This enables the java.library.path to be modified at runtime
// From a Sun engineer at http://forums.sun.com/thread.jspa?threadID=707176
//
Field field = ClassLoader.class.getDeclaredField("usr_paths");
field.setAccessible(true);
String[] paths = (String[])field.get(null);
for (int i = 0; i < paths.length; i++) {
if (s.equals(paths**)) {
return;
}
}
String[] tmp = new String[paths.length+1];
System.arraycopy(paths,0,tmp,0,paths.length);
tmp[paths.length] = s;
field.set(null,tmp);
System.setProperty("java.library.path", System.getProperty("java.library.path") + File.pathSeparator + s);
} catch (IllegalAccessException e) {
throw new IOException("Failed to get permissions to set library path");
} catch (NoSuchFieldException e) {
throw new IOException("Failed to get field handle to set library path");
}
}```
I’ll upload the mini-test later today, but there is really not much about it: A program that calls a few CUDA functions, together with the JCuda JAR and DLL. But we’ll see whether it works.
Concerning the native librar location: Indeed, the usual way is to set the java.library.path. But usually, this is done via the command line when starting the application, like java TheApplication -Djava.library.path=.\lib\
Is there any particular reason why you want to do it at runtime?
The main objective is to provide as simple an execution as possible. Simple run-as executable jar for my application.
Is there a way to specify run-time parameters into an executable jar, because that would be a good alternative.
Edit:
Never took a look at it before to be honest, and it does seem to be possible. In eclipse just configure the run configurations. So I will get rid of the adding libraries at runtime.
Edit edit:
Unfortunately when exporting the runnable jar it turns out that eclipse cannot package the VM arguments into the runnable jar, so I would have to package an executable file with the jar to aid in passing the correct paths.
I also have not yet used the “Runnable JAR” export of Eclipse extensively. But in any case, you might consider using a .BAT file to launch the JAR with the right parameters.
I have uploaded the simple test package temporarily at http://jcuda.org/_JCudaDeployTest.zip - you’ll see that it’s really very basic, but I’m also curious whether something like this will run without a toolkit. It should only require the nvcuda.dll, and if this is installed with the driver in a recent version, it should basically work. (For the runtime libraries, there may be additional dependencies, but we can figure this out later)
Did you gain any new insights with this? I really wonder whether such an archive would also work on a PC that never has seen an installation of the CUDA toolkit…
Seems the OP has vanished :). I’ll happily take over. Your JCuda 5.5 test runs fine on my clean Win7 sp1 x64 machine.
However, when i add some code to use the Runtime as well. It spits out
So driver api seems to work, runtime api needs something else?
*** Edit ***
Found it. Dependency Walker revealed that the JCuda runtime dll needs cudart64_50_35.dll. Which makes sense, but it is a pity that nvidia does not bundle it with the driver. I checked with nvidia, and devellopers are allowed to redistribute these dll’s with applications. Adding their location to the sytem PATH environment variable fixed my problems.
I think that this might become an increasingly important issue. Unfortunately, when I started with JCuda several years ago, I did not have enough knowledge about possible difficulties when trying to make such a libary really cross-platform. This refers to JNI itself, as well as some CUDA-specific things.
However, it should be possible to distribute JCuda, at least theoretically, in the way that you described - namely, by also including the required CUDA libraries. I think that when they are located in the same directory as the JCuda DLLs, it should not even be necessary to adjust the PATH.
And this seems to be the “normal” way to do so: I don’t own many computer games, but one of them uses CUDA, and also contains the required “cudartXX_YY_ZZ.dll”-library. This is not really surprising, since an application that is compiled for a particular CUDA version can not run with an arbitrary (different-versioned) CUDA DLL. (Although there seem to be different mechanisms used for the driver- and the runtime API…).
I have not yet tried to deploy an application that uses the Runtime API on a machine that was freshly set up (the test mentioned above used the Driver API), but it’s good to hear that it worked for you without major problems.
No problem, Marco. Glad I can help you for a change!
Did a quick test by removing the dll’s from my path and placing them next to the JCuda dll’s, like you suggested. That seems to work too. And it is a lot cleaner! To be sure they weren’t somewhere else on my path, I deleted the dll’s and the test broke again. So placing them there was definitely the solution.
All this also applies to the npp-dll’s by the way, although bundling those with JCuda would make the download ~130MB bigger :verzweifel:.
Yes, the size could be an issue, of course. But JNpp is not part of the “core” JCuda package, and I think that there are few (if any) developers who use JNpp at all, and probably only for more “experimental” stuff, where depolyment is not so critical anyhow. For “core” JCuda, some feedback shows that there are real applications using it, so it’s good to have a basic idea how it may be deployed together with all required libraries.
To be sure they weren’t somewhere else on my path, I deleted the dll’s and the test broke again. So placing them there was definitely the solution.