Installer: enable ROCm torch on RDNA2 (gfx1030-1036) on Windows - #7277
Conversation
repo.amd.com publishes a gfx103X-all wheel family with win_amd64 torch 2.9.1/2.10.0/2.11.0+rocm7.13.0 (cp310-313), but both Windows allowlists omitted RDNA2, so RX 6000 cards (gfx1030/1032, etc.) fell back to CPU-only torch. Map gfx1030-1036 to gfx103X-all in install.ps1 ($archFamilyMap) and install_python_stack.py (_GFX_TO_AMD_INDEX_ARCH). No torch floor (mirrors gfx110X-all: newest wheel, no _grouped_mm bug on RDNA2). NVIDIA/Mac/CPU and Linux paths untouched; gfx906 stays CPU (no wheels published).
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request adds mappings for RDNA 2 (RX 6000) GPUs (gfx1030 through gfx1036) to the gfx103X-all target in both install.ps1 and studio/install_python_stack.py. There are no review comments, and I have no feedback to provide.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d8ff915a25
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
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".
| "gfx1036" = "gfx103X-all"; "gfx1035" = "gfx103X-all" # RDNA 2 (RX 6000) | ||
| "gfx1034" = "gfx103X-all"; "gfx1033" = "gfx103X-all" | ||
| "gfx1032" = "gfx103X-all"; "gfx1031" = "gfx103X-all" | ||
| "gfx1030" = "gfx103X-all" |
There was a problem hiding this comment.
On the normal install.ps1 path, this new map installs a +rocm wheel and then invokes unsloth studio setup with UNSLOTH_INSTALL_ROLLBACK_MANAGED=1 (install.ps1:2520-2580). However, studio/setup.ps1:3062-3068 and its stale-venv list at studio/setup.ps1:2773-2779 still omit every gfx103* target, so it classifies that new ROCm wheel as requiring CPU. The stale check then exits with an installer-managed repair error (studio/setup.ps1:2810-2814) instead of repairing it, causing fresh RX 6000/RDNA2 installs through this script to fail. Add the same RDNA2 keys to both setup.ps1 lists.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Good catch, thanks. Synced both studio/setup.ps1 lists to include gfx1030-1036: the stale-venv $_rocmWheelArches (so installer-managed setup no longer flags the fresh RDNA2 +rocm wheel as stale and exits) and the $archFamilyMap (so a standalone unsloth studio setup routes RX 6000 to gfx103X-all). Also updated the supported-arch warning. Pushed in 1a36636.
|
@codex review |
|
Codex Review: Didn't find any major issues. Hooray! 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". |
get_torch_index_url() chooses the ROCm wheel index purely from the ROCm runtime
VERSION, never from the GPU's gfx arch. gfx1033 (Van Gogh, the Steam Deck APU) is
mapped to gfx103X-all in _GFX_TO_AMD_INDEX_ARCH, so a Deck was routed to ROCm
wheels the moment any ROCm runtime was present.
Those wheels install and then return wrong answers rather than refusing. With an
identical seed, init and data over 60 SGD steps, CPU converges 0.9710 -> 0.1148
while the GPU gives:
rocm7.1 / torch 2.10 -0.7765 -> nan
rocm7.2 / torch 2.11 0.0000 -> 1.0000 -> 17.4674
native gfx1033, TheRock torch 2.13 + ROCm 7.15 nan
A negative MSE loss is not attainable. torch.autograd.gradcheck fails in float64
on all three ("backward is not reentrant" on the native build), and the runtime
raises HSA_STATUS_ERROR_EXCEPTION 0x1016 under load. Forward math is fine --
full-module forward matches CPU to 4.2e-07 and loss to seven significant figures
-- so this is specifically the backward pass, and three independent ROCm builds
including AMD's own native gfx1033 one fail identically. Measurements in
studio/ROCM_RDNA2_APU.md.
Scope is exactly the arch that was measured. This is deliberately NOT "everything
outside AMD's hardware support table": unsloth serves several archs AMD does not
list, on purpose and with evidence -- gfx906 (MI50 / Radeon VII) through the
rocm6.3 legacy index, verified there with torch 2.7.0, and gfx1031-gfx1036
through gfx103X-all (unslothai#7277). Gating on that table would have silently dropped
support that is known to work; a test pins those archs as untouched.
The gate is inline in get_torch_index_url rather than a helper because several
harnesses extract that function on its own, and a helper they did not also
extract would be an undefined command whose negation sent every ROCm case to the
cpu index. A pinned UNSLOTH_TORCH_INDEX_URL still returns before this point, so
forcing ROCm remains possible.
get_torch_index_url() chooses the ROCm wheel index purely from the ROCm runtime
VERSION, never from the GPU's gfx arch. gfx1033 (Van Gogh, the Steam Deck APU) is
mapped to gfx103X-all in _GFX_TO_AMD_INDEX_ARCH, so a Deck was routed to ROCm
wheels the moment any ROCm runtime was present.
Those wheels install and then return wrong answers rather than refusing. With an
identical seed, init and data over 60 SGD steps, CPU converges 0.9710 -> 0.1148
while the GPU gives:
rocm7.1 / torch 2.10 -0.7765 -> nan
rocm7.2 / torch 2.11 0.0000 -> 1.0000 -> 17.4674
native gfx1033, TheRock torch 2.13 + ROCm 7.15 nan
A negative MSE loss is not attainable. torch.autograd.gradcheck fails in float64
on all three ("backward is not reentrant" on the native build), and the runtime
raises HSA_STATUS_ERROR_EXCEPTION 0x1016 under load. Forward math is fine --
full-module forward matches CPU to 4.2e-07 and loss to seven significant figures
-- so this is specifically the backward pass, and three independent ROCm builds
including AMD's own native gfx1033 one fail identically. Measurements in
studio/ROCM_RDNA2_APU.md.
Scope is exactly the arch that was measured. This is deliberately NOT "everything
outside AMD's hardware support table": unsloth serves several archs AMD does not
list, on purpose and with evidence -- gfx906 (MI50 / Radeon VII) through the
rocm6.3 legacy index, verified there with torch 2.7.0, and gfx1031-gfx1036
through gfx103X-all (unslothai#7277). Gating on that table would have silently dropped
support that is known to work; a test pins those archs as untouched.
The gate is inline in get_torch_index_url rather than a helper because several
harnesses extract that function on its own, and a helper they did not also
extract would be an undefined command whose negation sent every ROCm case to the
cpu index. A pinned UNSLOTH_TORCH_INDEX_URL still returns before this point, so
forcing ROCm remains possible.
1 participant
Summary
On Windows, AMD RDNA2 cards (RX 6000 series: gfx1030/1031/1032, etc.) fall back to CPU-only PyTorch even though AMD publishes working ROCm wheels for them.
repo.amd.com/rocm/whl/gfx103X-all/serveswin_amd64torch 2.9.1/2.10.0/2.11.0+rocm7.13.0 (cp310-313), but both Windows arch allowlists omitted the gfx103X family, so the installer routed RDNA2 to CPU.Reported by RX 6800 / RX 6900 XT (gfx1030) and RX 6600 XT (gfx1032) users.
Fix
Map gfx1030-1036 to the
gfx103X-allfamily in the two Windows allowlists:install.ps1$archFamilyMapstudio/install_python_stack.py_GFX_TO_AMD_INDEX_ARCHNo torch floor is added: RDNA2 mirrors
gfx110X-all(installs the newest wheel). Thetorch._grouped_mmnull-pointer bug that forces a floor on gfx120X/Strix does not affect RDNA2, which has no MoE grouped-mm path. The unlisted-arch default atinstall_python_stack.py:1586-1588installs a baretorch/torchvision/torchaudiotrio from the arch index, and the ROCm install is non-fatal on failure (keeps the existing build).Verified
repo.amd.com/rocm/whl/gfx103X-all/torch/serveswin_amd64wheels for cp310-313 (torch 2.9.1/2.10.0/2.11.0+rocm7.13.0).UNSLOTH_ROCM_GFX_ARCH) through the real selection code:gfx1030/1031/1032/1036->https://repo.amd.com/rocm/whl/gfx103X-all/gfx1103->gfx110X-all,gfx1151->gfx1151,gfx1201->gfx120X-all(all unchanged)gfx906/gfx900-> CPU (unchanged; AMD publishes no wheel family for these)install.ps1parses cleanly (PowerShell AST, 0 errors).Scope
AMD-only, additive keys. NVIDIA, Mac, Intel, CPU, and Linux paths are untouched (these maps are Windows ROCm-only). gfx906 (MI50) stays on CPU because
repo.amd.compublishes no gfx906 wheel family (HTTP 403); it already works on Linux via the pytorch.org rocm index.Note
RDNA2 is excluded from aotriton, so flash-attention stays off on these cards (already handled by
is_rdna); QLoRA relies on bitsandbytes-ROCm. This PR fixes wheel selection so RDNA2 gets a GPU torch build instead of CPU; runtime fine-tuning stability on RDNA2 (bitsandbytes kernels) is a separate follow-up.