CUDA 11.2

[blueberry]

@jcuda Same old story. CUDA 11.2 has been released, and it is probably compatible as-is, but JCuda 11.1 looks for specific version 11.1 of Nvidia's native libraries, whereas Linux has 11.2.whatever, soft linked as 11.2 and 11.

[jcuda]

Thanks for the heads-up, I'm currently downloading and had a short look at the release notes. It indeed looks like there are not sooo many changes (although I also thought that for 11.1...), certainly something to tackle during the holidays.

[jcuda]

A rant.

I am and will never be able to understand how on earth somebody can define a function cuGraphExecExternalSemaphoresSignalNodeSetParams that receives a CUDA_EXT_SEM_SIGNAL_NODE_PARAMS that contains an array of CUDA_EXTERNAL_SEMAPHORE_SIGNAL_PARAMS objects where each has the structure

typedef struct CUDA_EXTERNAL_SEMAPHORE_WAIT_PARAMS_st {
    struct {
        struct {
            unsigned long long value;
        } fence;
        union {
            void *fence;
            unsigned long long reserved;
        } nvSciSync;
        struct {
            unsigned long long key;
            unsigned int timeoutMs;
        } keyedMutex;
        unsigned int reserved[10];
    } params;
    unsigned int flags;
    unsigned int reserved[16];
} CUDA_EXTERNAL_SEMAPHORE_WAIT_PARAMS;

and still think that this could be even remotely acceptable, in any way, for any purpose.

This is just plain, utter crap.

I've spent a considerable amount of my spare time, for 12 years now, giving my best to support the brain farts that NVIDIA emitted. But if somebody really ""wants"" (i.e. thinks that he has to) use something like this, he should use CUDA, and not JCuda (or maybe JavaCPP - they did it - yay!).

In the recent releases, CUDA and JCuda diverged considerably. Figuring out what can be supported in JCuda, and how, far too often lead to the answer "not at all". The effort for updates increased considerably. They throw in increasingly complex functionality, which is often not covered by samples at all. The changes that they make are arbitrary, extensive, and really, really, bad, along basically all dimensions of the term "bad" that I can imagine.

I'll try to do the update for 11.2 (although certainly not all features - and particularly, not this ridiculous "external graph execution semaphore" crap - will be supported). I might then do a final update for CUDA 12. But I just cannot afford this any more. JCuda is about to reach its end-of-life.

[jcuda]

And literally on the brink of an EOL announcement, https://blogs.oracle.com/javamagazine/programming-the-gpu-in-java is published, and my mood went from "I'll tell NVIDIA where they can shove it" to "Oh dear, maybe I should really try to do this update...". I'll try. I'll really try, although I don't exactly know why.

[blueberry]

Maybe they have been reading this thread :)

[jcuda]

So, it's hard to believe (and in the meantime, CUDA 11.3 is out), but I actually had another stab at the update for 11.2 today. At least, to some extent. A few new functions have been added. But I will simply not add some parts of the newer functionality (related to external semaphores and memory pools). If somebody wants this functionality in JCuda, just send a mail to thatWillNotBeCheap@jcuda.org.

Beyond that, I think a "reasonable" trade-off betreen usefulness+backward compatibility, and the time that I'm willing/able to invest, is to just do the minor updates (and bugfixes) with the new version, so that existing programs at least work with newer CUDA versions - which roughly mean that there are binaries available, and 99% of the functionality of CUDA is there, but some of the ... *ehrm* ... questionable ... functions like the aforementioned cuGraphExecExternalSemaphoresSignalNodeSetParams would throw an exception.

I'll finish the update tomorrow, including the update of JCudnn for cuDNN 8.1.1, and drop another note here.

[blueberry]

Great news! I think that the decision to concentrate on 99% of CUDA is right, because that new weird stuff might be too niche (if useful at all in JCuda context) to break the whole project.

[jcuda]

Thanks @blueberry for your encouraging words.

The update is done, for CUDA 11.2 and cuDNN (11.2) 8.1.1. The state is tagged as version-11.2.0-RC00, but corresponds to the current master.

[blueberry]

Hi Marco,

Here's the Linux build. It uses the latest version of 11.2 available in Arch archives, which is 11.2.2 (https://archive.archlinux.org/packages/c/cuda/) and the latest cudnn overall. Arch already contains 11.3 binaries, so I can build that too as soon as you update JCuda to 11.3.

jcuda-linux-11.2.zip

[jcuda]

Thanks for that quick reaction!

JCuda 11.2.0 is on its way to Maven Central, and will be available at

<dependency>
    <groupId>org.jcuda</groupId>
    <artifactId>jcuda</artifactId>
    <version>11.2.0</version>
</dependency>
<dependency>
    <groupId>org.jcuda</groupId>
    <artifactId>jcublas</artifactId>
    <version>11.2.0</version>
</dependency>
<dependency>
    <groupId>org.jcuda</groupId>
    <artifactId>jcufft</artifactId>
    <version>11.2.0</version>
</dependency>
<dependency>
    <groupId>org.jcuda</groupId>
    <artifactId>jcusparse</artifactId>
    <version>11.2.0</version>
</dependency>
<dependency>
    <groupId>org.jcuda</groupId>
    <artifactId>jcusolver</artifactId>
    <version>11.2.0</version>
</dependency>
<dependency>
    <groupId>org.jcuda</groupId>
    <artifactId>jcurand</artifactId>
    <version>11.2.0</version>
</dependency>
<dependency>
    <groupId>org.jcuda</groupId>
    <artifactId>jcudnn</artifactId>
    <version>11.2.0</version>
</dependency>

Thank you, @blueberry for your continued support and contributions!

[blueberry]

Thank you Marco for the great work and generous sharing!