[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ROCm on riscv64



Hi Sakura286,

On 2025-10-13 02:42, Sakura286 wrote:
> ... we would enable the ROCm packages up to and including the HIP Runtime, but not the math libraries.

Does this mean that Debian ROCm team accept riscv64 patch for HIP Runtime now?

Yes. I'll add riscv64 to the build targets for my ROCm 6.4 uploads. If they build, then great. If they fail, then we will accept patches.

Christian Kastner suggested a while ago that we could use build profiles for components that depend on ROCm [1]. I wonder if the default state for that build profile could be adjusted on a per-platform basis so that we don't need to hardcode a list of architectures into every package that depends on ROCm?

The real trouble comes from packages that have some extra ROCm functionality, like ucx. If ROCm is broken on riscv64 or arm64, we end up needing to go through all the reverse dependencies and patching their d/control and d/rules for architecture-specific Build-Depends, architecture-specific binary packages, and architecture-specific build rules that are all really just predicated on 'is ROCm available on this host architecture?'

We can't just put the supported architecture list in a Makefile, since that wouldn't be able to change anything in d/control, and something like is-architecture-64bit isn't able to optionally change the Build-Depends list. So, I wonder if the Build Profiles machinery might be a pathway to a clean solution such that we can still have 'best effort' support for unusual architectures like arm64, ppc64el, and riscv64 without compromising the quality of our amd64 support.

Sincerely,
Cory Bloor

[1]: https://lists.debian.org/debian-ai/2025/05/msg00017.html


Reply to: