Re: RFC: Centralized ROCm target list + utility

[Cordell Bloor <cgmb@slerp.xyz>]

Hi Tim and Christian,

On 2025-06-26 11:01, Tim Flink wrote:
> If this is going to be a utility that sees wider usage, would 
> something like 'rocm-target-isa' be a better choice? I just wonder if 
> there would be an assumption that arch refers to system arch (amd64, 
> aarch64 etc.) instead of shader architecture.
>
> If it's going to be used by folks who are already familiar with what 
> the shader architectures are, this may not be a big concern, though. 

I'm afraid I don't understand why ISA would be less confusing, as both 
"arch" and "isa" could refer to either the CPU or GPU. If you wish to 
distinguish between the CPU and the GPU, the typical terminology used is 
"host" and "device". Alternatively, clang sometimes uses "offload" in 
place of "device".

The term "arch" is used to refer to gfx targets in many places. It is 
the terminology used by cmake [1], clang [2][3], and gcc [4] when 
dealing with the gfxids, and it has a direct correspondence to the sm 
arch CUDA terminology as well [5][6]. Since the output of this Debian 
utility is often going to be passed as the value for CMake or clang 
options that refer to it as "architecture" / "arch" (and never as 
"isa"), I do think "arch" is a better match.

For comparison, I don't know any place where "isa" is used to describe 
the gfx number, aside from this proposed utility. When AMD writes its 
ISA manuals, they're for the entire family of architectures (e.g., all 
of RDNA 4 gets one manual and gfx1200 / gfx1201 aren't even mentioned [7]).

If we need to clarify that the utility is reporting GPU architectures, I 
would qualify it with "device", making it "rocm-target-device-archs". 
With that said, it's ultimately just a name and the actual functionality 
is what really matters. I'm just happy to see it exist.

On 2025-07-02 00:49, Christian Kastner wrote:
> FYI I intend to upload this sometime during this week, so that packages
> can make use of it.
>
> I think the main contentious design designs should be addressed, namely:
>
>    * Name of the utility for building: rocm-target-isa
>    * Name of the binary package field documenting what was used
>     X-ROCm-GPU-ISA
>
> Please respond soon if you object to this.

I would just suggest that you consider whether it's better to be "ROCm" 
or "AMD". If a package were built with GCC's support for AMD GPUs [4] 
(which is not part of ROCm), would you want it to have this tag? If so, 
I would replace "ROCm" with "AMD".

I don't think I would say that I "object", because your names are 
reasonable and I could live with them. I think they could be better, and 
I've explained why, but it's ultimately not a big deal.

Sincerely,
Cory Bloor

[1]: https://cmake.org/cmake/help/v4.1/variable/CMAKE_HIP_ARCHITECTURES.html
[2]: 
https://rocm.docs.amd.com/projects/llvm-project/en/docs-6.4.1/conceptual/code-portability.html
[3]: e.g., --offload-arch=<target-id>, and the amdgpu-arch utility
[4]: https://gcc.gnu.org/onlinedocs/gcc/AMD-GCN-Options.html
[5]: https://cmake.org/cmake/help/v4.1/prop_tgt/CUDA_ARCHITECTURES.html
[6]: 
https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#ptx-isa-version-8-8
[7]: 
https://www.amd.com/content/dam/amd/en/documents/radeon-tech-docs/instruction-set-architectures/rdna4-instruction-set-architecture.pdf