> 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?
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.
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.
The current and previous generations of consumer AMD cards just don't work with ROCm and there's been no indication they ever will
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...
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.
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.
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.
Most examples seem to be using GLSL shaders for the kernel, but posts seem to indicate it uses SPIR-V as input [https://community.khronos.org/t/is-a-vulkan-compute-shader-d...]. And then you have threads like this [https://community.amd.com/t5/drivers-software/amd-dropped-sp...] saying that SPIR-V isn't supported on the AMD's Windows driver (I had similar issues myself trying to get SYCL examples to run), though I see other places running Vulkan Compute stuff on AMD+Windows. Maybe that only applies to SPIR-V with an OpenCL runtime?
Diagrams [https://www.khronos.org/assets/uploads/apis/2020-spir-landin...] seem to indicate that you can feed stuff like OpenCL and SYCL into SPIR-V (and then Vulkan Compute) instead of GLSL. For the former case, would you essentially still be using OpenCL, but just with a different runtime? (though articles like this [https://linuxreviews.org/The_State_Of_OpenCL_To_Vulkan_Compu...] seem to suggest OpenCL -> Vulkan isn't in a good state)
Most of the time, when people say OpenCL, they mean that an OpenCL driver is provided by the GPU vendor. That's what's in a particularly sorry state. Many vendors ship OpenCL but have deprecated it. AMD's ROCm is based on OpenCL, but they don't support it on all cards and there are problems.
The other thing that's picking up steam lately is using a lower level API such as Vulkan as the interface to the graphics hardware, and having a layer that runs the compute workload (whether OpenCL or something else) on top of that. In my opinion, this actually has a pretty good future. On Linux, Vulkan is obviously the way to go, on Windows it's supported by all major cards, and on mac it's possible to fake it with MoltenVK. This is what clspv and clvk are about, but from the article you posted these are not in usable shape yet. I think that might say more about the level of interest around OpenCL than anything else though. It's entirely possible that running compute on Vulkan becomes mainstream through other efforts like IREE than by porting OpenCL workloads.
In a couple years or so, there's a good chance the landscape will shift again, as WebGPU might be capable of running compute workloads well, and is likely to be supported by all vendors. Note that despite "web" in the name, it doesn't require a browser or other web technology. You can run prototypes of it today, but there are still huge chunks of the ecosystem missing.
That thread is talking about SPIR (the OpenCL binary shader format) in the OpenCL implementation, not SPIR-V (the Vulkan binary shader format, which has also been adopted by other APIs) in the Vulkan implementation.
Unless something has changed since then, or the post is inaccurate?
What is still a mess is the tool situation. You have to write your shaders in GLSL or HLSL (the latter is still missing some subgroup operation) and compile to SPIR-V. You also have to have CPU-side code to manage all resources, including memory allocation and putting in explicit pipeline barriers and other ways to manage the asynchrony. For someone who just wants to get their code running, it's pretty painful.
My own application is 2D rendering, but a lot of the motivation for improving Vulkan Compute is machine learning workloads. One of the projects to watch is IREE (https://google.github.io/iree/).
I've got some blog posts and tutorials in the pipeline, stay tuned.