AMD ROCm Looks Like It Will Finally Be Supporting OpenCL 3.0 Soon

[Mystro256]

But still not in a usable state outside of the hardware AMD already supports. It completely crashes Blender trying HIP on a RX 6650 XT on Fedora 40 with the benchmark test files (or any .blend for that matter). Yes I sent in what debug information I could gather.

Can you test this update?

https://bodhi.fedoraproject.org/updates/FEDORA-2024-3f027d3cb6

We think we found the issue but feedback would be much appreciated.

EDIT: note I actually patch rocm-opencl in Fedora to work on more HW than default, YMMV though on if it works

[stormcrow]

Can you test this update?

https://bodhi.fedoraproject.org/updates/FEDORA-2024-3f027d3cb6

We think we found the issue but feedback would be much appreciated.

EDIT: note I actually patch rocm-opencl in Fedora to work on more HW than default, YMMV though on if it works

I'll try it out and see. I would very much like to have a working HIP for Blender that doesn't involve Windows. Things have been so frustrating all over with AMD GPUs lately.

Edit to add: Nope. Still crashes when hitting the render scene command. I'll try it again later on when the system isn't doing other things see if it's a lack of VRAM issue, but I don't think it is.

Addendum: Yeah, crashes on rendering Monster.blend although it can at least render the default cube now. That's after a full update and pulling in the Bodhi issue fix, then a reboot to make sure no stale dependencies were left in my active environment. It can render my very simple scenes (like donuts - hey, I'm a beginner ) but it can't handle the more complex demo scenes and benchmarks like Monster, Junkyard, etc.

[cgmb]

EDIT: note I actually patch rocm-opencl in Fedora to work on more HW than default, YMMV though on if it works

Debian recently packaged rocm-opencl and is beginning to update some of its opencl packages to be tested on AMD GPUs in their continuous integration system. The first package updated was clpeak, which is now being run on 15 different AMD GPU architectures from Fiji onward. In addition to the architectures currently being tested, I'm currently in the process of setting up gfx902, gfx90c, gfx1013, and gfx1102 nodes.

The Debian package is still on ROCm 5.7, but we're in the process of updating the stack to ROCm 6.1. Then will come a compiler update from llvm-17 to llvm-18 for the update from ROCm 6.1 to ROCm 6.2, if we have time before the Trixie freeze (whenever that is).

[Jabberwocky]

The OpenCL 3.0 compute specification has been out in finalized form since September 2020. Since then NVIDIA's official Windows/Linux drivers have been exposing OpenCL 3.0 going back to 2021, the Intel Compute Runtime stack has also been exposing OpenCL 3.0 support for years, and even with Mesa's Rusticl open-source OpenCL implementation it's beginning to see Gallium3D drivers with conformant OpenCL 3.0. Yet if installing the AMD ROCm compute stack right now, you'll see OpenCL 2.1. But it looks like OpenCL 3.0 will soon be here for ROCm

Conveniently leaves out that we are still waiting for Nvidia to support OpenCL 2 since 2013, more than 10 years ago...

OpenCL 3 is actually OpenCL 1.3 but was purposely designed to sound new and allow people to make biased statements like this above.

I'm not defending AMD. Their proprietary drivers (needed for compute) on Linux have been trash on consumer hardware, but can we please stop praising Leather Suit man when he's been an ass to the compute industry since it's inception.

Is this news actually relevant? Is ANYONE using OpenCL? I don't think anything has changed since 2022 in terms of usage... https://www.phoronix.com/forums/foru...34#post1353234

[DiamondAngle]

Huh, rocm is fully open source, you need 0 proprietary components for amd compute on linux. Rocm on windows dose need some proprietary parts.

[Abacus123]

We have been working with fedora and debian for a while to package ROCm. Native ROCm packages are already available in recent versions of those distros.

Any chance of native ROCm packages being available in the repos for openSUSE tumbleweed?

[stormcrow]

Huh, rocm is fully open source, you need 0 proprietary components for amd compute on linux. Rocm on windows dose need some proprietary parts.

Not strictly true. You have to load the firmware blob just to get the hardware to initialize. I know the debate over blob firmware, not to mention HDCP is never going to function without a blob, that's a legal restriction. Second, regardless of it being open source, the only people that can really get ROCm/HIP/OpenCL fully functional, not just a hacked job like in Fedora (and no offense meant for those trying) is for AMD to do it. Repackaging it for native install is only a convenience. They have all the documentation and they haven't released any of it to be able to get it fully functional and reliable beyond their very limited officially supported hardware or Windows.

In the end it doesn't matter if it's open source to end users if it doesn't work and the only people that can really get it reliably working in all hardware cases is AMD. If it doesn't work, it doesn't work. Hence most people doing Blender (and other consumer grade or non data center compute) on Linux are using Nvidia because they quite literally have no choice.

[DiamondAngle]

Thats totaly untrue, sure i run mostly supported hw (i have gfx900, gfx906, gfx908, and gfx1030) but i have zero problems using the arch linux packages for hip incl rocblas,sparse,miopen,pytorch,flash-attention,triton and many many more.

I have compiled several rocm packages and kernel modules from source to get some performance advantages (like pulling hipblaslt code for gfx908 etc) but everything _works_ out of the box

[Svyatko]

In the end it doesn't matter if it's open source to end users if it doesn't work and the only people that can really get it reliably working in all hardware cases is AMD. If it doesn't work, it doesn't work. Hence most people doing Blender (and other consumer grade or non data center compute) on Linux are using Nvidia because they quite literally have no choice.

Choice is here - Intel. Big hopes for Intel Battlemage.
Blender devs chose Nvidia.
It is possible to enhance AMD ROCm compatibility, but who will pay for that?

https://github.com/ROCm/clr/issues/20#issuecomment-2422794782

To clarify: we are testing out supporting header version 3.0 and are hitting some bumps, but it is currently not on our roadmap yet. And we have no plans to support OpenCL 3.0 in the runtime as of now. Apologies if my previous response caused any confusion. Thanks!

[Panix]

Choice is here - Intel. Big hopes for Intel Battlemage.
Blender devs chose Nvidia.
It is possible to enhance AMD ROCm compatibility, but who will pay for that?

https://github.com/ROCm/clr/issues/20#issuecomment-2422794782

Yeah, right. Intel didn't even have a desktop card until recently.
Yes, Blender chose Nvidia and AMD did nothing to improve/progress their support - they are not just subpar in Blender. AMD is not a choice for productivity. Rocm is a non-starter.

I echo Scarecrow's sentiments.