Why do things using CUDA often require older versions of compilers? E.g. ccminer. Try to make it, but it finds my modern gcc or clang too modern :(
Interactive GPU Programming, Part 1: Hello CUDA
21–30 of 30 posts
Re: Interactive GPU Programming, Part 1: Hello CUDA
#22I hope CUDA will get replaced by Vulkan merged with whatever core OpenCL features it still needs. Looks like Khronos are looking into converging them in some way: https://www.pcper.com/reviews/Graphics-Cards/Follow-Neil-Tre... CUDA unfortuantely is Nvidia's lock-in, so not a good way forward.
It took them being beaten by NVidia to actually care to add SPIR and C++ support to OpenCL.
Even now, while CUDA brings C++ compiler out of the box with their SDK, for OpenCL one needs to go to Codeplay and download their ComputeCpp Community edition compiler for SYSCL support, that might or not, support a given card. Hardly any better.
Re: Interactive GPU Programming, Part 1: Hello CUDA
#23I'd love something like this with Python and ctypes.
Re: Interactive GPU Programming, Part 1: Hello CUDA
#24Earlier quoted context omitted.
> unfortunately Nvidia is the only vendor that pays considerable number of people to develop the ecosystem. AMD basically says "get lost" by refusing to put more than a handful of people on the job of providing OpenCL libraries. Vulkan itself is developed and supported well, and it already can be used for compute as far as I know. But apparently there are some features that come from the OpenCL world that need to be…
The language and basic platform is not a problem. OpenCL was and is OK. However, the libraries are far and between. CUDA offers cuBLAS, cuFFT, cuDNN, cuSolve, etc. For OpenCL, even the decent BLAS library (CLBlast) had to be written by a guy who did it for free, while AMD's clBLAS is more or less stalled (and I never managed to build it on Linux in the first place), and that's it...
Re: Interactive GPU Programming, Part 1: Hello CUDA
#25Are there similar resources/tutorials for GPU programming/CUDA/openCL for pure Java?
http://nd4j.org/ - in built GPU garbage collector and everything.
If you want raw cuda primitives (not generally recommendended and hard to do right) - you can take a look at our javacpp based (we also maintain this) cuda bindings: https://github.com/bytedeco/javacpp-presets/tree/master/cuda
Unlike jcuda (which people typically recommend despite not being updated as often) we actually depend on this for the nd4j and deeplearning4j projects.
These cuda bindings are meant to be a 1 to 1 mapping to the cuda api as well. Hope this helps!
If you want a fairly small and minimalistic look at the underlying c code which uses cuda take a look at: https://github.com/deeplearning4j/libnd4j
All of this is published on maven central for you and runs on linux, windows and even mac. It's also the same api. All you do is switch the backend.
Re: Interactive GPU Programming, Part 1: Hello CUDA
#26In Polish, "cuda" means "miracles". Always cracks me up!
Re: Interactive GPU Programming, Part 1: Hello CUDA
#27Why do things using CUDA often require older versions of compilers? E.g. ccminer. Try to make it, but it finds my modern gcc or clang too modern :(
The cuda compiler itself (nvcc) is far behind the features of more recent compilers. For instance, c++11 is supported, but not the full standard. It will take a while before 14/17 are supported.
Re: Interactive GPU Programming, Part 1: Hello CUDA
#28From the perspective of a CUDA beginner, this doesn't seem simpler than writing CUDA with C(not C++, just C). If you're going to pick up CUDA, starting with C means you get the best tooling support and community docs. Not to mention that managing pointers and explicit types in C will genuinely help your understanding of how CPU-GPU works. If you already know Clojure, this is probably the best chance to extend somethi…
Re: Interactive GPU Programming, Part 1: Hello CUDA
#29Why do things using CUDA often require older versions of compilers? E.g. ccminer. Try to make it, but it finds my modern gcc or clang too modern :(
This requires nvcc and the device compiler to have exact knowledge of how the host compiler compiles every single construct (thing e.g. about alignment and padding in complex structures), and they must at least be able to parse the syntax of the host include files (which e.g. fails if the include files have C++11 syntax, but the device compiler only knows how to parse C++98).
Re: Interactive GPU Programming, Part 1: Hello CUDA
#30Are there similar resources/tutorials for GPU programming/CUDA/openCL for pure Java?
(Disclaimer: I created and maintain this library which is now apart of the eclipse foundation): http://nd4j.org/ - in built GPU garbage collector and everything. If you want raw cuda primitives (not generally recommendended and hard to do right) - you can take a look at our javacpp based (we also maintain this) cuda bindings: https://github.com/bytedeco/javacpp-presets/tree/master/cuda Unlike jcuda (which people typi…