4 ms·

Their software things (drivers, compilers, apis) are laughable.

by Iwan-Zotow 7y ago

shaklee3 7y ago
I would add libraries to that list (cuda equivalent).
- pixelpoet 7y ago
  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 GPU dev in a 3-man team) two successful rendering applications with OpenCL on all 3 desktop platforms, it's not some kind of impossible task. More developers just have to stick their necks out and do it.
  - shaklee3 7y ago
    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.
- slavik81 7y ago
  They've been hiring developers to work on ROCm, so it seems they're investing in improving that situation.
fortran77 7y ago
Agreed! I posted this link here because I thought it was laughable, too. We do GPGPU programming (signal processing) and there's really no choice but Nvidia. I'd love there to be some competition, but AMDs developer tools and support are nothing compared to Nvidia. Plus Nvidia architecture is more "general purpose" than AMDs is for general computation

Their software things (drivers, compilers, apis) are laughable.

shaklee3 7y ago

I would add libraries to that list (cuda equivalent).

pixelpoet 7y ago
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 GPU dev in a 3-man team) two successful rendering applications with OpenCL on all 3 desktop platforms, it's not some kind of impossible task. More developers just have to stick their necks out and do it.
- shaklee3 7y ago
  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.
slavik81 7y ago
They've been hiring developers to work on ROCm, so it seems they're investing in improving that situation.

fortran77 7y ago

Agreed! I posted this link here because I thought it was laughable, too. We do GPGPU programming (signal processing) and there's really no choice but Nvidia. I'd love there to be some competition, but AMDs developer tools and support are nothing compared to Nvidia. Plus Nvidia architecture is more "general purpose" than AMDs is for general computation