Repository navigation
Unsloth Studio (AMD RDNA 1, Windows): install ROCm torch for the RX 5700 XT from AMD's multi-arch index - #11755
Merged
danielhanchen merged 25 commits intoSep 29, 2026
Conversation
…rch nightly index RDNA 1 has no family on repo.amd.com, so every Windows installer put an RX 5700 XT on CPU torch and said so (unslothai#8529). AMD's multi-arch nightly index carries per-card kernel packs for it: `torch[device-gfx1010]` resolves torch plus the gfx1010 pack. With that torch, unslothai#11615 and the zoo's unslothai#1356 / unslothai#1316, the card trains (unslothai#11614). install_python_stack.py, install.ps1 and setup.ps1 now route gfx1010 / gfx1011 / gfx1012 to that index, pinned to one tag (a nightly moves), with torchvision on the same tag and no torchaudio (none is published for it). The three RDNA 1 rows move from the "not covered" name tables to the routed ones on the Windows copies; the backend's copy follows. Linux is unchanged: nothing has run that route on bare-metal Linux, and WSL2's GPU driver refuses RDNA 1 outright. Tests: the unslothai#8529 suites now exercise the "not covered" wording with Polaris (RX 580, gfx803), which still owns it everywhere; the routing guards keep RDNA 1 banned on Linux and assert the Windows route; the parity test accepts a multi-arch device as routable on the Windows copies only; a new file pins the package specs, the index, the name tables and the PowerShell mirrors.
…stall The multi-arch index publishes no torchaudio, so the one left by an earlier CPU or per-family pass is linked against a torch that is gone and throws a Windows "Entry Point Not Found" dialog when anything imports it. Seen on the first fresh install from this branch: torch 2.12.0+rocm10.2 next to torchaudio 2.11.0+rocm7.13. Remove it after the multi-arch pass; a torchaudio carrying the pinned tag, should AMD publish one, stays.
for more information, see https://pre-commit.ci
…ti-arch torch setup.ps1 and install.ps1 install the pair themselves and set the marker that makes the python repair return early, so the cleanup there never ran on a fresh install (seen: torchaudio 2.11.0+rocm7.13.0 still present after the multi-arch pass). Do it in the two PowerShell installers right after their trio lands, and in the python marker shortcut when the installed torch carries the multi-arch tag.
for more information, see https://pre-commit.ci
…ch venv The dependency pass re-resolves torchaudio 2.11.0 on every run: torch-stoi and descript-audiotools require it unconditionally and nothing exists for the pinned torch (AMD's index lists no torchaudio for the tag, PyPI stops at 2.11.0). The cleanups that run right after the trio install therefore lose to step 8. Run it once more at the end of the Windows flow, after every with-deps step.
for more information, see https://pre-commit.ci
Measured on the RX 5700 XT venv the installer built: torchaudio 2.11.0 next to torch 2.12.0+rocm10.2 imports, resamples, computes a mel spectrogram and loads torch-stoi, with no dialog. The dependency pass installs it (torch-stoi and descript-audiotools require it; PyPI stops at 2.11.0 and AMD's index has none), and taking it out again only lost audio features. The pinned trio still lists no torchaudio, which is what the index needs; the rest is left to the resolver.
…e nightly repo.amd.com/rocm/whl-multi-arch publishes the same per-device packaging as the nightly, on release tags: torch 2.11.0+rocm7.14.1 with the gfx1010/1011/1012 device packs, torchvision 0.26.0 and torchaudio 2.11.0 on the same tag. Measured on an RX 5700 XT: resolves in one go, fp16 matmul correct, Triton unchanged (buffer ops still need unslothai#11615), and the 3-step LoRA/QLoRA rows on Qwen3.5-0.8B and Qwen3-1.7B match the nightly to the fourth decimal. So the route pins that release instead of a nightly date: the index also serves 2.12.0, which sits on the <2.12.0 window the rest of the Windows install applies, so 2.11.0 is the newest release inside it. torchaudio goes back into the trio and the empty-audio-slot handling ($RocmNoAudio, the trio filter) goes away.
for more information, see https://pre-commit.ci
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
This was referenced Sep 24, 2026
Closed
…repair tests on the helper torchaudio is back in the multi-arch trio, so the empty-slot filter on install.ps1's three ROCm trio commands has nothing to filter; the plain form is what the pr5940 follow-up tests read. The two cuda_repair tests looked for the inline _WINDOWS_ROCM_TORCH_PKG_SPECS.get in _ensure_rocm_torch, which now calls _windows_rocm_torch_pkg_specs; they anchor on that call.
…ws it _ensure_rocm_torch binds a local named _bare_gfx further down, so the multi-arch message calling the module helper raised UnboundLocalError on the Windows repair path for a gfx1010 host with a CPU torch. Inline the bare-arch spelling there and run that site in a test.
for more information, see https://pre-commit.ci
This was referenced Sep 25, 2026
…xes from the gfx override, reinstall a per-family build on a now-RDNA 1 host - test_other_arches_keep_their_specs compares gfx1034 against _WINDOWS_ROCM_TORCH_PKG_SPECS; unslothai#11834 pinned the gfx103X family, so bare names no longer apply. - setup.ps1 and install.ps1 drop a ":xnack-" style suffix from UNSLOTH_ROCM_GFX_ARCH before routing, as the Python resolver already does. - A standalone studio update on a venv holding a per-family ROCm torch reinstalls from the multi-arch index when the card is RDNA 1 and its amd-torch-device pack is missing.
…spec test The gfx1034 update described in b3efb0c was not in that commit; the test still expected bare package names that main no longer returns.
for more information, see https://pre-commit.ci
danielhanchen
added a commit
to Datta0/unsloth-staging-3
that referenced
this pull request
Sep 29, 2026
danielhanchen
added a commit
to danielhanchen/unsloth-staging-2
that referenced
this pull request
Sep 29, 2026
danielhanchen
added a commit
to LeoBorcherding/unsloth
that referenced
this pull request
Sep 29, 2026
unslothai#11755 landed on main with a device-pack repair keyed on the RDNA 1 set. With every RDNA arch routed here it now checks both the torch and torchvision packs, follows _windows_routes_multiarch so a family-mirror host does not reinstall every update, and a migrated venv's orphaned family runtime no longer triggers the family check.
danielhanchen
added a commit
that referenced
this pull request
Sep 29, 2026
…o 9000 cards from AMD's multi-arch index (#11846) * Windows installers: route RDNA 1 (gfx1010/1011/1012) to AMD's multi-arch nightly index RDNA 1 has no family on repo.amd.com, so every Windows installer put an RX 5700 XT on CPU torch and said so (#8529). AMD's multi-arch nightly index carries per-card kernel packs for it: `torch[device-gfx1010]` resolves torch plus the gfx1010 pack. With that torch, #11615 and the zoo's #1356 / #1316, the card trains (#11614). install_python_stack.py, install.ps1 and setup.ps1 now route gfx1010 / gfx1011 / gfx1012 to that index, pinned to one tag (a nightly moves), with torchvision on the same tag and no torchaudio (none is published for it). The three RDNA 1 rows move from the "not covered" name tables to the routed ones on the Windows copies; the backend's copy follows. Linux is unchanged: nothing has run that route on bare-metal Linux, and WSL2's GPU driver refuses RDNA 1 outright. Tests: the #8529 suites now exercise the "not covered" wording with Polaris (RX 580, gfx803), which still owns it everywhere; the routing guards keep RDNA 1 banned on Linux and assert the Windows route; the parity test accepts a multi-arch device as routable on the Windows copies only; a new file pins the package specs, the index, the name tables and the PowerShell mirrors. * Expect the RX 5700 XT to resolve in the Windows name tables now that it routes * Drop a torchaudio built against another torch after the multi-arch install The multi-arch index publishes no torchaudio, so the one left by an earlier CPU or per-family pass is linked against a torch that is gone and throws a Windows "Entry Point Not Found" dialog when anything imports it. Seen on the first fresh install from this branch: torch 2.12.0+rocm10.2 next to torchaudio 2.11.0+rocm7.13. Remove it after the multi-arch pass; a torchaudio carrying the pinned tag, should AMD publish one, stays. * Pin that a lone RDNA 1 host takes the Vulkan llama.cpp route * [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci * Run the stale-torchaudio cleanup on every path that ends with the multi-arch torch setup.ps1 and install.ps1 install the pair themselves and set the marker that makes the python repair return early, so the cleanup there never ran on a fresh install (seen: torchaudio 2.11.0+rocm7.13.0 still present after the multi-arch pass). Do it in the two PowerShell installers right after their trio lands, and in the python marker shortcut when the installed torch carries the multi-arch tag. * [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci * Give the Windows final step the last word on torchaudio in a multi-arch venv The dependency pass re-resolves torchaudio 2.11.0 on every run: torch-stoi and descript-audiotools require it unconditionally and nothing exists for the pinned torch (AMD's index lists no torchaudio for the tag, PyPI stops at 2.11.0). The cleanups that run right after the trio install therefore lose to step 8. Run it once more at the end of the Windows flow, after every with-deps step. * [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci * Stop removing torchaudio: 2.11 works beside the multi-arch torch 2.12 Measured on the RX 5700 XT venv the installer built: torchaudio 2.11.0 next to torch 2.12.0+rocm10.2 imports, resamples, computes a mel spectrogram and loads torch-stoi, with no dialog. The dependency pass installs it (torch-stoi and descript-audiotools require it; PyPI stops at 2.11.0 and AMD's index has none), and taking it out again only lost audio features. The pinned trio still lists no torchaudio, which is what the index needs; the rest is left to the resolver. * RDNA 1 on Windows: install from AMD's stable multi-arch index, not the nightly repo.amd.com/rocm/whl-multi-arch publishes the same per-device packaging as the nightly, on release tags: torch 2.11.0+rocm7.14.1 with the gfx1010/1011/1012 device packs, torchvision 0.26.0 and torchaudio 2.11.0 on the same tag. Measured on an RX 5700 XT: resolves in one go, fp16 matmul correct, Triton unchanged (buffer ops still need #11615), and the 3-step LoRA/QLoRA rows on Qwen3.5-0.8B and Qwen3-1.7B match the nightly to the fourth decimal. So the route pins that release instead of a nightly date: the index also serves 2.12.0, which sits on the <2.12.0 window the rest of the Windows install applies, so 2.11.0 is the newest release inside it. torchaudio goes back into the trio and the empty-audio-slot handling ($RocmNoAudio, the trio filter) goes away. * [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci * Windows AMD trio: pass the three specs plainly again, and anchor the repair tests on the helper torchaudio is back in the multi-arch trio, so the empty-slot filter on install.ps1's three ROCm trio commands has nothing to filter; the plain form is what the pr5940 follow-up tests read. The two cuda_repair tests looked for the inline _WINDOWS_ROCM_TORCH_PKG_SPECS.get in _ensure_rocm_torch, which now calls _windows_rocm_torch_pkg_specs; they anchor on that call. * Windows repair site: do not call _bare_gfx() where the function shadows it _ensure_rocm_torch binds a local named _bare_gfx further down, so the multi-arch message calling the module helper raised UnboundLocalError on the Windows repair path for a gfx1010 host with a CPU torch. Inline the bare-arch spelling there and run that site in a test. * [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci * RDNA 1 route: count it as covered in the two gates outside the route, and move the wheel-less fixtures to Polaris The backend's repairability check and setup.ps1's pre-Intel "AMD gets GPU wheels" gate both read a list that still omitted gfx1010-1012, so a 5700 XT on Windows could not establish a torch mismatch and lost to an Intel Arc on a mixed host. The backend gains a Windows-only extension of the supported set (Linux still declines RDNA 1); setup.ps1's list gains the three arches. Tests that used the RX 5700 XT / gfx1010 as the card with no Windows wheels move to Polaris (RX 580 / gfx803); the Linux-only parity tests learn that RDNA 1 names are unsupported on the Linux copies and routed on the Windows copies. * [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci * Unsloth Studio (AMD/Windows): install every RDNA arch from AMD's stable multi-arch index repo.amd.com/rocm/whl-multi-arch has a per-device kernel pack for every RDNA arch at the release tag #11755 pins (2.11.0+rocm7.14.1, torchvision 0.26.0, torchaudio 2.11.0 on the same tag). The per-family Windows indexes stop one ROCm release earlier, an exact pin has nothing for the kept-release rule to keep (#11814), and per-device packs are smaller than family bundles. So the RDNA 1 route becomes the route for RDNA 1 through 4 (gfx1153 included, gfx1033 and CDNA stay on their family), in the python repair and both PowerShell installers. The family map stays: a host mirroring the family layout (UNSLOTH_ROCM_WINDOWS_MIRROR, no multi-arch mirror) keeps the family route for arches that have one, and the stale/mismatch classifiers still read families off the installed runtime. The trio is derived from the index that was chosen, so it can never name a build the index does not serve. Measured on an RX 6500 XT (gfx1034) and, via #11755, an RX 5700 XT (gfx1010). RDNA 3 / 3.5 / 4 are the same build and shape, unmeasured; draft until someone runs it. Part of #11815. * Bundle-coverage test: anchor the family-map regex on its definition line * [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci * Tests: expect main's per-arch torch floors on the family route * Trim comments added by the multi-arch route * Install torchvision's device pack on the multi-arch route Bare torchvision from repo.amd.com/rocm/whl-multi-arch carries no GPU kernels: torchvision.ops.nms raised hipErrorInvalidDeviceFunction on a gfx1151 (Radeon 8060S, Windows 11). torchvision[device-gfxNNNN] pulls amd-torchvision-device-gfxNNNN, which resolves for every routed arch. * Count gfx1153 as a Windows ROCm arch in the backend The installers route gfx1153 to the multi-arch index, but the backend's supported set stopped at gfx1152, so a gfx1153 host left on CPU torch never qualified for the mismatch repair. Add a parity test against _WINDOWS_MULTIARCH_GFX, and correct the _index_is_multiarch docstring: explicit unknown-family pins are installed verbatim and never reach it. * Repair a swapped card on a multi-arch ROCm install The multi-arch build names no rocm-sdk-libraries family, so the Windows repair's family comparison reads None and never reinstalls after a card swap, leaving torch with no kernels for the new GPU. Check the installed amd-torch-device / amd-torchvision-device packs for the routed arch instead. Legacy per-family installs are left to the family check. * Trim comments restating the multi-arch code * Keep a multi-arch mirror's query token intact Appending the index slash after the whole URL put it inside a ?token= query on an authenticated mirror. Split on ? / # first, as _index_url_join does for the family indexes; plain URLs are unchanged. * Recognise a query-token multi-arch mirror by its path _index_is_multiarch compared whole URLs, so https://m/whl-multi-arch?token=x never matched its own resolved form (.../whl-multi-arch/?token=x) and the repair installed the trio without device extras. Compare path parts only. --------- Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com> Co-authored-by: Daniel Han <23090290+danielhanchen@users.noreply.github.com>
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.
Part of #11614 (training on AMD RDNA1) and part of #8529 (the installer half): with this, an RX 5700 XT on Windows gets a working ROCm torch from Unsloth Studio / Unsloth Desktop instead of the CPU fallback, and with #11615 (merged) plus unslothai/unsloth-zoo#1356 and unslothai/unsloth-zoo#1316 it trains.
The problem in plain words
RDNA 1 cards (RX 5700 XT, 5600 XT, 5500 XT,
gfx1010/gfx1011/gfx1012) have no family on the index the Windows installers use, https://repo.amd.com/rocm/whl. So every installer detected the card, correctly said "no ROCm PyTorch wheels Unsloth installs" (#8577) and installed CPU torch.AMD's multi-arch index, https://repo.amd.com/rocm/whl-multi-arch/, carries per-card kernel packs for these cards, on release tags (the index serves torch 2.9.1 through 2.12.0 for them). The install shape differs from the per-family index:
torch[device-gfx1010]resolves torch plus anamd-torch-device-gfx1010pack, and the same spelling pulls the matchingrocm-sdk-devicepack. Everything else about the wheel is the same bundled-runtime ROCm torch the other families get.What this PR does
On Windows only,
gfx1010,gfx1011andgfx1012route to that index, in all three installers that install torch:studio/install_python_stack.py(studio update, repairs):_WINDOWS_MULTIARCH_GFX,_windows_rocm_index_url()returns the multi-arch base for them, and_windows_rocm_torch_pkg_specs()gives the pinned pair.install.ps1andstudio/setup.ps1(fresh installs):$multiArchGfxplus the same tag constants, a branch ahead of the per-family one, and the "has wheels" checks that drive the mixed-host picker count RDNA 1 as covered.Three deliberate choices:
Pinned to one release tag:
torch[device-gfxNNNN]==2.11.0+rocm7.14.1,torchvision==0.26.0+rocm7.14.1,torchaudio==2.11.0+rocm7.14.1. The index also serves2.12.0+rocm7.14.1, which sits exactly on thetorch<2.12.0window the rest of the Windows install applies, so 2.11.0 is the newest release inside that window and the pin has to stay exact (a>=would land on the ceiling). Bumping is one constant in each of the three files, and a test asserts the three agree and that the pin stays under 2.12.The whole trio comes from that index. torchaudio is published there on the same tag, so nothing is dropped and nothing is left for the dependency pass to backfill. (An earlier revision of this PR used AMD's nightly index,
nightly.repo.amd.com/rocm/whl-next, pinned to a dated 10.2 build with no torchaudio; the stable index turned out to carry the same device packs on release tags, and the same tests pass on it. The nightly is gone from this PR.)Not in the per-family map.
_GFX_TO_AMD_INDEX_ARCH/$archFamilyMapare one URL leaf per family on repo.amd.com; the multi-arch index has one URL for every device and selects the card through the extra. Keeping it separate keeps the parity tests that guard those maps meaningful, and keeps Linux out of it.The three RDNA 1 rows move from the "not covered" GPU name tables to the routed ones on the Windows copies (
install.ps1,setup.ps1,install_python_stack.py, and the backend's_GPU_NAME_GFX_TABLE, which decides whether a repair could help a card). The "not covered" wording stays for Polaris (RX 580,gfx803, #8458), which still has no wheels anywhere.Linux is unchanged.
install.shandsetup.shkeep RDNA 1 in the unsupported table and the Linux resolver still returns no index for it. Nothing has run this route on bare-metal Linux, and WSL2 cannot: its GPU driver refuses the address-space reservation ROCm needs on RDNA 1 (dxgkio_reserve_gpu_va: EOVERFLOW, details in #11614). The same index does have Linux wheels for these cards at the same tags, so the Linux half is a follow-up for whoever has the hardware.Smart App Control blocks the unsigned
hipInfo.exeon every AMD install and the unsigned torchcodec DLLs the updater adds; that is a separate issue, not made worse here, and does not stop training.Measured
Fresh per-branch install on this box with
HIP_VISIBLE_DEVICES=1, so the installers see a single RX 5700 XT the way a one-card RDNA 1 machine does (the RX 6500 XT stays masked). What the installer produced, read back from the venv:amd-torch-device-gfx1010pack,rocm-sdk-device-gfx1010)libbitsandbytes_rocm715.dllruns on gfx1010 under this torch)torch.cuda.get_device_properties(0)torch.cuda.get_arch_list()Training with that venv on the 5700 XT, unsloth 2026.9.11 (has #11615) plus the zoo branch of unslothai/unsloth-zoo#1356 with unslothai/unsloth-zoo#1316's checkpointing file, eager mode as Unsloth Studio runs on Windows ROCm (
TORCHDYNAMO_DISABLE=1), seq 1024, batch 2, seed 3407:adamw_torchadamw_8bitIdentical to ten decimals with the throwaway venv the stable index was first tried in, and within the 4th to 5th decimal of the same rows on the 10.2 nightly this PR used before (
0.0366742536 0.0366742536 0.0281488057and0.0209256057 0.0209256057 0.0192451496), which is the different ROCm, not a fault. The desktop-app run in unslothai/unsloth-zoo#1356 (30 steps of alpaca-cleaned through the Unsloth Studio UI, mean loss 1.41) was on the nightly torch installed by hand; the backend below boots on the stable one.The Unsloth Studio backend started from that venv (only the 5700 XT visible) comes up on port 8893 and logs:
What
setup.ps1prints for this card on the way there (the install ran in the supervisor's own window; the venv table above is the measurement):Two checks behind the choice of index shape, done in a clean venv:
uv pip install --index-url https://repo.amd.com/rocm/whl-multi-arch/ --extra-index-url https://pypi.org/simple "torch[device-gfx1010]==2.11.0+rocm7.14.1" "torchvision==0.26.0+rocm7.14.1" "torchaudio==2.11.0+rocm7.14.1"resolves 20 packages in one go (torch,amd-torch-device-gfx1010,rocm-sdk-device-gfx1010,rocm,rocm-sdk-*, torchvision, torchaudio, and the pure-python deps from PyPI); and https://repo.amd.com/rocm/whl/ lists exactly gfx103X-all, gfx110X-all, gfx110X-dgpu, gfx1150, gfx1151, gfx1152, gfx120X-all, gfx908, gfx90X-dcgpu, gfx90a, gfx94X-dcgpu and gfx950-dcgpu, no gfx101X, which is why this is a second index and not a table entry.The same torch inside Unsloth Desktop (my main install, swapped by hand to what this PR installs), relaunched with
HIP_VISIBLE_DEVICES=1so the app sees only the RX 5700 XT, which is what a single-card RDNA 1 machine looks like: the About page lists the card under ROCm 7.17.26374 with the 2026.9.11 package, the System page shows it as GPU 0, ROCm, and a second 30-step run there landed on the same numbers as the first two-card run (mean 1.4119, final 1.5441).The first 30-step run through that app on the 5700 XT is in unslothai/unsloth-zoo#1356 (screenshots there).
The multi-arch torch does not regress the card the stock installer serves either. Same app, same swapped stack, same job (Qwen3.5-0.8B, 16-bit LoRA, alpaca-cleaned, 30 steps, seed 3407) on the RX 6500 XT (gfx1034), the card whose family index this box would normally get: 30/30, mean train loss 1.4119, final 1.5442, grad norms 0.72 to 1.90, no NaN. That is the 5700 XT's curve to the fourth decimal (its final was 1.5441). Wall time was longer on the 4 GB card, 33 min against 4.5 min on the 8 GB one, which is memory, not the torch.
What the installer transcript shows on this two-card box, for the record:
install.ps1infers the arch from the first display adapter (RX 6500 XT, gfx1034) and installs the gfx103X family trio. Its name inference does not consultHIP_VISIBLE_DEVICES; that is existing behaviour on a mixed host and irrelevant to a one-card machine.setup.ps1honours the mask, infers gfx1010, printsgfx1010 is RDNA 1 -- AMD multi-arch index, pinned to 2.11.0+rocm7.14.1 (torch, torchvision, torchaudio)and installstorch[device-gfx1010]==2.11.0+rocm7.14.1 torchvision==0.26.0+rocm7.14.1 torchaudio==2.11.0+rocm7.14.1. That is the branch in this PR doing its job.unslothai/llama.cpp@b11139-mix-a6922cc) shipped a checksum asset listing no Windows archives at all, so the prebuilt path was skipped, and the source-build fallback died on a path-length error in the clone. On a one-card RDNA 1 machine the existing Installer: opt-in Vulkan llama.cpp backend (and fallback when no AMD card is HIP-supported) #7357 rule sends a Windows AMD host with no HIP-prebuilt arch to the Vulkan bundle (gfx1010 is below the HIP floor, and Vulkan is the right llama.cpp backend for it anyway); it declined here only because the mask was set, by design. A test below pins that a lone gfx1010 host takes the Vulkan route.Tests
New
tests/studio/install/test_rdna1_multiarch_windows_route_11614.py: the resolvers send every spelling of the three arches (gfx1010,GFX1010,gfx1010:xnack-) to the multi-arch index and nothing else there; the specs are pinned with the device extra to one release tag (not a nightly date), the pin stays under the Windows torch ceiling, and torchaudio rides the same tag; RDNA 2 and Polaris resolve as before; the Windows name tables resolve the RDNA 1 marketing names and the "not covered" tables no longer claim them;install.ps1andsetup.ps1carry the same three arches and the same tag as the python installer.test_unsupported_arch_routing_guards_8529.py: Polaris stays banned everywhere; RDNA 1 stays banned on Linux (theinstall.shcase table andget_torch_index_urlare still executed undersh), and a new class asserts the Windows route plus the mirror override.test_rdna1_unsupported_message_8529.pyand the.ps1twin: the wording tests now run with the RX 580; the RX 5700 XT is asserted to route through the WMI name path; the unsupported-table parity is split into the Linux copies (still name RDNA 1) and the Windows copies (must not). The mixed-adapter guard cases use Polaris as the uncovered card and RDNA 1 as a covered peer.test_rocm_arch_table_parity.py: an arch a Windows name table produces may be a multi-arch device with a route instead of a per-family entry; the Linux tables may not produce one.studio/backend/tests/test_install_resolve_prebuilt.py: a lone gfx1010 host takes the Installer: opt-in Vulkan llama.cpp backend (and fallback when no AMD card is HIP-supported) #7357 Vulkan llama.cpp route (no HIP prebuilt exists for it), and gfx1010 beside a HIP-capable card keeps the HIP bundle.On this box, run with the Unsloth Studio venv's python: the four files above 499 passed;
test_rdna1_multiarch_windows_route_11614.py33 passed;test_install_resolve_prebuilt.py -k "vulkan or rdna1"171 passed;tests/studio/test_rdna1_unsupported_message_8529.ps1andtests/studio/test_amd_name_arch_r9700.ps1all checks passed. Failing here exactly as on the parent commit (same tests, same parametrizations, run back to back on both worktrees), so not this change:tests/test_windows_amd_gpu_scan_fallback.py(PowerShell 5.1 runspace crash on this host),test_rocm_support.py::TestGfx1102Rocm64Floorandstudio/backend/tests/test_rocm_torch_explicit_request.py(Git Bashawk -v/ heredoc quirks),test_amd_fastpath_probe.py::test_the_preflight_and_the_repair_agreeplus::test_the_cli_answers_end_to_end_over_a_stub_torch(read this two-GPU host's real WMI),test_installed_runtime_health_matrix.py(both tests),test_uv_boolish_parity.py(five tests) andtest_install_llama_prebuilt_logic.py::test_setup_ps1_routing_matches_setup_sh(a pwsh helper/permissions error in the harness). Listed so nobody re-bisects them onto this change.Trying it on a one-card RDNA 1 box
Fresh install from this branch, no environment tricks needed. Expected in the transcript:
gfx1010 is RDNA 1 -- AMD multi-arch index, pinned to 2.11.0+rocm7.14.1 (torch, torchvision, torchaudio), then a torch 2.11.0+rocm7.14.1 that lists gfx1010 intorch.cuda.get_arch_list(); llama.cpp lands on the Vulkan bundle. Training a gated-delta model (Qwen3.5) additionally needs unslothai/unsloth-zoo#1356 and unslothai/unsloth-zoo#1316 in the venv until they merge; Qwen3 / Llama only need unslothai/unsloth-zoo#1316.Review history
Earlier discussion comments were folded into this description. Review findings and their resolution:
_ROCM_SUPPORTED_GFX_WINDOWS_ONLYadds gfx1010 to gfx1012 on Windows only.$multiArchGfx.UNSLOTH_ROCM_GFX_ARCH=gfx1010:xnack-fell through to CPU torch in both PowerShell installers. Fixed: the feature suffix is dropped before routing.studio updatekept a per-family ROCm torch after the host became RDNA 1. Fixed: reinstall from the multi-arch index whenamd-torch-device-<gfx>is missing.uv pip compile --default-index https://repo.amd.com/rocm/whl-multi-arch/resolves the pinned trio for gfx1010, gfx1011 and gfx1012 on Python 3.11, 3.12 and 3.13 (win_amd64) with no other index.