6 ms·

> Deprecation > OpenCL rendering kernels. The combination of the limited Cycles split kernel implementation, driver bugs, and stalled OpenCL standard has made

by birktj 5y ago

> Deprecation > OpenCL rendering kernels. The combination of the limited Cycles split kernel implementation, driver bugs, and stalled OpenCL standard has made maintenance too difficult. I am not really up to date on the GPGPU world, but is OpenCL in such a bad shape that it is not really usable? If so that is very sad. Are there any alternative open hardware agnostic GPGPU apis or has CUDA eaten the entire market?

raphlinus 5y ago
My perspective is that OpenCL is indeed in that bad shape, though it does have defenders. Both AMD (ROCm) and Intel (oneAPI) have ways to run workloads originally written to run on CUDA, but they're nowhere near the level of polish as CUDA. I believe an open stack can and will emerge, but it will take time and effort on all levels of the stack. It's possible to do pretty amazing things with Vulkan compute shaders, but the programming model is different than CUDA (it's not single-source), and the tooling support is not quite there. In time, I am hopeful that WebGPU will gather more momentum, and be officially supported even in places where Vulkan requires janky adapter layers. But in its current form, it's very immature and far from being usable for real workloads.
- dogma1138 5y ago
  ROCm is a total mess, and is Linux only. OneAPI is in a rather good state considering it’s barely a release candidate now I’ll put my money on Blender support Intel GPUs sooner than AMD ones with Cycles X unless AMD will adopt OneAPI.
  - jsheard 5y ago
    ROCm doesn't even run on every AMD card, it only supports a subset of their architectures skewed towards the HPC market The current and previous generations of consumer AMD cards just don't work with ROCm and there's been no indication they ever will
  - sudosysgen 5y ago
    OneAPI/SYCL also works on AMD if the card supports ROCM.
    - dogma1138 5y ago
      “Works” and actually works are different things. ROCm isn’t in a state that i would define actually working atm, considering just how broken their CUDA to HIP stuff is I’m not going to hold my breath.
      - sudosysgen 5y ago
        SYCL can be targeted directly to HIP without going through Cuda first, but I agree that it's far from perfect. IMO though, it's as useable as OpenCL by now.
w-m 5y ago
Yes it’s that bad unfortunately. Ok, so you got you kernel working and it performs well. That’s quite an achievement, because most tooling is atrocious, and profiling tools nonexistent for many platforms. Now you want to run this on the users machine. You are of course using an ancient OpenCL version, because very few vendors updates their OpenCL drivers. Situation has gotten so bad that the consortium had to basicallly roll back much of the newer standard because nobody sipported it. Anyway, the users GPU has the right capabilities and should run your code fine. But it doesn’t. If you’re lucky, you get an error message. Often you don’t, either you get a cryptic error code with zero Google results, or the OpenCL compiler just crashes. That actually happens quite often. In summary, if you want to support many different GPUs in different OSes, you’re in a world of pain, because everything is half-baked. There was a letter by the Blender devs to Apple a couple years ago to get their shit together and fix their OpenCL driver. I don’t think they ever did, just deprecated it and told you to use Metal...
- henrikf 5y ago
  Even worse than error message is incorrect results. I worked on the OpenCL neural net evaluation backend used in Leela Zero and lc0 Go and chess bots. We had reports of several OpenCL drivers being so broken that they gave incorrect results while appearing to work correctly without giving any error messages. Intel integrated GPUs on Apple were the worst offender and it looks like the drivers are never going to get fixed. Some older AMD cards had similar issues. We had to add a check that GPU NN evaluation matches CPU reference to catch these broken drivers.
RaisingSpear 5y ago
OpenCL is old, and everyone seemingly wants to abandon it, but it's your only option for a bunch of configurations (such as AMD on Windows, even though AMD has pulled all their OpenCL stuff from their website). As someone who's done a fair bit of SIMD programming on CPU, and heard many scream that wide SIMD (like AVX512) is pointless when you have GPGPU, it's certainly eye-opening to see how poor a state cross-platform GPGPU development is in. Well, I suppose if you only care about Nvidia, CUDA does seem to be pretty good. Too bad it's Nvidia only. I've heard people consider Vulkan Compute as an alternative. I had a quick look, and it doesn't seem like it supports integer operations (what I'm mostly doing), so doesn't seem viable for me, but I guess it could for a bunch of folk. Not familiar with Vulkan myself though, so corrections welcome.
- pavlov 5y ago
  I'm genuinely surprised that AMD didn't put in an effort to implement CUDA themselves. It's been almost 15 years. They should have started a skunkworks project to get CUDA running immediately. Intel didn't take long to eat crow and ship the AMD64 instruction set in their CPUs as soon as it became clear they'd lost the 64-bit ISA game. AMD should have taken a lesson from that: if the market wants the other guy's API, you can implement it, customers will be pleased, and that gives you power over the API that you wouldn't have otherwise.
  - RaisingSpear 5y ago
    > I'm genuinely surprised that AMD didn't put in an effort to implement CUDA themselves I think HIP is their attempt at that, as it's very similar to CUDA and is meant to be easy to port. Maybe there's reasons why they (or anyone else really) can't just adopt CUDA (licensing?), though that's beyond my knowledge.
- raphlinus 5y ago
  Vulkan supports integer operations just fine, but tool support for just about everything is extremely primitive. Sizes other than 32 bits are available, but generally as an option. You can check https://vulkan.gpuinfo.org/listfeaturescore10.php https://vulkan.gpuinfo.org/listfeaturescore10.php to see the fraction of drivers that support the various integer sizes (and lots other optional features).

by birktj 5y ago

raphlinus 5y ago

My perspective is that OpenCL is indeed in that bad shape, though it does have defenders. Both AMD (ROCm) and Intel (oneAPI) have ways to run workloads originally written to run on CUDA, but they're nowhere near the level of polish as CUDA. I believe an open stack can and will emerge, but it will take time and effort on all levels of the stack. It's possible to do pretty amazing things with Vulkan compute shaders, but the programming model is different than CUDA (it's not single-source), and the tooling support is not quite there. In time, I am hopeful that WebGPU will gather more momentum, and be officially supported even in places where Vulkan requires janky adapter layers. But in its current form, it's very immature and far from being usable for real workloads.

dogma1138 5y ago
ROCm is a total mess, and is Linux only. OneAPI is in a rather good state considering it’s barely a release candidate now I’ll put my money on Blender support Intel GPUs sooner than AMD ones with Cycles X unless AMD will adopt OneAPI.
- jsheard 5y ago
  ROCm doesn't even run on every AMD card, it only supports a subset of their architectures skewed towards the HPC market The current and previous generations of consumer AMD cards just don't work with ROCm and there's been no indication they ever will
- sudosysgen 5y ago
  OneAPI/SYCL also works on AMD if the card supports ROCM.
  - dogma1138 5y ago
    “Works” and actually works are different things. ROCm isn’t in a state that i would define actually working atm, considering just how broken their CUDA to HIP stuff is I’m not going to hold my breath.
    - sudosysgen 5y ago
      SYCL can be targeted directly to HIP without going through Cuda first, but I agree that it's far from perfect. IMO though, it's as useable as OpenCL by now.

w-m 5y ago

Yes it’s that bad unfortunately. Ok, so you got you kernel working and it performs well. That’s quite an achievement, because most tooling is atrocious, and profiling tools nonexistent for many platforms. Now you want to run this on the users machine. You are of course using an ancient OpenCL version, because very few vendors updates their OpenCL drivers. Situation has gotten so bad that the consortium had to basicallly roll back much of the newer standard because nobody sipported it. Anyway, the users GPU has the right capabilities and should run your code fine. But it doesn’t. If you’re lucky, you get an error message. Often you don’t, either you get a cryptic error code with zero Google results, or the OpenCL compiler just crashes. That actually happens quite often. In summary, if you want to support many different GPUs in different OSes, you’re in a world of pain, because everything is half-baked. There was a letter by the Blender devs to Apple a couple years ago to get their shit together and fix their OpenCL driver. I don’t think they ever did, just deprecated it and told you to use Metal...

henrikf 5y ago
Even worse than error message is incorrect results. I worked on the OpenCL neural net evaluation backend used in Leela Zero and lc0 Go and chess bots. We had reports of several OpenCL drivers being so broken that they gave incorrect results while appearing to work correctly without giving any error messages. Intel integrated GPUs on Apple were the worst offender and it looks like the drivers are never going to get fixed. Some older AMD cards had similar issues. We had to add a check that GPU NN evaluation matches CPU reference to catch these broken drivers.

RaisingSpear 5y ago

OpenCL is old, and everyone seemingly wants to abandon it, but it's your only option for a bunch of configurations (such as AMD on Windows, even though AMD has pulled all their OpenCL stuff from their website). As someone who's done a fair bit of SIMD programming on CPU, and heard many scream that wide SIMD (like AVX512) is pointless when you have GPGPU, it's certainly eye-opening to see how poor a state cross-platform GPGPU development is in. Well, I suppose if you only care about Nvidia, CUDA does seem to be pretty good. Too bad it's Nvidia only. I've heard people consider Vulkan Compute as an alternative. I had a quick look, and it doesn't seem like it supports integer operations (what I'm mostly doing), so doesn't seem viable for me, but I guess it could for a bunch of folk. Not familiar with Vulkan myself though, so corrections welcome.

pavlov 5y ago
I'm genuinely surprised that AMD didn't put in an effort to implement CUDA themselves. It's been almost 15 years. They should have started a skunkworks project to get CUDA running immediately. Intel didn't take long to eat crow and ship the AMD64 instruction set in their CPUs as soon as it became clear they'd lost the 64-bit ISA game. AMD should have taken a lesson from that: if the market wants the other guy's API, you can implement it, customers will be pleased, and that gives you power over the API that you wouldn't have otherwise.
- RaisingSpear 5y ago
  > I'm genuinely surprised that AMD didn't put in an effort to implement CUDA themselves I think HIP is their attempt at that, as it's very similar to CUDA and is meant to be easy to port. Maybe there's reasons why they (or anyone else really) can't just adopt CUDA (licensing?), though that's beyond my knowledge.
raphlinus 5y ago
Vulkan supports integer operations just fine, but tool support for just about everything is extremely primitive. Sizes other than 32 bits are available, but generally as an option. You can check https://vulkan.gpuinfo.org/listfeaturescore10.php https://vulkan.gpuinfo.org/listfeaturescore10.php to see the fraction of drivers that support the various integer sizes (and lots other optional features).