Re: RFC: Centralized ROCm target list + utility
Hi Cory,
thank you for the quick response.
On 2025-06-24 07:53, Cordell Bloor wrote:
> On 2025-06-23 13:55, Christian Kastner wrote:
>> <codename> can be a symlink to some other <codename>.
>>
>> Currently, the trixie list consists of the typical targets, and
>> unstable
>> and experimental are symlinks to trixie.
>
> I would note the documented behaviour of rocm_enumerate_devices, as
> that script is queried by:
> 2. CMake to specify the default value of CMAKE_HIP_ARCHITECTURES [2]
What would CMAKE_HIP_ARCHITECTURES entail? I did a grep on rocrand-6.4
with no result, but maybe it's used in some indirect way.
Would setting ROCM_TARGET_LST=/.../<codename> remove the need to
populate AMDGPU_TARGETS?
> As such, I would recommend that your proposed master list follow the
> format of the rocm target list,
Sure, no problem. I think supporting comments would have been a nice
feature but the canonical interface is through the utility. And we
should also add a d/README.Debian with more info anyway.
Though I can't find for what this format actually is?
>> $ rocm-arch-support
>> -> Prints space-separated list of targets for the current
>> distribution: "gfx803 gfx900 gfx906 gfx908 ..."
>
> We should clearly distinguish build targets from supported GPUs.
> Consider that users may not see gfx1031 in the current values of this
> list, but it works fine on Debian because we've implemented the gfx1030
> fallback. This will continue when we switch the build target to
> gfx10-3-generic (or spirv).
How would we do that?
The primary goal of this particular utility is build support. So one way
to disambiguate would be to rename the utility to 'rocm-build-support'
to make this distinction clearer.
> It can probably be a separate tool, but the average user may also
> benefit from a simple `is-my-gpu-supported` command.
It's definitely a general goal, and I briefly considered this for this
specific utility, because something like a "--my-gpus" argument could be
used to emit build targets just for the developer's machine.
But that would have meant adding a few dependencies. I wanted this first
draft to be a minimal script upon which to iterate, so I considered this
feature out-of-scope for this first version.
>> $ rocm-arch-support --for-build
>> -> Prints semicolon-separated list of targets for the current
>> source
>> package: "gfx803;gfx900;gfx906;gfx908;..."
>> -> use as eg: AMDGPU_TARGETS="$(rocm-arch-support --for-build)"
>
> I'm bikeshedding, but semi-colon separated is specifically a CMake
> convention. The option should be `--cmake` or something similar. Other
> build tools may have different conventions.
The semicolon is just the default, --sep can be used to override this
with an arbitrary string.
This default was chosen because --for-build is meant to be exclusively a
package build helper (to be called in an unpacked source with a debian/
subdir), and there we currently use the architectures
semicolon-separated in d/rule.
There will eventually be more logic tied to --for-build, other than
inferring the target distribution, though that logic is a bit too early
to address now.
Best,
Christian
Reply to: