CUDA 11.6

[jcuda]

This is just for tracking the release of JCuda 11.6 (overlap with 11.5 due to some delays, https://github.com/jcuda/jcuda-main/issues/43#issuecomment-1028474099 )

[jcuda]

@blueberry The update for CUDA 11.6.1 has been done.

Fortunately, there have not been many API changes:

• The runtime libraries did not contain any updates at all (except for the internal version numbers)
• The core library contained an addition of one function (this has been added to JCuda)
• A few functions for the CUDA "Graph API" have been added or modified, but this is not covered by JCuda anyhow

The release candidate is tagged as version-11.6.1-RC01 (note the 1 at the end), and corresponds to the current state in master.

[blueberry]

@jcuda Hi, I completely missed this update and came here to ask for any news towards 11.6.1. I will do the build ASAP (if possible, today). Thank you!

[blueberry]

Hi Marco,

Sorry for the delay, here's the linux build (on a recent Arch Linux): jcuda-linux-11.6.1.zip

[jcuda]

@blueberry That's great. I could try to do the release during the weekend then. But ... there is still that GLIBC issue from https://github.com/jcuda/jcuda-main/issues/45 - do you have any further insights on that?

[blueberry]

I don't know how to solve that. OTOH, it still isn't clear to me whether the users that have to run old LTS releases of Linux on the server would even want to use the latest CUDA release immediately, or one of the old releases of JCuda still covers them pretty well (11.3., 11.4, etc.).

[jcuda]

Admittedly, I haven't yet tried to do the compilation on a Virtual Machine. And if I set up a VM (or rather revive the one that I once created, I'd still have to dig into the details of GLIBC versioning.

Quick websearches like linux cmake glibc version bring some related questions, but the solutions (like the one at https://stackoverflow.com/questions/4032373/linking-against-an-old-version-of-libc-to-provide-greater-application-coverage ) don't look like a reasonable approach.

Maybe there's some simpler way. Just curious: When you start cmake-gui in jcuda-main and press 'Configure', it should list the configuration like that:

Do you see anything GLIBC-specific there? (Maybe that could be a place to sneak in an older version, without having to resort to that assembler-level solution that was described on stack overflow...)

[blueberry]

Unfortunately, there is no such thing here. TMost of other options seem to be same as on your system, some are similar, but not CMAKE_C_STANDARD_LIBRARIES nor anything that hints at being relevant.

[jcuda]

I'll try to have a closer look at some of the results from searching things like ~"linux cmake glibc version" - it's hard to imagine that there is not some magic flag or trick to solve this. But due to the constraints (time and technical ones), in doubt, I'd just use the binaries as they are.

[blueberry]

Hi Marco,

Any plans for releasing 11.6.1? There is now 11.6.2 in the Arch repositories (I didn't check compatibility with JCuda 11.6.1. yet).

[jcuda]

@corepointer In view of https://github.com/jcuda/jcuda-main/issues/45 , do you think that you have a chance to test the binaries from https://github.com/jcuda/jcuda-main/issues/44#issuecomment-1105188191 ?

Otherwise, I'll just release the 11.6.1 binaries as they are, to avoid further delays. (And if somebody has a problem with the binaries that is related to GLIBC: Contributions of more "portable" binaries are welcome...)

Regarding 11.6.2: If they take semantic versioning serious, then 11.6.2 should be backward compatible, and the binaries should work with CUDA 11.6.2 as well. This can be verified after the release of 11.6.1, and if there is any incompatibility, a dedicated 11.6.2 version can be released.

(I'll try to do the 11.6.1 release in the next days, preferably not later than Friday)

[blueberry]

Thank you!

[jcuda]

JCuda 11.6.1 has been uploaded and will soon be available under the usual coordinates:

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

Thanks @blueberry 🥇 for the continued support and for providing the Linux binaries!

(I'll try to have a look at whether there are any API changes for CUDA 11.6 "Update 2" that may justify a 11.6.2 release, but if there is nothing significant and if CUDA 11.6.2 is backward compatible with JCuda 11.6.1, then it may not be important to create such a release - my gut feeling is that CUDA 17 will come out soon, anyhow...)

[blueberry]

Thank you Marco. JCuda 11.6.1 works with CUDA 11.6.2, at least on my machine.

[corepointer]

@corepointer In view of #45 , do you think that you have a chance to test the binaries from #44 (comment) ?

Otherwise, I'll just release the 11.6.1 binaries as they are, to avoid further delays. (And if somebody has a problem with the binaries that is related to GLIBC: Contributions of more "portable" binaries are welcome...)

Regarding 11.6.2: If they take semantic versioning serious, then 11.6.2 should be backward compatible, and the binaries should work with CUDA 11.6.2 as well. This can be verified after the release of 11.6.1, and if there is any incompatibility, a dedicated 11.6.2 version can be released.

(I'll try to do the 11.6.1 release in the next days, preferably not later than Friday)

Sorry for the late reply. Better late than never :-P Status of the published binaries is "fails as expected" for Ubuntu 20.04. I test-compiled on Ubuntu 18.04 (the oldest Ubuntu release supported by CUDA 11.6.1) and this works fine in Ubuntu 18 and 20. I pushed the binaries to a git repo.

[jcuda]

Thanks for the update!

I'm now not entirely sure: I could take these binaries, essentially rename them to "11.6.1b", and create a new release from that. On the other hand, I'm not sure how crucial that is. For your current use-cases, is it OK to have these as local binaries, or do you "need" them as a Maven release?

More generally, of course, it would be nice to always have ~"the most portable version" in Maven. Assuming that NVIDIA keeps the pace of publishing CUDA updates, I assume that there will be a new version soon. When it comes out, would you be willing to contribute the Linux binaries then? The effort for building should be manageable, once you have the workflow/toochain set up. (An aside: For the release, I'd only need the binaries that should be copied to jcuda-main\output via the Maven build)

And @blueberry : I think you are usually testing the binaries that you provided against the test suite of neanderthal. Would it be possible to test these binaries (also in view of the Linux version and compatibility)? That would be great.

[blueberry]

And @blueberry : I think you are usually testing the binaries that you provided against the test suite of neanderthal. Would it be possible to test these binaries (also in view of the Linux version and compatibility)? That would be great.

Yes, of course.