Skip to content

fix[next]: Detect ROCm device architecture instead of hard-coding gfx942 - #2796

Open
tehrengruber wants to merge 1 commit into
GridTools:mainfrom
tehrengruber:fix-rocm-device-arch
Open

fix[next]: Detect ROCm device architecture instead of hard-coding gfx942#2796
tehrengruber wants to merge 1 commit into
GridTools:mainfrom
tehrengruber:fix-rocm-device-arch

Conversation

@tehrengruber

@tehrengruber tehrengruber commented Aug 14, 2026

Copy link
Copy Markdown
Contributor

Problem

_query_device_arch() in otf/compilation/common.py returns a hard-coded "gfx942" (MI300A) for ROCm devices — an old TODO. Every GPU binary is therefore compiled for gfx942 only (get_device_arch() feeds both the DaCe and the gtfn/CMake build); on any other AMD GPU the fat binary contains no matching code object and the first kernel launch segfaults inside libamdhip64 (the stub-based hipLaunchKernel does not return a clean error for this case). Observed on a gfx1103 APU; setting HIPARCHS explicitly works around it.

Fix

Query the architecture from the device via cupy.cuda.runtime.getDeviceProperties(0)["gcnArchName"], stripping the target-feature suffix (e.g. gfx90a:sramecc+:xnack-gfx90a), with the same error handling as the CUDA branch. The CUDAARCHS/HIPARCHS environment override precedence is unchanged. Verified on a gfx1103 APU (ROCm 7.2): detection returns gfx1103.

AI disclaimer: Description and code were developed with the help of LLMs. Code was reviewed in detail, description briefly read, too verbose, but doesn't matter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant