Give the Radeon 8060S a board identity instead of unknown_gpu - #1483
Draft
mgehre-amd wants to merge 1 commit into
Draft
Give the Radeon 8060S a board identity instead of unknown_gpu#1483mgehre-amd wants to merge 1 commit into
mgehre-amd wants to merge 1 commit into
Conversation
mgehre-amd
force-pushed
the
fix/mgehre/gfx11-kb-identity
branch
2 times, most recently
from
September 11, 2026 07:36
0761ab8 to
4122cf7
Compare
The rocm-smi probe recognised only MI product tags, so a Strix Halo run
resolved gpu_type='' and every recipe-KB row keyed to the shared unknown_gpu
namespace. That is one namespace for every unrecognised card, so a recipe
learned on a Strix Halo iGPU was read back on unrelated hardware.
_AMD_GPU_TYPES, the --gpu-type choices, _PRODUCT_TAGS and the preflight warning
all derive from AMD_GPU_DISPATCH_IDENTITIES, so one row there makes the probe
resolve the board, the CLI accept it, provenance record gfx1151 without needing
rocminfo on PATH, and the KB key on the card. The only other change is dropping
spaces from the rocm-smi output before matching, because the derived tag is
RADEON8060S and the card prints "Radeon 8060S Graphics".
Changes:
- The gpu_type is the Magpie script suffix verbatim. _workload_envs pins
{framework}_{gpu_type}.sh with no existence check, so the two names cannot
drift, and _gpu_runner_type needs no new mapping: it passes the value through.
- Adding an RDNA board does not widen the CDNA fast paths. The sglang
FP8-per-token env and the CK block-scale switch gate on _GFX942_GPU_TYPES, a
separate frozenset of the three gfx942 parts, not on the identities table. A
test pins that. It does mean _resolve_amd_gpu_type is no longer what holds
RDNA out of those paths -- it answers "is this a board we know", and the two
call sites do the CDNA3 narrowing themselves.
- model_gate's is_amd becomes True for this board, correcting a Strix Halo
being treated as non-AMD and skipping the AMD-only compat detectors.
- The CU count is read from rocminfo on the card (Compute Unit: 40).
integrate_patch matches it against the cu_num column of AITER GEMM tuning
CSVs to reject artifacts that cannot dispatch on the target.
- Only the 8060S is added, though the same rocm-smi field also names the 8050S
and the 890M. A row for a board Magpie has no script for would pin a file
that does not exist, turning a run that currently works (Magpie falls through
to its native script) into one that fails. Add each row when its script lands.
- No arch fallback. "GFX Version: gfx1151" and torch's gcnArchName name an arch,
not a board, and gfx1151 spans both the 8060S and the 8050S -- so it would
either merge two cards into one KB namespace or pin a vllm_gfx1151.sh that
does not exist. An untabulated SKU keeps falling back to unknown_gpu.
- Normalising the haystack rather than the needle keeps _PRODUCT_TAGS derived
from the identities table as a single expression. Carrying the printed
spelling instead would make it (needle, gpu_type) pairs and pull
multi_node/_internal/gpu_probe.py and its tests into the change for no
behavioural gain. Space-stripping preserves tabs and newlines, so line
structure survives, and the reverse-sorted ordering still keeps "MI300X" from
claiming an "MI300XL".
- The MI product-tag path, the torch gcnArchName fallback and the undetectable
case already have coverage in test_coverage_margin3_unit.py's
test_gpu_type_autodetect_rocm_and_torch_fallback, so the new test file does
not repeat them.
Verified on a Ryzen AI Max+ 395 (rocm-smi reports "Card Series: Radeon 8060S
Graphics", rocminfo reports gfx1151 / 40 CUs): the probe returns radeon8060s,
runner_type is radeon8060s so the pinned script is vllm_radeon8060s.sh,
amd_gpu_dispatch_identity is ('gfx1151', 40), and the canonical_id is
inference:<model>:radeon8060s:vllm:... Against the same host before the change
the probe returned None and the id carried unknown_gpu. Full suite against main:
no failure that main does not also have.
mgehre-amd
force-pushed
the
fix/mgehre/gfx11-kb-identity
branch
from
September 11, 2026 09:47
4122cf7 to
cf823d9
Compare
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
1 participant
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.
Description: what and why
The rocm-smi probe recognised only MI product tags, so a Strix Halo run resolved
gpu_type=''and every recipe-KB row keyed to the sharedunknown_gpu._PRODUCT_TAGSbecomes(needle, gpu_type)pairs and gains one row, so theprobe returns
radeon8060s. Everything downstream already does the right thingwith that:
Tests: added/updated? commands run?
test_gpu_type_kb_identity.pytest_gpu_board_list_single_source.pyVerified on a Ryzen AI Max+ 395, where rocm-smi reports
Card Series: Radeon 8060S Graphics:main_autodetect_gpu_type()Noneradeon8060svllm_radeon8060s.shamd_gpu_dispatch_identity(...)None('gfx1151', 40)gfx_archrocminfoonlygfx1151from the tablecanonical_id...:unknown_gpu:vllm:......:radeon8060s:vllm:...Breaking changes: no
Depends on Magpie shipping
vllm_radeon8060s.sh(AMD-AGI/Magpie#90)PR addresses single concern: yes
Linked issue(s): none
Root cause is upstream (Magpie/TraceLens/GEAK/IntelliKit/AgentKernelArena): no