Fedora & Debian Developers At Packaging ROCm For Easier Radeon GPU Computing Experience

[phoronix]

Phoronix: Fedora & Debian Developers At Packaging ROCm For Easier Radeon GPU Computing Experience

When it comes to the Radeon ROCm GPU software support AMD only officially supports it on SUSE Linux Enterprise Server, RHEL / CentOS, and Ubuntu LTS releases. But Arch Linux already makes it fairly easy to deploy with their third-party packages and now Fedora and Debian have developers also eyeing possible packaging of the Radeon Open eCosystem software for more easily deploying on those distributions...

https://www.phoronix.com/scan.php?page=news_item&px=Fedora-Debian-ROCm-Work

[Setif]

https://www.phoronix.com/forums/foru...70#post1296870 !!

[makant]

Good news! this is what ROCm needs, easy to install.

I'm testing it on Arch Linux and it took more than 4 hours compiling with a 5950x processor but it works very well. With a 6800xt graphics card before ROCm it processed 1800 steps/hour training the CycleGAN horse2zebra with PlaidML/OpenCL. Now with tensorflow-rocm 14900 steps/hour.. an overwhelming difference. I have tried other networks and so far all have worked without errors.

[Quppa]

Excellent, but still useless for people like me as long as ROCm lacks support for Navi GPUs and GUI apps (Darktable, Blender, DaVinci Resolve, etc.).

[tehehe]

Pretty useless if the only gpu's that are supported by ROCM are datacenter beasts

[bridgman]

Pretty useless if the only gpu's that are supported by ROCM are datacenter beasts

Yep, that's why we have been putting so much work into supporting our other products:

https://github.com/RadeonOpenCompute/ROCm/issues/1617

We have not officially announced support yet but people are running the ROCm stack successfully on RDNA2 today and we are getting pretty close to announcing official support. RDNA1 still needs more work in the math libraries but I believe the core HIP/ROCm is in pretty good shape now.

[pegasus]

See also Easybuild, coming with ROCm support to a friendly HPC cluster near you.

[Danny3]

Finally!
I'm waiting for a long time for the day when I can install it easily on a up-to-date Ubuntu based distro (non-LTS)
I don't want to use 2 years old distro and packages just for the compute part to work.
Also, I don't want to be held back by the kernel version.
Looks like the next Ubuntu LTS (22.04) will probably come with Linux 5.15, which means that will not have any of the wonderful improvements in 5.16 and 5.17
I bet that many of us will just upgrade the kernel manually instead of waiting for another 2 years.
I hope ROCm will have no problem with that.

[MadeUpName]

On Fedora this should be stupid simple. Redhat has all the pieces needed for a working ROCm stack already. Fedora for some completely bizarre reason provides a working ROCm KFD but none of the other packages that are needed to make it useful in any way. All they need to do is tell Koji to start compiling for Fedora while they are compiling for Redhat.

The other thing I don't get is why AMD targets Redhat but not Fedora. If they target Fedora they will have support there and then in 10 years when they fork the next Redhat from Fedora the support will already be there. Brigman told us that AMD prefers to work with newer kernels but in the real world all their support is for the oldest ones.

Am I the only one that finds it interesting that an AMD employee is finally paying attention to packaging ROCm just when MESA 22 is about to be released potentially making ROCm irrelevant?

"ROCm is a disease on this planet and MESA is the cure" - Agent Smith

[bridgman]

The other thing I don't get is why AMD targets Redhat but not Fedora. If they target Fedora they will have support there and then in 10 years when they fork the next Redhat from Fedora the support will already be there. Brigman told us that AMD prefers to work with newer kernels but in the real world all their support is for the oldest ones.

That one is simple - enterprise distros like RHEL require packaged drivers right down to the kernel because the core code moves too slowly to keep up with new HW and SW support. The ROCm userspace components are designed to run over upstream kernels, and we split the package hierarchy to allow use with distros that already have relatively current kernels.

Using Debian-based ROCm with Upstream Kernel Drivers

You can install ROCm user-level software without installing AMD’s custom ROCk kernel driver. The kernel used must have the HSA kernel driver option enabled and compiled into the amdgpu kernel driver. To install only ROCm user-level software, run the following commands instead of installing rocm-dkms:

sudo apt update sudo apt install rocm-dev echo 'SUBSYSTEM=="kfd", KERNEL=="kfd", TAG+="uaccess", GROUP="video"' | sudo tee /etc/udev/rules.d/70-kfd.rules

Fedora has current KFD because we maintain all of the ROCm stack code upstream when it touches established components. Fedora probably has all the amdgpu and LLVM code from ROCm as well.

We do our development against upstream kernels (usually on a mix of Fedora and Ubuntu systems) but then package and test for the older kernels and userspace that our datacenter customers use.

Now that we are catching up on support for consumer hardware it makes having support in consumer distros a lot more interesting. That said, mystro256 has been working on Fedora packaging for a couple of years now as time permits.

BTW if ROCm (open source and upstream) is the disease then what the heck is CUDA ?