3 ms·

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 exam

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 on opencl for Nvidia. It's not going to happen, and it's not worth holding out hope. At this point, cuda has improved at a much faster rate, and the support is much higher. It's just not worth building a new scientific computing product around opencl, since it's as portable as cuda at this point if Nvidia doesn't support it.

pixelpoet 7y ago
In principle there's nothing stopping people from developing similarly great libraries for OpenCL, which I would on the one hand expect to happen eventually, but on the other hand it's impossible to deny the existing achievements of Nvidia's software team. 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: https://indigorenderer.com https://indigorenderer.com https://chaoticafractals.com https://chaoticafractals.com It's also very useful for cross-vendor GPU benchmarking, see https://www.indigorenderer.com/benchmark-results?filter=singlegpu https://www.indigorenderer.com/benchmark-results?filter=sing...
pjmlp 7y ago
OpenCL was never that portable to mobile devices anyway, even though they are at the other end of the high-end GPU spectrum. iOS never went beyond OpenCL 1.0, and eventually Apple moved into Metal. Android never supported OpenCL, as Google preferred to push their C99 based dialect, Renderscript.

pixelpoet 7y ago

In principle there's nothing stopping people from developing similarly great libraries for OpenCL, which I would on the one hand expect to happen eventually, but on the other hand it's impossible to deny the existing achievements of Nvidia's software team. 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: https://indigorenderer.com https://indigorenderer.com https://chaoticafractals.com https://chaoticafractals.com It's also very useful for cross-vendor GPU benchmarking, see https://www.indigorenderer.com/benchmark-results?filter=singlegpu https://www.indigorenderer.com/benchmark-results?filter=sing...

pjmlp 7y ago

OpenCL was never that portable to mobile devices anyway, even though they are at the other end of the high-end GPU spectrum. iOS never went beyond OpenCL 1.0, and eventually Apple moved into Metal. Android never supported OpenCL, as Google preferred to push their C99 based dialect, Renderscript.