Fedora Makes Progress On Radeon ROCm Packages, But Still Needs To Land OpenCL / HIP

[agd5f]

Mystro256
As someone working with ROCm, could you please comment on deprecating all Vega 10 GPUs as of 4.5 and them removed from the supported list of GPUs in 5.0? One previous poster in another thread said something along the lines of "the support isn't being removed, it's just not being tested anymore." Is that the case, or are things changing in 5.x and the roadmap that totally break Vega 10 GPUs with ROCm 5.x? I'm so tempted to buy up some MI25's on ebay for cheap, but not if it's completely dead to AMD.

We are not removing vega support. It's just seeing a reduced level of validation. It's no different than any other project. For example, older GPUs in mesa get less testing than newer ones.

[Mystro256]

Good to see you around here!

A question:

I understand that AMD aims to implement GPU-accelerated rendering into the upcoming Blender 3.2 release for Linux.

Now, is my Radeon R9 380 (GCN Gen3 - GFX8 - Tonga V2) going to be supported for this?

Note I'm running Ubuntu 20.04 LTS based distributions, so I'm not inquiring about the packaging problems you face on Fedora, since AMD seems to support such a setup with official packages.

Thanks!

I assume with blender you are talking about ROCm compute accelerated blender?

ROCm require kernel support and LLVM support to work. From what I understand, Gen3 does not have either (kernel for gen 3 is graphics only I think), so you're out of luck for ROCm support. You could try mesa's OpenCL though, but I'm not sure how well that works.

ROCm Gen 4 (Polaris) on the other hand was experimental as far as I know. I'm told has issues with LLVM and is non-trivial to fix. I'm not a compiler guy so I can't really help there. We do provide a legacy OCL driver for supporting Polaris, but it uses a closed source compiler, so the driver is nonfree. Most of the code is actually just ROCm OCL with a different backend.

To be clear, ROCm is intended to work with Gen 5+ and RDNA.

[MadeUpName]

Hopefully ARC has it's act together and we can just forget about AMD.

We are not removing vega support. It's just seeing a reduced level of validation. It's no different than any other project. For example, older GPUs in mesa get less testing than newer ones.

Marty: The last time Tap toured America, they where, uh, booked into 10,000 seat arenas, and 15,000 seat venues, and it seems that now, on their current tour they're being booked into 1,200 seat arenas, 1,500 seat arenas, and uh I was just wondering, does this mean uh...the popularity of the group is waning?
Ian: Oh, no, no, no, no, no, no...no, no, not at all. I, I, I just think that the.. uh.. their appeal is becoming more selective.

[coder]

We are not removing vega support. It's just seeing a reduced level of validation. It's no different than any other project. For example, older GPUs in mesa get less testing than newer ones.

I understand developers like us have little or no influence over strategic-level decisions, but I hope someone at AMD realizes how foolish it is to leave so many potential users out in the cold. If there's any real desire for ROCm to gain traction outside of a tiny number of niche markets, then support needs to be provided on the hardware people actually have.

And it's not just about developers! You need to consider that developers write code mostly for use by non-developers, who are using even potentially older hardware. In order for devs to support apps, the hardware support needs to be solid and stable (i.e. not breaking, from one release to the next).

Nvidia and Intel are useful benchmarks, here. I don't know how far Nvidia's support goes, but I know I can run OpenCL on Intel iGPUs going back at least as far as Gen 8 (i.e. Broadwell CPUs from more than 7 years ago)!

[jaehan.gyopo]

We are not removing vega support. It's just seeing a reduced level of validation. It's no different than any other project. For example, older GPUs in mesa get less testing than newer ones.

agd5f So if a Vega 10 developer or user were to submit a reproducible bug, a regression or elsewise, would AMD commit to fixing the bug or would it "forever" be on the bottom of the priority list? And I'm asking about next year or the year after, not this weird "until September" or whatever month Vega 10 is suppose to continue receiving support in ROCm 4.5.

Sorry, but the way AMD releases (sometimes more like dumps things without much documentation or explanations) and then drop support for those things makes me super hesitant to develop with anything for fear I get the rug pulled out from underneath me (it's happened on more than one occasion).

[fuzz]

Mystro256 thanks for these packages, working flawlessly on my 6800 XT on fedora 36.

Now to see about getting it working with a WX 4150, if it's even supported

[Mystro256]

fuzz no problem, glad to hear it works, I haven't had time to test it well.

I have 5.1 as an update pending for f36, I was waiting for the llvm 14 backport:

https://bodhi.fedoraproject.org/updates/FEDORA-2022-a4acfb594b

As for the WX4150, it's a polaris, so the support is experimental (i.e. it was never really "supported"). To use it, you have to export a variable... I think ROC_ENABLE_PRE_VEGA=1 (not sure).

[JacekJagosz]

Mystro256 First, thank you for so much work you did on that, like the patches to make the process so much cleaner.
I'm packaging rocm for Solus based on your work, and it has proven extremely helpful. I have a question though. I am facing an issue where a GPU is detected by `rocminfo`, but then there is no OpenCL device found when running `clinfo` or `rocm-clinfo`. Even when running strace I can verify it finds all the libraries, but still no OCL device. Did you ever encounter such a problem on Fedora? Or have an idea what could be causing it?
It is hard to diagnose this issue as Fedora is the only distribution so far that uses system's LLVM and not a separate one just for ROCm, and I can't find anyone encountering an issue like that before.

[Mystro256]

Mystro256 First, thank you for so much work you did on that, like the patches to make the process so much cleaner.
I'm packaging rocm for Solus based on your work, and it has proven extremely helpful. I have a question though. I am facing an issue where a GPU is detected by `rocminfo`, but then there is no OpenCL device found when running `clinfo` or `rocm-clinfo`. Even when running strace I can verify it finds all the libraries, but still no OCL device. Did you ever encounter such a problem on Fedora? Or have an idea what could be causing it?
It is hard to diagnose this issue as Fedora is the only distribution so far that uses system's LLVM and not a separate one just for ROCm, and I can't find anyone encountering an issue like that before.

Yeah I haven't done real functional testing. I know LLVM upstream is missing some bits from ROCm's fork that I haven't had time to access. Currently there's only one patch I've identified is needed for HIP, which I asked the fedora clang maintainers to cherrypick from llvm 15 (upstream main branch):

https://src.fedoraproject.org/rpms/clang/pull-request/156

If I recall correctly, rocminfo checks for kernel support, while clinfo checks for runtime support (logic is in ROCclr). If it shows up in the first but not the latter, you might have prevega HW, which is experimental. I think you need to "export ROC_ENABLE_PRE_VEGA=1" (or maybe "true") but I've never tried it myself. You could also patch the code if you want to explicitly enable it:

https://github.com/ROCm-Developer-Tools/ROCclr/blob/090087267c0e49e5b5b8cdec2309a335e322c532/utils/flags.hpp#L248

FYI, I'm still working on the packaging patches. I've upstreamed most of them, but there's still a few patches I have locally I need to rework to allow upstreaming (at least 1 OCL patch, 1 ROCclr patch, and a few HIP patches). I'll get to them as I have free time.