Debian is packaging ROCm - help them out!

[Maxzor]

The compute stack ROCm is currently packaged by AMD for a number of Linux distributions, and while the effort is valuable, regardless of the quality of the software open-sourced, they do a pretty terrible job at software distribution.
The good stuff is that they are realizing that they can do better.

---

Other distributions

Arch people have packaged ROCm 4.5.2. in AUR, this is quite a pure mirror of the current AMD package structure :
https://github.com/RadeonOpenCompute/ --> https://github.com/rocm-arch/rocm-arch

---

Debian

AMD engineers, notably Cordell Bloor, have started to work with Debian maintainers, gathered in a ROCm packaging team, notably Étienne Mollier. The goal is make a sound packaging, which means revisiting how the stack is displayed and exposed, and to put “ROCm one ‘apt install rocm’ away from users”.

There are quite a lot of topics to cover, among which :

• the AMD llvm flavor and the upstreaming status
• the kernel module `amdgpu` (including the amdkfd bits https://github.com/RadeonOpenCompute/ROCK-Kernel-Driver) flavor and the upstreaming status
• how to build the meta-package tree and handle the dependency graph, the conflicts, possibly virtual packages aswell

There are open packaging work sessions with jitsi meetings happening currently, feel free to join! Now is the time to package it right. Best way is to approach via the mailing list IMO : [email protected]

The ROCm stack and source is currently split over three github organisations :

1. https://github.com/RadeonOpenCompute/
2. https://github.com/ROCm-Developer-Tools/
3. https://github.com/ROCmSoftwarePlatform/

From: https://lists.debian.org/debian-ai/2.../msg00048.html

Generally speaking, the lowest-level components are found under RadeonOpenCompute, the middle-of-the-stack components are found under ROCm-Developer-Tools and the high-level libraries and frameworks are found under ROCmSoftwarePlatform.

From: https://lists.debian.org/debian-ai/2.../msg00053.html

The good news is that ROCm is currently going through a project-wide reorganization of our installed file layouts (e.g. https://github.com/ROCmSoftwarePlatf...OLVER/pull/351). There were some questions as to the implementation, so we've stepped back to discuss this feature more before proceeding. So, now is a particularly good time to clearly state the needs of distributions, and ensure they are considered and any issues are addressed.

The source and collaborative space for this packaging development is on Debian's gitlab instance, salsa : AMD Yes! ROCm Team · GitLab.

---

This effort is pretty important for ROCm to reach a wide audience in the Linux world. The moment ROCm is packaged into Debian, it will trickle down and snowball to Ubuntu and the other downstream distributions. Hello Michael, I think that on top of the regular welcome news about AMD ROCm, giving some publicity to this effort could help giving general traction to ROCm : I have quite written the article for you and would be happy to flesh it out further.

[Mystro256]

*Cough* https://lists.fedoraproject.org/arch...PL2ZPA27UJXXL/ *Cough*

[cgmb]

I'm glad to see further interest. I keep a gist with my ROCm build script for Debian unstable. My time for working on this is each Monday at ~5:00pm MST, and I generally hang out on Jitsi while doing so. Feel free to email me for the meeting link and drop in.

the AMD llvm flavor and the upstreaming status

I discussed the differences between the AMD LLVM and the upstream LLVM a bit around the time of the ROCm 4.2.0 release. I haven't tried it myself, but I suspect that clang-13 could build ROCm if the right options were enabled.

the kernel module `amdgpu` (including the amdkfd bits https://github.com/RadeonOpenCompute/ROCK-Kernel-Driver) flavor and the upstreaming status

As I understand it, everything needed for basic functionality is already in the upstream kernels. However, I'm not very familiar with the lowest levels of the ROCm stack.

[piorunz]

That's a great news! Many users are waiting for this. There is a thread on AMD forums:

https://community.amd.com/t5/drivers-software/opencl-linux-debian-bullseye-sid/td-p/441901

Will that ROCm package which is being created, support RDNA2?

[Maxzor]

Hello, a quick update in this thread is due, and you can follow the packaging progress here.

Official Debian packages for 4.5.2 are being produced, internally reviewed by the packaging team, and entering the publishing pipeline which starts with the Debian NEW queue.
So far, very few are available in the experimental archive, which is the first stage before the unstable/sid and then the testing archives, which eventually leads to stable. Upon entering unstable, the packages become targets for the next Ubuntu stable release. Unfortunately, ROCm will most likely not be fully packaged for Ubuntu Jammy LTS.
Once the packages are uploaded to the archives, you can track their state here.

Good news is that the process is very well started, and that there is a first iteration of official packages for quite the whole stack already. The surface area with AMD engineers, on the debian-ai mailing list, with virtual meetings, and on AMD githubs, has been steadily increasing. There is the infrastructure to somewhat rapidly update the packaging for the next ROCm release.

You can find some outstanding points in the first link, the gist of it is that the install paths for the stack, the build system and using the stack with the upstream compiler toolchain, have given and are making some friction, but this is moving forward.

P.S. Jeremy Newton is making also significant progress on Fedora, and has been great enough to help Debian too!

[Maxzor]

That's a great news! Many users are waiting for this. There is a thread on AMD forums:

https://community.amd.com/t5/drivers-software/opencl-linux-debian-bullseye-sid/td-p/441901

Will that ROCm package which is being created, support RDNA2?

Official support for GPU architectures is dependent on AMD, RDNA1&2 is coming rapidly as far as I know.