3 ms·

You might be interested in knowing that OpenCL is merging with Vulkan's API[1], so there'll likely be a lot more support in the future. [1]:https://news.ycombi

by ktta 9y ago

You might be interested in knowing that OpenCL is merging with Vulkan's API[1], so there'll likely be a lot more support in the future. [1]:https://news.ycombinator.com/item?id=14383296 https://news.ycombinator.com/item?id=14383296

dogma1138 9y ago
The problem with OpenCL is the lack of well performing libraries, AMDs Core Math and Performance libraries are utter garbage still. If you can't do what Blender did and write everything from scratch including your primatives you'll be much slower than CUDA. But there is also a cost to it the Blender Cycles OpenCL code is nearly 5 times as big as their CUDA code and Cycles on OpenCL is still not at a feature parity with CUDA. The change in branding would likely not yield much for it.
- ktta 9y ago
  I haven't heard much about AMD's ACML and ArrayFire but I'm not surprised. On the other hand, I think you're underestimating the fact that OpenCL is an open spec and therefore has support from the FOSS world. CUDA has always been criticized for being closed source. Even though OpenCL doesn't get much praise, and actually get criticized a bit (I'm personally not a big fan because writing OpenCL code is like bending over backwards). It has a lot of potential with new libraries coming up[1] which can possibly make it atleast on par with CUDA. Once that happens, AMD's cost effective cards will put it in the race. [1]:https://github.com/clMathLibraries https://github.com/clMathLibraries
  - dragandj 9y ago
    [1] is actually AMD's old libraries. Judging by dev activity, it seems to be abandonware in favor of https://github.com/RadeonOpenCompute https://github.com/RadeonOpenCompute which is itself not ready for prime time.
    - dogma1138 9y ago
      ROCm is an amalgamation of a lot of things, some new some (very) old. It still relies on many pretty old libraries with questionable performance at best. The newer stuff is good but it's tailored to AMD GPUs, don't expect interoperability when it comes to any reasonable performance if you want to run ROCm OpenCL on NVIDIA or Intel hardware.
  - dogma1138 9y ago
    CUDA is tricky, it's not FOSS but it's also not completely "closed" source either it's just a restricted license. Many of the core libraries are not exactly open but these are primitives. If say cuDNN would become open source today there won't be any benefit from it, you won't be able to make it run faster than what NVIDIA has already achieved. As for the vendor lock well this is tricky, AMD also tried to vendor lock their initial compute APIs they've fallen back on OpenCL because it wasn't working. ROCm isn't exactly vendor neutral while it can run on nearly any OpenCL compatible hardware it's tailored and optimized for AMD GPUs which means it would run like utter garbage on anything else. It also supports interoperability with CUDA via the HIP compiler. And in all honest at least for scientific computing OpenACC (https://www.openacc.org/ https://www.openacc.org/) might make this argument irrelevant at least as far as general use code protability goes.

by ktta 9y ago

dogma1138 9y ago

The problem with OpenCL is the lack of well performing libraries, AMDs Core Math and Performance libraries are utter garbage still. If you can't do what Blender did and write everything from scratch including your primatives you'll be much slower than CUDA. But there is also a cost to it the Blender Cycles OpenCL code is nearly 5 times as big as their CUDA code and Cycles on OpenCL is still not at a feature parity with CUDA. The change in branding would likely not yield much for it.

ktta 9y ago
I haven't heard much about AMD's ACML and ArrayFire but I'm not surprised. On the other hand, I think you're underestimating the fact that OpenCL is an open spec and therefore has support from the FOSS world. CUDA has always been criticized for being closed source. Even though OpenCL doesn't get much praise, and actually get criticized a bit (I'm personally not a big fan because writing OpenCL code is like bending over backwards). It has a lot of potential with new libraries coming up[1] which can possibly make it atleast on par with CUDA. Once that happens, AMD's cost effective cards will put it in the race. [1]:https://github.com/clMathLibraries https://github.com/clMathLibraries
- dragandj 9y ago
  [1] is actually AMD's old libraries. Judging by dev activity, it seems to be abandonware in favor of https://github.com/RadeonOpenCompute https://github.com/RadeonOpenCompute which is itself not ready for prime time.
  - dogma1138 9y ago
    ROCm is an amalgamation of a lot of things, some new some (very) old. It still relies on many pretty old libraries with questionable performance at best. The newer stuff is good but it's tailored to AMD GPUs, don't expect interoperability when it comes to any reasonable performance if you want to run ROCm OpenCL on NVIDIA or Intel hardware.
- dogma1138 9y ago
  CUDA is tricky, it's not FOSS but it's also not completely "closed" source either it's just a restricted license. Many of the core libraries are not exactly open but these are primitives. If say cuDNN would become open source today there won't be any benefit from it, you won't be able to make it run faster than what NVIDIA has already achieved. As for the vendor lock well this is tricky, AMD also tried to vendor lock their initial compute APIs they've fallen back on OpenCL because it wasn't working. ROCm isn't exactly vendor neutral while it can run on nearly any OpenCL compatible hardware it's tailored and optimized for AMD GPUs which means it would run like utter garbage on anything else. It also supports interoperability with CUDA via the HIP compiler. And in all honest at least for scientific computing OpenACC (https://www.openacc.org/ https://www.openacc.org/) might make this argument irrelevant at least as far as general use code protability goes.