And once more: Right when I finished the update of JCuda for the CUDA Release Candidate, NVIDIA is publishing the final production version of CUDA 6.0 :twisted:
However, the update for the CUDA 6.0 Release Candidate has just been uploaded, and is available at http://jcuda.org/ . Unfortunately, the toolkit installers for CUDA version 6.0RC are no longer available at the CUDA download site, so this version will be of rather limited use. (In fact, the installers ARE still available, they are just no longer linked from the download site…).
[ul]
[li]The new functions for unified mermoy management of CUDA 6.0 have been added. [/li][li]The functions for setting stream callbacks are not yet supported, but will probably be supported in future versions[/li][li]Some minor changes are summarized in the change log at http://jcuda.org/changelog.txt[/li][/ul]
This version has been created in some haste, but should be working in general, although the unified memory functionality could not be tested yet.
Some additional notes:
[ul]
[li]The bindings for third party libraries or beta versions (JCudpp and JNpp) have not been updated for a while [/li][li]Bindings for the new “Xt” libraries are not yet available[/li][/ul]
These libraries will be updated/added as soon as possible, either together with the release of JCuda 0.6.0, or shortly after this release.
Version 0.6.0 of JCuda, intended for CUDA 6.0.37, has just been uploaded and is now available at http://jcuda.org/downloads/downloads.html . There have been no changes in the API compared to the release candidate.
Usually I’m trying to create a JCuda version also for the CUDA RCs, but I did not yet have a closer look at the 6.5 RC. I’ll probably do this early next week. From the description, it sounds like there are not sooo many changes in the API, so maybe it can be updated with little effort. (In fact, there are still some tasks pending from the previous update, and many other TODOs, but keeping the core up to date should have a higher priority than most of them)
Again, I was too slow: The final version of CUDA 6.5 is available. In the meantime, I did some bugfixing, so hope that I can do the update for the final version pretty soon.
I already downloaded it, and will try to update JCuda ASAP. There are some other “todos” in my list, but I think that (based on the release notes) there should not be toooo many changes to the API, so I hope it won’t take very long. The main unknown here is the new “cuSOLVER” library, which (depending on its complexity) might either be included in the first version of JCuda 0.7.0, or not.
There have not been many changes in the core API, but two possibly important news:
[ul]
[li]According to the NVIDIA CUDA Toolkit Release Notes, the CUDA Toolkit now no longer supports 32bit Windows or Linux as development platforms. Thus, the JCuda binaries will now only be offered as 64 bit versions
[/li][li]Support for the new CUSOLVER library has been added, and, surprisingly, it is called “JCusolver”. However, it should be considered as a “preview” version, because there are no examples and no detailed documentation available yet, and thus, it could not be tested extensively until now.
[/li][/ul]
The website has been updated. Particularly, the documentation has been restructured and extended with a section about debugging Kernels in JCuda applications with cuda-memcheck: jcuda.org - Debugging
JCuda has been updated to version 0.7.5. There have not been many changes in the API, only minor additions in some of the libraries.
The binaries of the latest version can be found at jcuda.org - Downloads , as usual.
Additionally, the GitHub repository with the source code of JCuda at https://github.com/jcuda is becoming “more official”: The source code will no longer be available as ZIP files on the website, but only at the GitHub repository from now on.
There are not yet all libraries available at GitHub, but the “core” libraries (JCuda, JCublas, JCufft, JCurand and JCusolver) are there, and the other ones will be added ASAP.
Additionally, I released an early version of jcuda-vec, because it was obviously used in other projects, and is “stable” in the sense that it does its job and has not changed for a while (although it may still change in future versions!)