> 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.

Who actually supports opencl 2.0? ROCM, which AFAICT is AMD's new preferred platform, only supports opencl 1.2 also.

As 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.

hackintosh

It's not supported on Mac, and even on Linux seems to have weird limitations on specific kernel versions.

It also supports just a subset of AMD chips, which doesn't seem to include the actual AMD chips of the different Macs that I have available.

ROCm would count if it's mature enough so that the setup "just works" on any reasonable environment (in the way that it mostly is so for the major ML platforms on nvidia/CUDA) but it does not yet seem ready for that.

Last year, I supervised a student project that involved writing a Vulkan backend for a compiler that already possessed CUDA and OpenCL backends. While I recall that everything ended up working, it didn't run all that fast. The vast majority of the problems were related to the language used for encoding the shaders, SPIR-V.

Among the difficulties we encountered, I recall the need to use an offline optimiser to do trivial things like CSE and constant folding. CUDA and OpenCL will do this during kernel compilation, but Vulkan implementations seems to be designed as non-optimising (in order for loading to be faster, I assume). This is a perfectly understandable design, but it means it's a little more awkward to use. For direct programming (as compared to a compilation target), it's a lot more awkward.

Another issue was that basic Vulkan is very restricted, as I assume it's supposed to be usable on simple hardware. Additional functionality can be enabled through a collection of extensions. One particular problem I recall is that our code generator assumes the existence of general pointers, for example such that the same memory can be used for different types of values at different times. SPIR-V has/had a very strict notion of pointers, and no way to cast between different types without an extension, and that extension was IIRC not implemented by NVIDIA or AMD. There were lots of these kinds of issues.

In the end, Vulkan is usable for compute - after all, a single master's student (admittedly one who's very bright) managed to implement a Vulkan-targeting compiler backend in half a year. However, at the time I concluded that it's not as mature or as practical as CUDA or OpenCL, for reasons that seem perfectly solvable. However, for direct programming, the SPIR-V that is needed for shaders is completely inaccessible. It would be like writing machine code (not assembly) by hand. I assume graphics programmers have some layer on top to provide a sane interface, but since we were writing a compiler anyway, it wasn't a big deal for us.

Deprecated by Apple in regards native OS X support for OpenCL, important distinction.