Mesa's Rusticl Implements OpenCL Subgroups

[phoronix]

Phoronix: Mesa's Rusticl Implements OpenCL Subgroups

Red Hat's Karol Herbst who has done a remarkable job on Rusticl as a modern OpenCL implementation written in Rust for Mesa Gallium3D drivers has another achievement under his belt: OpenCL subgroups are now in place for Mesa...

https://www.phoronix.com/news/Rusticl-OpenCL-Subgroups

[southwood]

Typo:

over 400 lines ofn ew code

[Sethox]

I like the disgust of the new code (yes being sarcastic here).

Implementing this support is quite big with over 400 lines ofn ew code.

[tuxd3v]

We can say whatever we want in relation to Rust..
Clover was a option that at same time was around 10% faster than AMD proprietary driver..but Clover is not feature complete..

But the Community that is developing rusticl, deserve our most respect for doing it..specially at a time when AMD decided to drop us in a situation where we brought their hardware and we get without opencl support..

Kudos to this team, that is showing a tremendous work.

[brucethemoose]

Lots of compute that really needs the performance is moving away from opencl anyway...


Blender is the big example, but it also looks like a vulkan backend is going to depreciate opencl in llama.cpp (a popular llm inference backend).

[coder]

Lots of compute that really needs the performance is moving away from opencl anyway...

Blender is the big example, but it also looks like a vulkan backend is going to depreciate opencl in llama.cpp (a popular llm inference backend).

Blender is not a good example, since its core devs are long-time Nvidia fanboys and never cared for the OpenCL backend that was contributed by others and was always a second class citizen in their view.

As for deep learning workloads, the problem OpenCL faces is that it has to compete against well-optimized domain-specific libraries like cudnn. I believe Intel has done a lot to make OpenCL more competitive, but I don't know how much of their stack runs on other GPUs (i.e. due to which features they require) or how well.

My point is not to over-interpret specific examples, or risk being lead astray. OpenCL is a good general, portable solution for compute acceleration, even if it's not always the fastest option.

[karolherbst]

Blender is not a good example, since its core devs are long-time Nvidia fanboys and never cared for the OpenCL backend that was contributed by others and was always a second class citizen in their view.

As for deep learning workloads, the problem OpenCL faces is that it has to compete against well-optimized domain-specific libraries like cudnn. I believe Intel has done a lot to make OpenCL more competitive, but I don't know how much of their stack runs on other GPUs (i.e. due to which features they require) or how well.

My point is not to over-interpret specific examples, or risk being lead astray. OpenCL is a good general, portable solution for compute acceleration, even if it's not always the fastest option.

The biggest problem with OpenCL for a long time was, that Nvidia had the best OpenCL stack on the market, but CUDA was even better for obvious reasons. There are some counter examples that well optimize OpenCL code can be as fast as well optimize CUDA code, but that needs the proper ecosystem first before enough developers actually care.

It's kinda improving these days, but Nvidia spearheading the entire market for almost 15 years kinda put the bar quite high.

[timofonic]

Rusticl seems interesting. Thanks a lot!

But does OpenCL deserve to exist instead merging it with Vulkan?

Will we see really strong conpetition against proprietary CUDA? I still can't see it.

I see noth Intel and AMD just fight with their own half baked crap instead join forces against Nvidia GPGPU monopoly:
- Intel oneAPI: Aka an API only used by one person! 🤣
- ROCm: Open Compute? Sure, only if you can open your wallet wide enough to buy high end expensive workstation.

Prepare to suffer, because everything is CUDA.

I hope things improve someday. Maybe Rustcl can help at this. I hope so.

[coder]

But does OpenCL deserve to exist instead merging it with Vulkan?

Vulkan compute seems more like OpenGL's compute shaders, than a full-fledged OpenCL replacement.

Will we see really strong conpetition against proprietary CUDA? I still can't see it.

I see noth Intel and AMD just fight with their own half baked crap instead join forces against Nvidia GPGPU monopoly:
- Intel oneAPI: Aka an API only used by one person! 🤣
- ROCm: Open Compute? Sure, only if you can open your wallet wide enough to buy high end expensive workstation.

oneAPI is based on OpenCL. AMD's equivalent is HiP, not ROCm. HiP is a clone of CUDA.

[brucethemoose]

Blender is not a good example, since its core devs are long-time Nvidia fanboys and never cared for the OpenCL backend that was contributed by others and was always a second class citizen in their view.

As for deep learning workloads, the problem OpenCL faces is that it has to compete against well-optimized domain-specific libraries like cudnn. I believe Intel has done a lot to make OpenCL more competitive, but I don't know how much of their stack runs on other GPUs (i.e. due to which features they require) or how well.

My point is not to over-interpret specific examples, or risk being lead astray. OpenCL is a good general, portable solution for compute acceleration, even if it's not always the fastest option.

Well thats the problem... If its not the fastest, why not just use Vulkan? Or a Vulkan "intermediate" like Kompute?

Again using llama.cpp as an example, the Vulkan drivers are apparently just faster/better supported on Nvidia/AMD (though I am not sure about Intel), and (while over my head) I think there are some other advantages related to CPU-GPU transfers, quantization, and IGP support.

And in that case, there is not any perverse incentive to move away from OpenCL, as its already implemented and supported.

This is not the only example either, for instance Torch MLIR and Apache TVM apparently favor Vulkan as a backend, even though TVM seems to support OpenCL.