4 ms·
I recently looked into GPGPU programming, and it seems to be a bit of a mess, which is surprising seeing how long it's been around and how much it is used. I th
by sorenjan 7y ago
I recently looked into GPGPU programming, and it seems to be a bit of a mess, which is surprising seeing how long it's been around and how much it is used. I think a large part of it is due to Nvidia using their strong position to hamper anything other than Cuda.
OpenCL 2.0 was announced in 2013, Nvidia added OpenCL 2.0 "for evaluation purposes" in 2017. I don't think they have final support yet.
OpenCL 2.1 uses the same intermediate language as Vulkan, SPIR-V. Nvidia does not seem to support this.
When OpenCL 2.2 was announced in 2017 Khronos said they were working on converging OpenCL and Vulkan compute, but OpenCL will remain separate. I think this means that they will both use the same SPIR-V backend to run shader code, but I don't know.
Khronos also has SYCL. The latest version, 1.2.1, was released a few days ago and uses OpenCL 1.2 as the backend. I'm guessing it doesn't use a newer version because of Nvidia's poor support for them, but AMD doesn't seem to support it well either.
Then there's a multitude of other libraries/platforms, like POCL, HCC, Acoran, that I don't know anything about but found mentions of. AMD has HIP which can convert Cuda to run on AMD hardware, so maybe Cuda is the best option for AMD as well?
I find it a bit of an embarrassment for the industry that it's this messy and complicated, and I don't see it getting better in the near future. It seems as if the proprietary Cuda is still the best option, and that's a big failure for everyone other than Nvidia. I don't want to use a proprietary language, but I want the code to run well on all the major platforms. I still don't know what to use.
https://www.khronos.org/sycl/ https://www.khronos.org/sycl/
http://portablecl.org/ http://portablecl.org/
https://gpuopen.com/compute-product/hcc-heterogeneous-compute-compiler/ https://gpuopen.com/compute-product/hcc-heterogeneous-comput...
https://www.codeplay.com/products/acoran/ https://www.codeplay.com/products/acoran/
https://gpuopen.com/compute-product/hip-convert-cuda-to-portable-c-code/ https://gpuopen.com/compute-product/hip-convert-cuda-to-port...
- dahart 7y ago> I don't want to use a proprietary language CUDA is mostly just limited C++. A couple of the interesting points in the release notes: “Added support for CUDA Virtual Memory Management APIs.; 10.2 now includes libcu++, a parallel standard C++ library for GPUs.” Those things make CUDA even easier to treat like regular C++. The language isn’t really the force keeping people in or out, the libraries & tools are. cuDNN, for example, is something you can’t get in OpenCL.
- rrss 7y agoWho actually supports opencl 2.0? ROCM, which AFAICT is AMD's new preferred platform, only supports opencl 1.2 also.
- keldaris 7y agoAs you've correctly identified, CUDA is the only sane default choice in the GPGPU world. OpenCL 1.2 is a viable distant second if you're sure you don't need any of the major CUDA libraries and value the portability aspect (not the same thing as performance portability, of course, but still). Finally, if you don't need strict accuracy guarantees and your application is mostly about graphics, you can get by with compute shaders. Everything else - POCL, HCC, ROCm, the various SYCL implementations, etc. you can safely ignore if you want something usable today, none of them are production ready or anywhere close to it.