fix(AMD): recognise the RX 6950 XT, 6850M XT and 6550M instead of leaving them on CPU torch - #10746
Conversation
…ving them on CPU torch The seven copies of the AMD marketing-name to gfx table cover the launch RDNA 2 parts and not the refresh ones, which carry their own model number: RX 6950 XT (Navi 21), RX 6850M XT (Navi 22) and RX 6550M (Navi 24) matched no arm. On a host where the name is the only arch source -- Windows with the Adrenalin driver and no HIP SDK -- that means no arch, so CPU-only torch on a card the gfx103X-all index does cover. The same table decides whether Settings > System can report a card PyTorch cannot use, so the gap also cost the message: an unmatched adapter reads as one the stack declines on purpose, and the panel falls through to a bare "No visible GPU" beside a card the OS is listing. Adds the three names to all seven copies, a parity case for each so a future copy that misses one fails naming the file, and a backend test pinning that a Windows adapter named only by its marketing string establishes a mismatch.
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
for more information, see https://pre-commit.ci
|
Confirmed the gap is still there in studio/install_python_stack.py and studio/backend/utils/hardware/hardware.py, where the RDNA 2 arms stop at RX 6900 and the refresh names fall through to CPU torch. Will get this reviewed. |
|
Confirmed the table in studio/backend/utils/hardware/hardware.py and the six installer copies still have no arm for the 6950 XT, 6850M XT or 6550M, so those names fall through to CPU torch. This also flips those hosts from a CPU wheel to gfx103X-all ROCm torch, which nobody has run on RDNA 2 silicon; could you say whether you want that routed for all three or only the reported 6950 XT before I review? |
|
Reviewed this alongside the other six open AMD PRs. Verdict: real issue, correct fix, no regression risk. I have pushed one commit to this branch filling two remaining gaps of the same kind. Details below. Before and afterBefore:
After: they resolve to This is a real issue, not a cosmetic one. Filing the RX 6850M XT (Navi 22) under the gfx1030 arm is fine for the same reason. Evidence that it worksSensitivity. I ran this PR's test files against main's tables: 6 parity failures plus 1 backend failure. Against the PR's tables: 0. So the tests genuinely detect the defect rather than passing either way. Real Windows hardware. Ran base versus head on a self-hosted Windows 11 gfx1151 Strix Halo runner, PowerShell 5.1 Desktop, comparing failing test IDs rather than counts:
Verdict NO_REGRESSION. The 87 to 97 move is this PR's own added parametrisation. Non-AMD. I drove One thing I addedGoing through every shipped RDNA2 SKU against the table, two more cards of exactly the same class were still missing, both Navi 24:
I pushed those to the gfx1034 arm in all six source copies plus the two test tables. 97 tests pass. RDNA1 (RX 5700 XT and friends) stays unmatched, which is correct, those are not supported. What the hardware could not answerThe only AMD hardware in the pool is gfx1151 Strix Halo. There is no RDNA2 card anywhere, so nothing here is an end-to-end demonstration that an RX 6950 XT now installs correctly. What was measured is the table logic and the parity between the six copies, on a real Windows box under real PowerShell 5.1. The base leg also cannot show the defect, because the PR modifies its own test file and the CI checks out each state whole, so read the Windows result as "the fix and its tests are green on Windows" rather than "the bug was reproduced and closed". Happy to merge this. |
for more information, see https://pre-commit.ci
|
@codex review |
|
@codex security review |
|
On the question of before/after UI screenshots for this PR: I looked into it properly and concluded they are not producible on any hardware I can reach. Recording why, since "we skipped it" and "it cannot be shown here" are different claims. The PR edits
So the user-visible effect is real but narrow, and reaching it needs all three of: Windows, an RDNA2 Radeon, and a driver that published no Shooting the pair anyway would produce two identical images, which reads as "this PR changed nothing" and would be worse than saying this. The evidence for the change is the table logic itself: 97 tests pass on a real Windows 11 gfx1151 box, and running this PR's tests against main's tables gives 6 parity failures plus 1 backend failure, so the tests do detect the defect rather than passing either way. The rest of the PR's visible effect is installer output, not the web UI, so it is terminal text rather than something a screenshot pair would add to. |
|
Codex Review: Didn't find any major issues. 👍 Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
Comments only, no behaviour change. Keeps every load-bearing fact: the issue number, that 6850M XT is Navi 22 filed under the Navi 21 arm deliberately, that every RDNA 2 row resolves to gfx103X-all so the exact id picks no different wheel, and that RDNA 1 stays declined on purpose.
|
CI triage note, since several checks here are red and none of them are this PR. Posting the evidence rather than asking anyone to take it on trust. 1. This was a transient breakage on
CI runs against main as of run time, and these runs predate 12:48, so they caught the window in between. No PR in this batch touches 2. The three 3. I ran that test on a clean So: buckets 3 and 3 and 3, in the runbook's terms. Nothing here blocks these PRs, and I have re-run the affected jobs now that main carries the fix. |
|
Merged current The branches had drifted far enough that CI was testing a stale combination rather than the change. The clearest case:
Merged cleanly with no conflicts. Verified before pushing:
Two other red checks that were also main's rather than this branch's, for the record:
Still genuinely outstanding and not from this branch: |
|
@codex review |
1 similar comment
|
@codex review |
|
Codex Review: Didn't find any major issues. 🎉 Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
|
Re-validated on current main (1e07231) with the branch merged, on real gfx1151 Strix Halo hardware on both Linux and Windows, and through a hermetic installer matrix. Summary: real issue, correct fix, no regression on NVIDIA, Mac, CPU, Windows or WSL. One commit pushed, comments only. Before and afterBefore: After: they resolve to gfx1030 or gfx1034, and every RDNA 2 row routes to the same EvidenceReal hardware, self-hosted gfx1151, base 1e07231 versus this head:
The added tests move base to head by exactly the new parametrisations; nothing that passed on main fails here. Installer matrix: Hosted runners: Local: 67 of 67 shell installer suites, the full One thing worth knowingThe RX 6850M XT is Navi 22, which is gfx1031. The table files it under the gfx1030 arm, which is how the RX 6700, 6750 XT and 6800M are already filed on main, and torch is unaffected because gfx1030 through gfx1036 all take Old installs and updatingA host that already has ROCm torch keeps its wheel: the name table is consulted only when no runtime or driver arch is available. A host with one of these cards that was routed to CPU torch because the name was unknown moves to the ROCm wheel on its next update. That is the point of the change, and it is the same path every already-listed RDNA 2 card takes. The same applies to a hand-built ROCm torch on one of these cards with no AMD SDK metadata: the existing generic-wheel repair replaces it with the per-gfx wheel, exactly as it does for an RX 6600 today, because the installer cannot tell a working custom build from a kernel-less one. Installs with a matching ROCm wheel, CUDA on NVIDIA-primary or mixed hosts, CPU on Intel-only hosts, and an explicit CPU backend or Not tested hereThe pool is gfx1151 only, so no RDNA 2 card exercised the end-to-end Windows name-only path; what was measured is the table logic, its parity across the seven copies, and the absence of movement everywhere else. NVIDIA, Intel XPU and Apple MLX were covered by the matrix and the repository's hardware spoof tests, not by hardware. |
|
@codex review |
1 similar comment
|
@codex review |
|
Codex Review: Didn't find any major issues. What shall we delve into next? Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
2 participants
The AMD marketing-name → gfx table covers the launch RDNA 2 parts and not the refresh ones, which carry their own model number.
RX 6950 XT(Navi 21),RX 6850M XT(Navi 22) andRX 6550M(Navi 24) match no arm in any of the seven copies.On a host where the name is the only arch source — Windows with the Adrenalin driver and no HIP SDK — no match means no arch, so the installer picks CPU-only torch for a card
gfx103X-alldoes cover. Reported in #10468 on a 6950 XT: Settings > System showed "No visible GPU" while Task Manager listed the card.The same table also cost the explanation.
_amd_device_can_establish_a_mismatchdecides whether the panel can say "PyTorch cannot use this card" and list it. When the Windows driver wrote noAdapterFamily— common, and the code's own note says the gfx1151 box's driver wrote none at all — it falls back to this table. An unmatched adapter therefore reads as one the stack declines on purpose, and the panel drops it entirely instead of showing what #9858 and #8620 built for exactly this case.Before / after
studio/install_python_stack.py::_gfx_arch_from_gpu_name, run on Windows 11 26200:The RDNA 1 row is the control: it is declined deliberately and stays declined.
What changed
Three names added to all seven copies (
install.shtwice,install.ps1,studio/setup.sh,studio/setup.ps1,studio/install_python_stack.py,studio/backend/utils/hardware/hardware.py), plus:test_rocm_arch_table_parity.py, so a future edit that misses a copy fails naming the file. Verified non-vacuous: reverting the six source files fails 6 of them, each pointing at a different copy.tests/studio/test_amd_name_arch_r9700.ps1.6850M XTis Navi 22 and joins the 6750 / 6700 arm as those already do. Every RDNA 2 row resolves togfx103X-all, so the exact id inside the family picks no different wheel — the parity suite documents that grouping as deliberate.Nothing about arch → index family, the wheel allowlist, or any other generation moves. 262 tests pass across the two suites; on this Windows host
tests/studio/installhas 71 pre-existing Linux-path failures, identical set on base and head.What a matched card actually gets
Worth stating, since the fix is only useful if there is something on the other side. Unpacking our own current Windows prebuilt:
Compiled code objects, not string-table mentions, so GGUF inference has real kernels for these cards. AMD publishes matching Windows torch wheels (
torch-2.10.0+rocm7.13.0-*-win_amd64onrepo.amd.com/rocm/whl/gfx103X-all).Training is a separate question this PR does not answer. The bf16 trap from #5337 is handled in main (
arch_lacks_bf16()flags anygfx10*and_gpu_init.pyreplaces torch'sis_bf16_supported, which returns True unconditionally on ROCm). Two items from the closed #6124 are still absent from main and unrelated to this diff: no RDNA 2 torch-version cap, and nogfx103Xguard onfor_inference().Hardware coverage
No hosted GitHub runner has an AMD GPU. The self-hosted Strix Halo runner is Linux gfx1151 and cannot exercise an RDNA 2 Windows path, so this table is the test report.
gfx103X-all6e45c61Scope
Two of the three names are beyond the letter of #10468, which is a 6950 XT report.
RX 6850M XTandRX 6550Mcame out of sweeping every RX 6000 marketing name against the table and they fail identically; leaving a known-missing name sitting in a line this PR already edits seemed worse than the wider diff. Cutting back toRX 6950alone is a one-line change per copy if you would rather keep it to the report.The training paragraph above is deliberate too. The fix is real and the thing it unblocks is unverified, and a body that stated only the first half would read as a promise of the second.
Bottom line. Solid: the routing change, proven by before/after on the real functions and pinned by tests that fail without it, with no other generation touched. Biggest gap: not one line of this ran on RDNA 2 silicon, and nobody on the team has an RDNA 2 card — so it fixes detection, and whether a 6950 XT then trains is untested by anyone, on any OS, since #7277 landed.