Recognize Radeon 8065S (Gorgon Halo / Ryzen AI Max 400) as gfx1151 - #7290
Conversation
![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 support for the Radeon 8065S iGPU (Gorgon Halo) by mapping it to the gfx1151 architecture (RDNA 3.5) across various installation and setup scripts, including install.ps1, install.sh, install_python_stack.py, setup.ps1, and setup.sh. This includes updating GPU name tables and regular expressions to correctly identify the new hardware. 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.
|
@codex review |
![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: 2c7673e1f6
ℹ️ 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".
| # RDNA 3.5 (Strix Halo + Gorgon Halo: Radeon 8065S/8060S/8050S/8040S iGPU, Ryzen AI Max / Max+) | ||
| (r"8065S|8060S|8050S|8040S|Strix Halo|Ryzen AI Max|AI Max", "gfx1151"), |
There was a problem hiding this comment.
On a driver-only host this new fallback selects the gfx1151 AMD index, whose installer paths constrain torch to the bundled ROCm 7.13 runtime. The commit notes that Gorgon Halo device support was only added in ROCm 7.14 and that an HSA override may be needed; without updating the runtime/index or setting that override, these newly recognized 8065S systems install ROCm torch that cannot enumerate the GPU, rather than the previous CPU fallback. Gate this mapping on a compatible runtime or add the required newer runtime/override handling.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
8065S and 8060S resolve to the identical gfx1151 arch and the identical wheel: the name table returns only an arch string with no per-name runtime floor, and both flow through the same repo.amd.com/rocm/whl/gfx1151/ path that already ships for Strix Halo 8060S. So gating this mapping on a compatible runtime cannot target 8065S without also gating 8060S, which is the currently working, already shipped config.
The wheel is not pinned to 7.13. gfx1151 uses the floor torch>=2.11.0,<2.12.0 against the per-arch index, which resolves to torch-2.11.0+rocm7.13.0 today only because that is the sole 2.11 build on the index. ROCm 7.14 is now a production release adding Gorgon Halo enablement for the Ryzen AI Max PRO 495/490/485; when AMD publishes a 2.11.x+rocm7.14 wheel on that same per-arch channel, as they did across 7.9 through 7.13, pip selects it with no change here.
On worse-than-before: a ROCm build on a device the runtime cannot enumerate still runs on CPU with torch.cuda.is_available() False, which is no worse than the prior CPU fallback. The only genuinely worse mode, is_available() True with a GPU memory access fault, is a pre-existing gfx1151 runtime maturity issue that already affects the shipped 8060S on these same wheels (ROCm/legacy-rocm-build#5824, pytorch/pytorch#173367); it is not introduced by recognizing an additional marketing name. The newer-runtime / HSA override caveat is already noted in the PR description and is an AMD runtime detail independent of installer name inference. Keeping the mapping.
| # RDNA 3.5 (Strix Halo + Gorgon Halo: Radeon 8065S/8060S/8050S/8040S iGPU, Ryzen AI Max / Max+) | ||
| (r"8065S|8060S|8050S|8040S|Strix Halo|Ryzen AI Max|AI Max", "gfx1151"), |
There was a problem hiding this comment.
When a Radeon wheel omits both is_integrated and the GCN-arch fields—the exact name-fallback case supported by _rocm_classify_unified_memory—the new 8065S host is installed and used as gfx1151 but is classified as discrete because worker.py recognizes only 8060s and 8050s. The OOM guard then applies the discrete 0.90 cap instead of the APU policy (0.80 on Linux or 1.0 on Windows), risking unnecessary allocation failures on Windows and reduced OS headroom on Linux. Add 8065s to that fallback and its parameterized regression test.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in f3c9bab: added 8065s to the unified-memory name fallback in _rocm_classify_unified_memory (and its parameterized regression test). This path is the name-only last resort, so a Radeon 8065S reported without gcnArchName or is_integrated now gets the APU cap (0.80 on Linux, 1.0 on Windows) instead of the discrete 0.90, matching how 8060S/8050S are handled. When the arch is readable it already classified as gfx1151 unified via the gcnArchName branch.
|
@codex review |
1 similar comment
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 397a8ec24c
ℹ️ 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".
| # RDNA 3.5 (Strix Halo: Radeon 8060S/8050S/8040S iGPU, Ryzen AI Max+) | ||
| (r"8060S|8050S|8040S|Strix Halo|Ryzen AI Max|AI Max", "gfx1151"), | ||
| # RDNA 3.5 (Strix Halo + Gorgon Halo: Radeon 8065S/8060S/8050S/8040S iGPU, Ryzen AI Max / Max+) | ||
| (r"8065S|8060S|8050S|8040S|Strix Halo|Ryzen AI Max|AI Max", "gfx1151"), |
There was a problem hiding this comment.
On Windows hosts that reach this marketing-name fallback (no directly reported HIP/amd-smi arch), this mapping selects AMD's gfx1151 wheel index, which the existing installer pins to torch 2.11.0+rocm7.13.0. The commit itself notes that Gorgon Halo's PCI device support was added only in ROCm 7.14, so this newly enabled path installs a runtime that cannot enumerate the 8065S unless the user separately supplies a newer runtime or HSA override. Gate this mapping until a 7.14-compatible wheel/runtime is selected, or update the selected runtime together with the detection.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Same concern as the thread above, and the blocking objection still stands. 8065S and 8060S resolve to the identical gfx1151 arch and the identical wheel through the same code path, so gating 8065S to a 7.14 runtime also gates the already shipped Strix Halo 8060S, which works on 7.13 today. That trades a real regression of a shipped config for a theoretical concern on the same wheel.
The gfx1151 selection is a torch>=2.11.0,<2.12.0 floor, not a 7.13 pin. It resolves to 2.11.0+rocm7.13.0 only because that is the sole 2.11 build on the per-arch index right now, and pip will auto-select a 2.11.x+rocm7.14 wheel from that same channel once AMD publishes one (ROCm 7.14 is GA with Gorgon Halo enablement). A device the runtime cannot enumerate falls back to CPU with torch.cuda.is_available() False, no worse than the prior CPU fallback. Holding the mapping.
|
@codex review |
1 similar comment
|
@codex review |
|
Codex Review: Didn't find any major issues. Keep it up! 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". |
Reconcile PR #7256 (Windows torch 2.11 + release preservation, installer comment reduction, torch 2.11 default line) with 77 commits of main install rewrites. Base is main's newer install semantics; this branch's still-novel contributions are layered on top. Key decisions: - install.ps1: kept main's rollback lifecycle (try/finally Restore-StudioVenvRollback, #7342) and the installed-version report (#7265); layered this branch's torch-2.11 allowance (torch<2.12.0 on the Windows CUDA fresh-install, CPU fallback and flavor repairs), the release-preservation port (Get-InstalledTorchVersionRaw / kept-release installs / UNSLOTH_KEPT_TORCH handoff / torch-overrides freeze) and the Exit-InstallFailure UNSLOTH_KEPT_TORCH clear. - install.sh: took main's newer AMD/Strix routing (per-arch index reroute #7264/#7300, runtime-less gfx inference #7305, KFD detection fix #7314, Radeon 8065S regex #7290, signal-restore trap #7342) and the #7365 unsloth pin bump; kept this branch's _TORCH_CEILING/_TORCHVISION_CEILING/_TORCHAUDIO_CEILING refactor widening the default ceiling to torch<2.12.0. - studio/install_python_stack.py: deferred all five code conflicts to main's Strix inference logic (result is AST-identical to main; only comment reductions remain). - studio/setup.ps1: took main's comment covering the whisper.cpp dictation markers (#7095); the UNSLOTH_KEPT_TORCH consumption handoff auto-merged intact. Dropped as superseded by main: this branch's stale unsloth>=2026.7.4 pins (main #7365), the older rocm7.1->rocm7.2 Strix reroute (main #7264/#7300), the narrow Radeon 80[0-9]0S regex (main #7290), and the pre-inference has_hip_torch gate (main's rocm_torch_ready gate, Codex P1 #7305). The two review-item fixes (grep -E in test_torch_constraint.sh, UNSLOTH_KEPT_TORCH clear in Exit-InstallFailure) survive.
1 participant
Summary
AMD's Ryzen AI Max 400 series (codename Gorgon Halo: Ryzen AI Max+ PRO 495 / PRO 490 / PRO 485) is a Strix Halo refresh. The iGPU is still RDNA 3.5 with 40 (or 32) compute units and ROCm reports it as
gfx1151, same as Strix Halo. AMD rebrands it as Radeon 8065S (40 CU flagship) and Radeon 8050S (32 CU).gfx1151is already fully supported (torch fromrepo.amd.com/rocm/whl/gfx1151/, thegfx1151llama.cpp prebuilt for Windows and Linux, thetorch>=2.11_grouped_mmfloor). The gap is only in GPU-name inference: when no HIP SDK / amd-smi is present and the arch is inferred from the marketing name, the tables listed8060S/8050S/8040Sbut not the new flagship name8065S, so a driver-only Windows host with a Radeon 8065S fell back to CPU torch. The 32 CU parts reuse8050S, which already matched.Fix
Add
8065Sto the five GPU-name -> gfx1151 tables and widen the two ROCm-on-WSL detection regexes fromRadeon 80[0-9]0StoRadeon 80[0-9][05]Sso both8060Sand8065Smatch:install.ps1$nameArchTablestudio/setup.ps1$nameArchTablestudio/install_python_stack.py_WIN_GPU_NAME_ARCH_TABLEinstall.shGPU-namecase+ the two_maybe_*_rocm_wsldetection grepsstudio/setup.shGPU-namecaseAdditive keys only. The arch (
gfx1151) and every downstream path are unchanged; parts that report the arch directly (always on Linux via rocminfo, on Windows with the HIP SDK, or viaUNSLOTH_ROCM_GFX_ARCH=gfx1151) already worked. This only fixes the name-inference fallback.Verified
Radeon 8065S->gfx1151in all five files (Python_WIN_GPU_NAME_ARCH_TABLE, both PowerShell$nameArchTablemaps, both bashcaseblocks), with no regressions:8060S/8050Sstillgfx1151,RX 6800stillgfx1030,RX 9070 XTstillgfx1201.Radeon 80[0-9][05]Smatches8065Sand8060S, andRyzen AI Max+ PRO 495still matches via the CPU-name branch.python -m astclean,bash -nclean.tests/sh/test_strixhalo_wsl_reroute.sh: 53 passed, 0 failed.Note
ROCm added Gorgon Halo runtime support in 7.14; our wheels are
+rocm7.13.0. The compute target and kernels are unchanged (gfx1151), but the new part's PCI device ID may need a newer ROCm runtime or an HSA override at runtime. That is an AMD runtime detail, independent of wheel/prebuilt selection.