5 ms·

Could we get an expert to weigh in on the state of OpenCL. It seems like AMD and Intel are shifting away from OpenCL other GPGPU languages such as ROCm and DPC+

Could we get an expert to weigh in on the state of OpenCL. It seems like AMD and Intel are shifting away from OpenCL other GPGPU languages such as ROCm and DPC++.

pjmlp 3y ago
DPC++ is Intel's own thing on top of SYCL, which relies on OpenCL drivers, basically long story short, what happened after Khronos realized shipping source code and C99 dialect wasn't really what most researchers were keen on using for their work.
pixelpoet 3y ago
Not sure if having two commercial OpenCL apps[0] makes me an expert, but the practical reality is that OpenCL works just great today, even on latest Apple platforms. It's not a lot of work to do a little testing and tuning on the 3 main vendors. News of OpenCL's demise is greatly exaggerated. [0] https://glaretechnologies.com/ https://glaretechnologies.com/
- rwbt 3y ago
  What version of OpenCL do Apple platforms support? Also, is OpenCL also deprecated like OpenGL on Apple?
  - my123 3y ago
    it's 1.2, macOS only, and marked as deprecated
- jsheard 3y ago
  Did you figure out a way to interop OptiX with OpenCL, or do you just not use Nvidias RT acceleration? AFAIK it's not exposed directly through OpenCL.
  - pixelpoet 3y ago
    Usually you batch up a large buffer of rays to be traced anyway, so it's not really a problem to hand this off to another API if need be. This is often the case on CPU too, where you would use something like Embree, but on GPU it'd be Vulkan RT or OptiX (we didn't do this for Indigo Renderer, however).
- joe_the_user 3y ago
  Well, my impression when I looked into OpenCl a few years ago was that it was certainly real and used for things but it was absolutely nothing like a Cuda replacement. Basically it's constructs are low level and processor specific - workable for graphic engines but not for general purpose gpu programming. This is explains the rise of ROCm and DPC++ as systems having equivalent higher level constructs to Cuda.
  - pjmlp 3y ago
    SYCL is the second attempt at it, because only after got punched, seeing researchers rather adopt CUDA with its polyglot PTX, supporting C++, Fortran, and even subsets of Java, Haskell, .NET, did they come up with SPIR, and OpenCL C++ in OpenCL 2.0. However almost no one cared, meaning AMD and Intel never shiped anything worth using, so OpenCL 3.0 is OpenCL 1.0 rebranded, and out of it, the C++ efforts were placed into SYSCL intead. Which Intel picked up for their own DPC++ efforts, an additional tooling layer on top of SYSCL, meanwhile the only company selling usable SYCL developer experience is a former compiler vendor, that used to work with Sony in high performance compilers for the Playstation (Codeplay), as they pivoted away from console development. Eventually Intel acquired Codeplay, and they are now the main supporters of One API tools, and the whole UXL efforts. In the middle of all this, AMD decided to go with their own efforts. It isn't only up to NVidia, when their competition can't get their story straight for decades.
    - joe_the_user 3y ago
      Indeed, If anything the situation is that Nvidia is far-sighted, developing hardware and software for general purpose GPU computing and the other chip manufacturers still think like traditional (non-CPU) chip manufacturers - they just want to sell a best-chip for a single purpose. This explain why they throw random things against the wall to see if they stick rather than choosing a general purpose and committing to it indefinitely.
VHRanger 3y ago
People are moving away from OpenCL. The big problem is driver support. The transition from 2 to 3 was a mess, performance is all over the place on some functions between intel/amd/nvidia, and Apple is at the point of just leaving it out. People have even started using Vulkan in its place for some GPGPU, because at least Vulkan has good drivers everywhere, being a low-level API.
- keldaris 3y ago
  While this is completely true, it is also true that OpenCL 1.2 is the one compute API that just works on every major platform and the drivers don't seem that unusably bad (though I'm not claiming experience of every platform here, just Nvidia on Windows/Linux and Apple Silicon on MacOS). Writing a limited dialect of C and sticking to 1.2 limitations is far from ideal, but it does at least work reliably. Sadly, that is more than can be said about most competitors.
  - VHRanger 3y ago
    Yes, 1.2 is OK. The problem is that the drivers are merely OK. Presumably if you're using OpenCL you care about the performance (otherwise why would you??) and since that's the case, it's the best on no platforms, and there are alternatives for any set of platforms that do better. I think OpenCL is sadly on its way out, and it's mostly Apple's fault (and Nvidia a little). Vulkan compute is much more interesting if you're looking to leverage iGPUs/mobile/other random CPUs. If you're targetting workstations/server workloads only, it makes sense to restrict yourself to a subset of accelerator types and code for that (eg. Torch or JAX for GPUs, use highway for SIMD, etc.)
    - keldaris 3y ago
      It depends on what you're doing. For writing FP32 number crunching code from scratch (meaning you don't care about something like Torch, or even cuBLAS/cuDNN), I haven't encountered cases where I couldn't match CUDA performance and if I did, I could always just use a bit of PTX assembly where absolutely necessary (which OpenCL lets you do, whereas Vulkan does not). This also gets me good performance on MacOS without rewriting the whole thing in Metal. There is no native FP16 support and there are other limitations that may matter to your usecase or be completely irrelevant. I'm definitely not saying OpenCL is any sort of a reasonable default for cross platform GPGPU work. In truth, I don't think there is any reasonable "general" default for that sort of thing. Vulkan has its own issues (only works via a compatibility layer on MacOS, implementation quality varies widely, extension hell, boilerplate hell, some low level things are just impossible, etc.) and everything else is a higher level approach that can't work for everything by definition. It's a pretty sad situation overall and every solution has severe tradeoffs. Personally, I just write CUDA when I can get away with it and try to stick to OpenCL otherwise, but everyone needs to make that choice for their own set of tradeoffs.

Could we get an expert to weigh in on the state of OpenCL. It seems like AMD and Intel are shifting away from OpenCL other GPGPU languages such as ROCm and DPC++.

pjmlp 3y ago

DPC++ is Intel's own thing on top of SYCL, which relies on OpenCL drivers, basically long story short, what happened after Khronos realized shipping source code and C99 dialect wasn't really what most researchers were keen on using for their work.

pixelpoet 3y ago

Not sure if having two commercial OpenCL apps[0] makes me an expert, but the practical reality is that OpenCL works just great today, even on latest Apple platforms. It's not a lot of work to do a little testing and tuning on the 3 main vendors. News of OpenCL's demise is greatly exaggerated. [0] https://glaretechnologies.com/ https://glaretechnologies.com/

rwbt 3y ago
What version of OpenCL do Apple platforms support? Also, is OpenCL also deprecated like OpenGL on Apple?
- my123 3y ago
  it's 1.2, macOS only, and marked as deprecated
jsheard 3y ago
Did you figure out a way to interop OptiX with OpenCL, or do you just not use Nvidias RT acceleration? AFAIK it's not exposed directly through OpenCL.
- pixelpoet 3y ago
  Usually you batch up a large buffer of rays to be traced anyway, so it's not really a problem to hand this off to another API if need be. This is often the case on CPU too, where you would use something like Embree, but on GPU it'd be Vulkan RT or OptiX (we didn't do this for Indigo Renderer, however).
joe_the_user 3y ago
Well, my impression when I looked into OpenCl a few years ago was that it was certainly real and used for things but it was absolutely nothing like a Cuda replacement. Basically it's constructs are low level and processor specific - workable for graphic engines but not for general purpose gpu programming. This is explains the rise of ROCm and DPC++ as systems having equivalent higher level constructs to Cuda.
- pjmlp 3y ago
  SYCL is the second attempt at it, because only after got punched, seeing researchers rather adopt CUDA with its polyglot PTX, supporting C++, Fortran, and even subsets of Java, Haskell, .NET, did they come up with SPIR, and OpenCL C++ in OpenCL 2.0. However almost no one cared, meaning AMD and Intel never shiped anything worth using, so OpenCL 3.0 is OpenCL 1.0 rebranded, and out of it, the C++ efforts were placed into SYSCL intead. Which Intel picked up for their own DPC++ efforts, an additional tooling layer on top of SYSCL, meanwhile the only company selling usable SYCL developer experience is a former compiler vendor, that used to work with Sony in high performance compilers for the Playstation (Codeplay), as they pivoted away from console development. Eventually Intel acquired Codeplay, and they are now the main supporters of One API tools, and the whole UXL efforts. In the middle of all this, AMD decided to go with their own efforts. It isn't only up to NVidia, when their competition can't get their story straight for decades.
  - joe_the_user 3y ago
    Indeed, If anything the situation is that Nvidia is far-sighted, developing hardware and software for general purpose GPU computing and the other chip manufacturers still think like traditional (non-CPU) chip manufacturers - they just want to sell a best-chip for a single purpose. This explain why they throw random things against the wall to see if they stick rather than choosing a general purpose and committing to it indefinitely.

VHRanger 3y ago

People are moving away from OpenCL. The big problem is driver support. The transition from 2 to 3 was a mess, performance is all over the place on some functions between intel/amd/nvidia, and Apple is at the point of just leaving it out. People have even started using Vulkan in its place for some GPGPU, because at least Vulkan has good drivers everywhere, being a low-level API.

keldaris 3y ago
While this is completely true, it is also true that OpenCL 1.2 is the one compute API that just works on every major platform and the drivers don't seem that unusably bad (though I'm not claiming experience of every platform here, just Nvidia on Windows/Linux and Apple Silicon on MacOS). Writing a limited dialect of C and sticking to 1.2 limitations is far from ideal, but it does at least work reliably. Sadly, that is more than can be said about most competitors.
- VHRanger 3y ago
  Yes, 1.2 is OK. The problem is that the drivers are merely OK. Presumably if you're using OpenCL you care about the performance (otherwise why would you??) and since that's the case, it's the best on no platforms, and there are alternatives for any set of platforms that do better. I think OpenCL is sadly on its way out, and it's mostly Apple's fault (and Nvidia a little). Vulkan compute is much more interesting if you're looking to leverage iGPUs/mobile/other random CPUs. If you're targetting workstations/server workloads only, it makes sense to restrict yourself to a subset of accelerator types and code for that (eg. Torch or JAX for GPUs, use highway for SIMD, etc.)
  - keldaris 3y ago
    It depends on what you're doing. For writing FP32 number crunching code from scratch (meaning you don't care about something like Torch, or even cuBLAS/cuDNN), I haven't encountered cases where I couldn't match CUDA performance and if I did, I could always just use a bit of PTX assembly where absolutely necessary (which OpenCL lets you do, whereas Vulkan does not). This also gets me good performance on MacOS without rewriting the whole thing in Metal. There is no native FP16 support and there are other limitations that may matter to your usecase or be completely irrelevant. I'm definitely not saying OpenCL is any sort of a reasonable default for cross platform GPGPU work. In truth, I don't think there is any reasonable "general" default for that sort of thing. Vulkan has its own issues (only works via a compatibility layer on MacOS, implementation quality varies widely, extension hell, boilerplate hell, some low level things are just impossible, etc.) and everything else is a higher level approach that can't work for everything by definition. It's a pretty sad situation overall and every solution has severe tradeoffs. Personally, I just write CUDA when I can get away with it and try to stick to OpenCL otherwise, but everyone needs to make that choice for their own set of tradeoffs.