0

I have imported the following libraries in Gradle:

compile group: 'org.jcuda', name: 'jcuda-natives', version: '0.9.2'
compile group: 'org.jcuda', name: 'jcublas-natives', version: '0.9.2'
compile group: 'org.jcuda', name: 'jcublas', version: '0.9.2'

and copy pasted JCublasSampleexample from JCuda page.

Unfortunately, I am getting the following error:

Creating input data...
Performing Sgemm with Java...
Performing Sgemm with JCublas...
Exception in thread "main" java.lang.UnsatisfiedLinkError: Error while loading native library "JCudaRuntime-0.9.2-windows-x86_64"
Operating system name: Windows 10
Architecture         : amd64
Architecture bit size: 64
---(start of nested stack traces)---
Stack trace from the attempt to load the library as a file:
java.lang.UnsatisfiedLinkError: no JCudaRuntime-0.9.2-windows-x86_64 in java.library.path
    at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1867)
    at java.lang.Runtime.loadLibrary0(Runtime.java:870)
    at java.lang.System.loadLibrary(System.java:1122)
    at jcuda.LibUtils.loadLibrary(LibUtils.java:143)
    at jcuda.runtime.JCuda.initialize(JCuda.java:422)
    at jcuda.runtime.JCuda.<clinit>(JCuda.java:406)
    at jcuda.jcublas.JCublas.initialize(JCublas.java:93)
    at jcuda.jcublas.JCublas.<clinit>(JCublas.java:81)
    ...

Of course, library is absent. The question is how to link it Maven/Gradle? Site says all DLLs should be inside JARs.

CUDA is installed, but I didn't specify it's version anywhere as I was to do with nd4j.

Dims
  • 47,675
  • 117
  • 331
  • 600
  • 1
    The section about [Using JCuda with Gradle](https://github.com/jcuda/jcuda-main/blob/master/USAGE.md#using-jcuda-with-gradle) contains an example script that does the native library stuff. (Sorry, I'm not familiar with Gradle - this was basically based on some snippets provided by contributors. If you encounter any issues, just open an issue in https://github.com/jcuda/jcuda-main ) – Marco13 Oct 28 '18 at 17:29
  • This didn't work for me and shouldn't as far as I understand. The code is intended to determine machine architecture and OS version at compile time and compute correspondent Maven coordinates. This was not needed for me as I just hardcoded the coordinates. I didn't know about `classifier` parameter and didn't add it, but nevertheless, the code didn't work. I think it also won't work with Maven, because nobody creates `lib` directory and put DLLs to there. – Dims Oct 28 '18 at 18:13
  • 1
    For maven, the required information is determined via the profile in the parent POM: https://github.com/jcuda/jcuda-parent/blob/master/pom.xml#L41 This is then used to figure out the *actual* dependency for the platform, e.g. https://github.com/jcuda/jcuda/blob/master/JCudaJava/pom.xml#L33 . The important point here may be: The `jcuda-natives` artifact does **not** contain the native libraries. The JAR that contains the native libraries is identified via the classifier, for example `jcuda-natives-0.9.2-windows-x86_64.jar`, as in http://central.maven.org/maven2/org/jcuda/jcuda-natives/0.9.2/ – Marco13 Oct 28 '18 at 18:36
  • I found that your code contains explicit lines to copy DLLs out of resources into temporary folder (LibUtils.java:247) and it works and DLLs appear in place. Unfortunately, DLL itself (JCublas-0.9.2-windows-x86_64.dll) has unsatisfied dependencies... – Dims Oct 28 '18 at 18:51
  • 2
    This usually means that the installed CUDA version does not match. You may check the output of `nvcc --version` to see the installed version. (The update of JCuda for CUDA 10 is on its way, just in case. Maybe I have too many "spare time projects" for my available "spare time" :-/ ) – Marco13 Oct 28 '18 at 20:54

1 Answers1

2

It was my fault: cublas DLL of correct CUDA version was not in the PATH. DLL of JCublas was loading successfully without any Gradle tricks, because code was copying it into tmp directory froume CLASSPATH. Simultaneously, error message was not informative, suggesting me to look for problems in other place and also Gradle example was confusing.

Summarizing what is required: to have CUDA of the same version as JCublas installed (and PATH correct) and required "native" JARs on classpath.

Dims
  • 47,675
  • 117
  • 331
  • 600
  • A side note: The error message says *"Stack trace from the attempt to load the library as a file:*", and shows a stack trace. But there also is **another** stack trace from the attempt to load the library as a resource. (This is mainly to have the option to manually place the natives (i.e. the DLLs) into the same directory, so that they are loaded from there. This should no longer be necessary now, because the libraries are unpacked from the JAR, but may sometimes be helpful for debugging and development). This other stack trace should say something like "could not load dependent libraries". – Marco13 Oct 29 '18 at 13:09