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

RE: ROCm 6.4 gpu targets



[Public]

Perhaps this is a known issue, related to the gpu set that the stack is built for, the auto check rule will fire when /dev/kfd is detected
Like https://salsa.debian.org/rocm-team/hipfft/-/blob/debian/unstable/debian/rules#L31
With all of the APU's out there, like with my build machine, a gfx1103, this rule fires but without having built for the gfx1103 target, this check is meaningless. Is there a way to improve the logic to either opt in or check the running matches the building gpu? On fedora we use an opt in for testing while building.
Tom


-----Original Message-----
From: Christian Kastner <ckk@kvr.at>
Sent: Tuesday, July 15, 2025 9:02 AM
To: Cordell Bloor <cgmb@slerp.xyz>
Cc: Rix, Tom <Tom.Rix@amd.com>; ROCm Team <debian-ai@lists.debian.org>
Subject: Re: ROCm 6.4 gpu targets

On 2025-07-15 16:47, Cordell Bloor wrote:
> Hi Tom,
> On 2025-07-15 07:46, Rix, Tom wrote:
>
>> With a ROCm 6.4 compiler, new gpu targets will be possible.
>> What are folk's thoughts about adding at least
>> gfx942,gfx1151,gfx1200,gfx1201?
>
> Those would make sense. We don't need a new compiler to enable gfx942
> in the Debian packages, so that is already in-progress.
>
> The upstream libraries in ROCm 6.4 default to building for gfx1151,
> gfx1200, and gfx1201, so I expect that those would be relatively easy
> to enable in Debian once the compiler and runtime have been updated. I
> would prefer to add gfx11-generic and gfx12-generic than more specific
> gfx11 and gfx12 targets, but it may be that some upstream libraries
> will still fail to build with the generic targets.
>
> Note that the gfx1200 and gfx1201 ISAs are identical in all but name.
> Debian has fallback logic patched into its HIP runtime, which it
> currently uses to support gfx101{0-3} and gfx103{0-6}. We can probably
> just extend those same patches to use fallback logic for gfx120{0,1}
> and skip building for gfx1201 until the generic targets can be used.
>
>> I am also wondering about how to do this without having to touch
>> every package.
>
> This was recently solved. Christian Kastner has uploaded the
> rocm-target-arch tool (provided by pkg-rocm-tools) to Debian
> Experimental. You can see how it is used in rocsparse [1].

Actually that is slightly broken, as I botched the generation of the X-ROCm-GPU-Architecture field: the values are semicolon-separated, instead of space-separated as is custom for d/control. This [3] is a better example for a full conversion.

The better fix is actually to entirely avoid the override_dh_gencontrol, by creating a dh_rocm helper that generates the relevant substitution.
This would make packaging even easier (just add dh-sequence-rocm to build-depends).

I've spoken to people who might we willing to implement dh_rocm at Debconf. It should be easy enough. I myself don't want to do it because Perl is not my thing.

Best,
Christian

> The target
> architectures are defined in
> /usr/share/pkg-rocm-tools/data/build-targets/<target_release> [2].
>
> Sincerely,
> Cory Bloor
>
> [1]:
> https://salsa.debian.org/rocm-team/rocsparse/-/blob/debian/6.4.1-1_exp
> 3/debian/rules?ref_type=tags#L14
> [2]:
> https://packages.debian.org/experimental/all/pkg-rocm-tools/filelist

[3]:
https://salsa.debian.org/rocm-team/rocprim/-/commit/15a5c78abc6708514764cda961924dc9a89fe1a7
--
Christian Kastner


Reply to: