Earlier quoted context omitted.
OpenCL is all you need, and for the sake of a healthy (read: non-monopoly) GPU computing ecosystem you must insist on good OpenCL support! Having an additional CUDA backend is fine if you want, but AMD GPUs are often really strong in a level playing field, which is exactly what you want as a consumer. Basically no consumer ever benefitted from a monopoly, and GPU computing is very important. I've developed (as lead G…
It's not, though. The blas and fft libraries are not only much slower (less efficient for the claimed peak of the cards), but they're missing features. For example, gemms don't work on complex half precision in any opencl library I've seen. Batched modes are missing for some types, etc. For basic operations, they're sufficient. But it's hard to get behind libraries that AMD doesn't really control. The ship has sailed…
What I'm hoping is that people in a similar position to mine, where I could easily choose OpenCL since I was coding everything from scratch in basically C, choose OpenCL instead of CUDA.
It's completely possible in many cases, and I'm not the world's greatest developer or anything; twice I chose OpenCL over CUDA and both turned out great. Particularly the JIT model is very useful. Judge for yourself:
It's also very useful for cross-vendor GPU benchmarking, see https://www.indigorenderer.com/benchmark-results?filter=sing...