Mesa's Rusticl OpenCL Implementation Can Outperform Radeon's ROCm Compute Stack

[phoronix]

Phoronix: Mesa's Rusticl OpenCL Implementation Can Outperform Radeon's ROCm Compute Stack

Mesa's Rusticl driver as a modern Rust-based OpenCL implementation for open-source Gallium3D drivers has shown it's capable of outperforming AMD's open-source ROCm compute stack for at least some GPUs and workloads...

https://www.phoronix.com/news/Rusticl-Outperformed-ROCm

[coder]

Massive congrats, karolherbst !!

🍾 🎉 🥳 🎈 🍾

[coder]

these results are nevertheless quite interesting considering the resources poured into ROCm by AMD over the past several years.

The issue is probably that AMD has been giving specifically OpenCL very little love, these days. It's all about HiP, for them.

[smitty3268]

The issue is probably that AMD has been giving specifically OpenCL very little love, these days. It's all about HiP, for them.

The drivers aren't really equivalent feature-wise, either. For example, I think Rusticl inlines all code, instead of keeping function calls, which could easily have a performance impact depending on the benchmark and how that's all implemented.

That said, I'm not really shocked by this at all given what we've seen in the past from AMD's proprietary compiler teams, and I'm guessing this is a fully legit result.

Congrats to karolherbst

[JosiahBradley]

It sounds good, but ROCm is also open source, why not work together for maximum performance to help solve the challenging problems today and the future holds. Open source shouldn't be about fighting for who's the best. It should be about open collaboration.

[coder]

It sounds good, but ROCm is also open source, why not work together for maximum performance to help solve the challenging problems today and the future holds. Open source shouldn't be about fighting for who's the best. It should be about open collaboration.

Competition still plays a role, in the Open Source ecosystem. We have BSDs and Linux, LLVM and GCC, Gnome and KDE, among countless other examples.

That said, there are lots of pragmatic aspects to building Rusticl atop Mesa vs. ROCm, where perhaps the Mesa approach provides lots of infrastructure that ROCm doesn't? More importantly, by using Mesa, Rusticl is GPU-agnostic, and I think that's probably the key point.

[ssokolow]

Competition still plays a role, in the Open Source ecosystem. We have BSDs and Linux, LLVM and GCC, Gnome and KDE, among countless other examples.

That said, there are lots of pragmatic aspects to building Rusticl atop Mesa vs. ROCm, where perhaps the Mesa approach provides lots of infrastructure that ROCm doesn't? More importantly, by using Mesa, Rusticl is GPU-agnostic, and I think that's probably the key point.

Not to mention that ROCm isn't written in Rust and, as Asahi Lina's tweets about the M1 driver work pointed out, it's sometimes just down to "Yeah, I have the skill to accomplish this in either language, but Rust is more enjoyable to work in".

[patrick1946]

It is all nice but who is still using OpenCL for new software? It looks like Vulkan Compute is supported on much more platforms. Actually all this standards make it a mess to support GPU computing.

[coder]

It is all nice but who is still using OpenCL for new software? It looks like Vulkan Compute is supported on much more platforms. Actually all this standards make it a mess to support GPU computing.

"Vulkan compute" lacks feature-parity and has much more lax precision standards than OpenCL. It's equivalent to OpenGL Shading Language, in that regard. Vulkan is also a much lower-level and therefore more labor-intensive API to use.

I'm also not sure about how broad support is for SPIRV-Compute. Do you have data on that?

[xcom]

Hello All . Is Rusticl okay now, for general usage like MemtestCL, Gpuowl?