Stop reporting unknown GPU archs as MI300X (baremetal) - #1460
Merged
Merged
Conversation
detect_gpu_label() fell through to "MI300X" for any arch outside gfx942/gfx950, so a Strix Halo (gfx1151) host was reported as an MI300X. The label is substituted into the operator prompt that setup prints as "GPU: <label>", so the fabricated part number gets pasted into an optimization request and forwarded as --gpu-type mi300x. That selects the wrong Magpie runner scripts and keys recipe-KB rows to hardware the run never executed on, quietly making baseline numbers incomparable across sessions. Unrecognized architectures now report the probed gfx id, and an undetectable one reports "unknown". Both are honest values that fail visibly against the --gpu-type choices instead of resolving to a valid but wrong MI part number. Changes: - The Python-side probe (gpu_types._autodetect_gpu_type) was already correct -- it returns None for unmapped archs -- so only the shell helper fabricated a label. Deliberately did not add a gfx1151 mapping: Hyperloom ships no Magpie runner scripts or aiter kernels for it, so claiming support would be a worse lie than the one being removed.
mgehre-amd
force-pushed
the
fix/mgehre/gpu-label-not-mi300x
branch
from
September 9, 2026 13:23
b7449dd to
4dc1479
Compare
chaojhou
approved these changes
Sep 14, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
detect_gpu_label()ininstall_baremetal.shfell through toMI300Xfor anyarch outside gfx942/gfx950, so a Strix Halo (gfx1151) host was reported as an
MI300X. The label is substituted into the operator prompt setup
prints as
GPU: <label>, so the fabricated part number gets pasted into anoptimization request and forwarded as
--gpu-type mi300x.Use the gfx target for unrecognised archs.
The support for Ryzen AI parts itself will come in a follow-up PR.
Tests: added/updated? commands run?
No automated test: the installer is shell, and exercising
detect_gpu_labelfrom pytest means extracting the function out of the script and stubbing
rocm-smi, which is more harness than the four-line change warrants. Verifiedby hand against the real binary instead (below).
shellcheck findings on the installer are byte-identical to
main.Verified on a Ryzen AI Max+ 395 (rocminfo reports gfx1151):
detect_gpu_label <arch>maingfx1151MI300Xgfx1151gfx90aMI300Xgfx90a""(nothing probed)MI300Xunknowngfx942/gfx950MI300X/MI355XBreaking changes: no
Only the fallback arm changes. gfx942/gfx950 and the rocm-smi product-name path
behave exactly as before.
PR addresses single concern: yes
Linked issue(s): none
Root cause is upstream (Magpie/TraceLens/GEAK/IntelliKit/AgentKernelArena): no