MagicBeanDev/Longshot
MagicBeanDev/Longshot
Watch
25
31
Fork
You've already forked Longshot
 43
Code Issues 63 Pull requests 127 Projects Releases 8 Packages Wiki Activity Actions 314

WIP: fix(vk): task + mesh compute fallback by default for Navi 23 on Windows, one rule for the IDs #219

Draft
TrashPanda wants to merge 3 commits from TrashPanda/Longshot:fix/navi23-24-mesh-fallback into main
pull from: TrashPanda/Longshot:fix/navi23-24-mesh-fallback
merge into: MagicBeanDev:main
Conversation 3 Commits 3 Files changed 5 +120 -26
TrashPanda commented 2026-11-13 15:23:44 +00:00
Contributor

Why

On Windows, AMD's RX 6600 / 6600 XT / 6650 XT (Navi 23) still draw task + mesh work through the driver's own mesh shaders, the path that loses the device on Navi 21 and 22 (https://github.com/NotRexed/Hookshot/issues/996). One RX 6600 report (Mako) lost the device on the session's first task + mesh draws, so this puts Navi 23 on the compute fallback, as Navi 21 and 22 already are. The evidence is mixed, so this stays WIP until a Windows RX 6600 run decides: another RX 6600 on the same driver played 15-20 minutes on the native path (#130). See "Two RX 6600 reports" below.

Ported from Mako, by sharkiix, github.com/Shakoquo/Mako@c4fd465a55

What changed

  • vk: the device list moves out of create_device() in gpu/vk/vk_main.cpp into mesh_rule::task_mesh_fallback_default(vendor, device) in gpu/vk/mesh_mode.h (nothing of Vulkan, so a test can compile it). vk_main.cpp still asks only under #ifdef _WIN32, and RX_VK_TASK_MESH_FALLBACK and RX_VK_MESH_SHADERS=native still decide over it, unchanged.
  • vk: one rule for which IDs go in, written in mesh_mode.h's comment: an included chip brings every ID that the PCI ID database or libdrm's amdgpu.ids name a card for, consumer, mobile and Pro alike (they share the chip and the driver's mesh path). Not its USB or audio functions, nor IDs neither list names a card for. Untested IDs go in with their chip, as https://github.com/NotRexed/Hookshot/pull/2215 did for the RX 6900 XT XTXH and RX 6950 XT.
    • Checking Navi 21 against it: its list had the consumer IDs only (0x73bf, 0x73af, 0x73a5). To keep one rule, Navi 21's Pro IDs come in too (ea448fe7). That commit stands alone and can be dropped if you would rather keep Navi 21 as it was; the rule in the comment would then need to say "consumer and mobile".
    • Navi 22 and Navi 23 already had all their named IDs.
  • vk: Navi 24 is held out entirely (the RX 6300, 6400, 6500 XT, and the Pro W6300 to W6500M): no report, and 4 GB cards on PCIe x4, where the fallback's buffers cost the most (below). mesh_mode.h and docs/development.md say it is not on by default and that RX_VK_TASK_MESH_FALLBACK=1 tries it.
ID Chip Models (pci-ids / amdgpu.ids)
0x73bf Navi 21 RX 6800, 6800 XT, 6900 XT already in
0x73af Navi 21 RX 6900 XT (XTXH) already in
0x73a5 Navi 21 RX 6950 XT already in
0x73a1 Navi 21 Radeon Pro V620 new (the rule)
0x73a2 Navi 21 Radeon Pro W6900X new (the rule)
0x73a3 Navi 21 Radeon Pro W6800 new (the rule)
0x73ab Navi 21 Radeon Pro W6800X, W6800X Duo new (the rule)
0x73ae Navi 21 Radeon Pro V620 MxGPU new (the rule)
0x73df Navi 22 RX 6700, 6700 XT, 6750 XT, 6750 GRE 12GB, 6700M/6800M/6850M XT already in
0x73e0 Navi 23 RX 6600M (pci-ids: "Navi 23", no model) new
0x73e1 Navi 23 Radeon Pro W6600M new
0x73e3 Navi 23 Radeon Pro W6600 new
0x73ef Navi 23 RX 6650 XT, 6650M, 6650M XT, 6700S, 6800S new
0x73ff Navi 23 RX 6600, 6600 XT, 6600 LE, 6600M, 6600S; amdgpu.ids also lists an RX 6750 GRE 10GB revision here new

Left out by the rule: Navi 21's 0x73a4, Navi 22's 0x73c4 and Navi 23's 0x73e4 (USB controllers); Navi 22's 0x73c3 (no model in either list) and 0x73ce (its SR-IOV function, no model); 0x73da is in neither list. Left out as Navi 24 (held): 0x743f, 0x7421, 0x7422, 0x7423, 0x7424.

  • tests: tests/test_task_mesh_fallback_devices.py compiles mesh_mode.h and checks that every listed ID is in the default for AMD only (not for NVIDIA or Intel with the same ID), and that RDNA 1, RDNA 3, the USB and unnamed IDs and all of Navi 24 stay out. It still reads vk_main.cpp to check that the default is Windows-only and that RX_VK_TASK_MESH_FALLBACK is read after it. It fails on main (no task_mesh_fallback_default), and fails with 0x743f put back.
  • docs: the RX_VK_TASK_MESH_FALLBACK row in docs/development.md names the chips, the rule and Navi 24's opt-in. The README's AMD row now claims only what reports show: the driver lost the GPU on an RX 6700 XT, an RX 6800 XT and, in one report in Mako, an RX 6600; another RX 6600 played 15-20 minutes on the native path (issue 130); the RX 6400 and 6500 XT keep their own mesh shaders.

Two RX 6600 reports

Mako's report (sharkiix) Longshot issue 130
Card, driver RX 6600, Vulkan driver 0x800161 RX 6600 8 GB, 26.10.1 (Vulkan driver 0x800161)
Build Mako 3.5 (merged Hookshot of 2026-11-11 plus Mako's own changes) Hookshot v2.2.0-rc.1 (source 006e7dfe)
Path native task + mesh native task + mesh (Navi 23 was not in that build's list)
What happened device lost on the session's first task + mesh draws: OptimizeChangeBanc DrawMeshTasks 1..3, then a 5 s GPU wait 15-20 minutes (48,360 presents) through Market, Ganon's Castle, Kokiri Forest, the Lost Woods and Gerudo Valley, then device lost about 6 s after a teleport into Death Mountain Crater
VRAM not reported at the driver's limit all session; last status 6125 MB used of 6317 MB allowed, textures 1849 MB against a 1260 MB budget
Log none published: the commit message is all there is quoted in the issue

How they fit together, as far as the evidence goes:

  • Issue 130 shows the native path can run on Navi 23 for a long time. Kokiri Forest and the Lost Woods are full of task + mesh foliage, and it drew them for minutes. So "lost on the first task + mesh draws" is not a rule for the chip on this driver.
  • Both losses came at an area load. OptimizeChangeBanc is the game's scene-change thread. So Mako's loss happened where VRAM and uploads peak too, the same moment as issue 130's. AMD's Windows driver gives no fault info, and "DrawMeshTasks 1..3, then a 5 s GPU wait" is the last work recorded before the timeout, not the work that faulted. Without the log there is no telling a mesh-path timeout from a paging timeout like issue 130's.
  • Mako's tree differed from the build in issue 130. At the merge it carried about 2,000 lines of its own changes in gpu/vk: AMD FSR Redstone frame generation, vk_draw.cpp +290 lines, a perf monitor, the recompiler's value probe, and a second copy of the storage-buffer rule for graphics stages (task and mesh included). Mako 3.5 also turned VRAM compaction on by default. 2d5a9d65 (small read-only storage buffers copied into the recording's stream while their chunk is imported) landed two minutes before the fallback commit, and both shipped in 3.5.1. Whether the reporter's build had it is unknown. None of these is known to cause a first-draw loss, but none is ruled out either, and Longshot main has only some of them.
  • Settings: none are known for Mako's report; issue 130 ran at 2048x1152 with nothing else changed that the log shows.

What the fallback costs in VRAM

From fallback_buffers_of in gpu/vk/vk_draw.cpp and the constants in emit_spirv.h:

  • Records: (MESH_FALLBACK_HEADER_WORDS + MESH_FALLBACK_RECORD_WORDS) * 4 = (8 + 16 Mi words) × 4 B = 64 MB per buffer pair. It is the same size for every program.
  • Payload (task programs only): 65535 * 4 B (a 256 KB map) + ceil(65535 / task threads) * payload_words * 4 B. payload_words is the program's lines × 32 (at most 511 lines), so 128 B to 64 KB per task workgroup. At 32 task threads that is 256 KB + 2048 × (128 B to 64 KB), from about 0.5 MB up to about 128 MB. The source's own note puts it at about 6.5 MB at 800 words.
  • How many: one set of pairs per recording thread. By default there is one recording thread, the replay thread (RX_VK_PARALLEL is off). With RX_VK_PARALLEL=n there are n, up to 8, each with its own set.
  • Growth: a task program whose payload fits no existing pair makes a new pair: another 64 MB of records plus the larger payload. Grown pairs stay for the session, since a command buffer recorded earlier may still read them. So it is about 64 MB plus the payload for the first pair, and another 64 MB or more each time a larger payload first appears. How many times that happens in this game is not measured, and no log line counts it.
  • Against issue 130: at its last status the headroom was 192 MB (6125 of 6317 MB), and textures were 590 MB over their budget. One pair of about 70 MB is about 1% of that allowance. Three pairs (about 200 MB) would be all of the headroom that session had. The native path allocates none of this. On an 8 GB card at its limit, the fallback can make issue 130's failure more likely, and on 4 GB Navi 24 it is a bigger share still. The test run below watches for this.

On the default: the evidence does not show yet that Navi 23 needs it. Issue 130 points to VRAM, not the mesh path. Mako's report has no log, and it came from a different tree. My proposal: this PR stays WIP until a Windows RX 6600-class run (T-V2MY) compares main and this PR with the vk: VRAM: status line watched.

  • If main loses the device on the native path where this PR doesn't, and VRAM stays under the allowance, Navi 23 goes in.
  • If main runs clean, or the PR's VRAM gets near the allowance, Navi 23 stays opt-in like Navi 24, and this PR keeps only the move to mesh_mode.h, the ID rule and the docs.

Flags and settings

Flag What it does Default now Recommendation Helps on Doesn't help on Untested on
RX_VK_TASK_MESH_FALLBACK=0/1 (existing) Task + mesh draws through the compute fallback (1) or the driver's mesh shaders (0) On for AMD Navi 21, 22 and 23 on Windows (was Navi 21 and 22 consumer IDs only); Navi 24 off Navi 23 on only if the Windows RX 6600 run shows the native path losing the device and the fallback staying within VRAM; Navi 24 opt-in (=1) Windows AMD RDNA 2 where the native path times out (Navi 21 and 22 reported) Linux (RADV already uses the compute path), RDNA 3/4, NVIDIA, Intel: unchanged Every Navi 23 card, Navi 21's Pro IDs; =0 turns it off for a run

Measurements

None possible: this PC has no RDNA 2 card (RTX 4070 Ti, driver 595.99.02, Linux), and the change only applies on Windows with AMD. The VRAM figures above are worked out from the source, not measured.

main: fbd42024 (2026-11-13)
this PR: fix/navi23-24-mesh-fallback @ ea448fe7
Hardware: none with the affected GPUs
Scene: n/a
Method: n/a. The motivating report is Mako's (by sharkiix): an RX 6600 on Windows, AMD Vulkan driver 0x800161, lost the device on the session's first task + mesh draws (OptimizeChangeBanc DrawMeshTasks 1..3, then a 5 s GPU wait). The counter-report is issue 130 (quoted above).
How to reproduce: on an RX 6600 / 6600 XT / 6650 XT on Windows, the same save and settings on main and on this PR, from a fresh start into Kokiri Forest, then the Lost Woods, Hyrule Field, Castle Town and Death Mountain Crater, 15-20 minutes each. The log's vk: task + mesh programs use the compute fallback line says the fallback is on. Note every vk: VRAM: N MB used of M MB allowed line and the fps.

main @ fbd42024 this PR @ ea448fe7
Device lost, RX 6600 (Mako's report) on the first task + mesh draws not measured
Device lost, RX 6600 (issue 130, Hookshot v2.2.0-rc.1, same native path as main) after 15-20 min, at the VRAM limit not measured
VRAM, fps not measured not measured 
(none from this PC; Mako's report: device lost after OptimizeChangeBanc DrawMeshTasks 1..3, then a 5 s GPU wait, driver 0x800161;
issue 130: vk: VRAM: 6125 MB used of 6317 MB allowed (1061 MB of it free in the blocks); textures 1849 MB (budget 1260 MB),
then vk: submit 339379 failed (-4) / VK_ERROR_DEVICE_LOST)

Testing

Tested: game-free checks on Linux (RTX 4070 Ti, clang). tests/test_task_mesh_fallback_devices.py passes here. It fails on main, and fails with 0x743f put back in the list. tests/test_mesh_mode_switch.py passes. python3 -I -B tests/run_all.py --jobs 4 (with LONGSHOT_VULKAN_HEADERS set) on ea448fe7: 498 passed, 1 failed, 30 skipped. The one failure, tests/test_lift_cache.py (import lift, split_hot fails: no numpy here), also fails on main. vk_main.cpp was not compiled here: it needs windows.h, and there is no mingw toolchain on this PC. Its change is one call into mesh_mode.h, which the test compiles with -Wall -Wextra -Werror.

Not tested: not run in the game: no RDNA 2 card or Windows AMD system here. Not tested: whether the fallback stops a device lost on Navi 23, how much VRAM it takes in play, what it costs in frame rate there, and anything on Navi 21's Pro IDs.

Needs other testers:

  • RX 6600 / 6600 XT / 6650 XT on Windows (8 GB): main, then this PR, then main again, same save and settings, 15-20 min from Kokiri Forest to Death Mountain Crater. Watch the vk: VRAM: lines and note any device lost, and compare fps with main. Expecting no device lost on the PR, VRAM under the allowance, fps within a few % of main. A clean run on main matters too: it says whether the default is needed (T-V2MY).

Screenshots

Nothing on screen.

Risk and rollback

Navi 23 (and Navi 21's Pro IDs) on Windows now take the compute fallback, which can be slower, and which holds at least 64 MB more VRAM per recording thread, more as payloads grow. On an 8 GB card at the driver's limit, that can bring on issue 130's device lost sooner. RX_VK_TASK_MESH_FALLBACK=0 or RX_VK_MESH_SHADERS=native restores the native path for a run. Reverting the commits restores the old list. The pipeline cache's stamp already holds the mesh path, so the first start on an affected card translates the programs again.

Reviewer notes

  • The ID rule's Navi 21 part (ea448fe7) is a separate commit so it can go on its own if you'd rather not widen Navi 21 here.
  • A log line when the fallback makes a buffer pair (its size, the thread) would make the VRAM cost exact in a test run. Not added, as the review asked for nothing in the code beyond the ID rule. Say if you want it here.

Issues

https://github.com/NotRexed/Hookshot/issues/996; #130 (the counter-report and the VRAM risk).

Checklist

For everyone

  • One topic.
  • The title is a Conventional Commit (type(scope): description).
  • Rebased on current main.
  • python -I -B tests/run_all.py run and passing (any failure that also fails on main is named above).
  • Tested in the game, or what wasn't is named under Testing. (not run in the game; no RDNA 2 card here: see Testing)
  • Testing filled in: what was tested, what wasn't, and what needs other testers (with test requests).
  • Measured: main and this PR at named commits, on the same PC, scene and settings, at least 2 interleaved runs each, the median reported. (no affected hardware here; T-V2MY asks for it)
  • No game files, dumps, build output or generated files.
  • third_party/ untouched (a new folder with a PROVENANCE.md instead).
  • The license is OK: GPL-3.0-or-later, nothing incompatible and nothing decompiled.

If applicable

  • AI assistance recorded with Assisted-by: / Co-Authored-By: trailers.
  • Flags noted, and the switch reference updated (docs/development.md, the README).
  • A game-free test added for the fix, failing on main and passing here.
  • A check under tests/ that reads changed source updated in this PR, not weakened.
  • Docs updated.
  • Host code builds on both Windows (llvm-mingw) and Linux, with UTF-8 paths. (Linux only: no llvm-mingw here. mesh_mode.h is portable C++ the test compiles; vk_main.cpp's change is one call into it)
## Why On Windows, AMD's RX 6600 / 6600 XT / 6650 XT (Navi 23) still draw task + mesh work through the driver's own mesh shaders, the path that loses the device on Navi 21 and 22 (https://github.com/NotRexed/Hookshot/issues/996). One RX 6600 report (Mako) lost the device on the session's first task + mesh draws, so this puts Navi 23 on the compute fallback, as Navi 21 and 22 already are. **The evidence is mixed, so this stays WIP until a Windows RX 6600 run decides:** another RX 6600 on the same driver played 15-20 minutes on the native path (https://git.magicbean.dev/MagicBeanDev/Longshot/issues/130). See "Two RX 6600 reports" below. Ported from Mako, by sharkiix, https://github.com/Shakoquo/Mako/commit/c4fd465a55b7578f7ec7070dd3880144c35aad4e ## What changed - vk: the device list moves out of `create_device()` in `gpu/vk/vk_main.cpp` into `mesh_rule::task_mesh_fallback_default(vendor, device)` in `gpu/vk/mesh_mode.h` (nothing of Vulkan, so a test can compile it). `vk_main.cpp` still asks only under `#ifdef _WIN32`, and `RX_VK_TASK_MESH_FALLBACK` and `RX_VK_MESH_SHADERS=native` still decide over it, unchanged. - vk: **one rule for which IDs go in**, written in `mesh_mode.h`'s comment: an included chip brings every ID that the [PCI ID database](https://pci-ids.ucw.cz) or libdrm's [`amdgpu.ids`](https://gitlab.freedesktop.org/mesa/drm/-/raw/main/data/amdgpu.ids) name a card for, consumer, mobile and Pro alike (they share the chip and the driver's mesh path). Not its USB or audio functions, nor IDs neither list names a card for. Untested IDs go in with their chip, as https://github.com/NotRexed/Hookshot/pull/2215 did for the RX 6900 XT XTXH and RX 6950 XT. - Checking Navi 21 against it: its list had the consumer IDs only (0x73bf, 0x73af, 0x73a5). To keep one rule, Navi 21's Pro IDs come in too (ea448fe7). That commit stands alone and can be dropped if you would rather keep Navi 21 as it was; the rule in the comment would then need to say "consumer and mobile". - Navi 22 and Navi 23 already had all their named IDs. - vk: **Navi 24 is held out entirely** (the RX 6300, 6400, 6500 XT, and the Pro W6300 to W6500M): no report, and 4 GB cards on PCIe x4, where the fallback's buffers cost the most (below). `mesh_mode.h` and `docs/development.md` say it is not on by default and that `RX_VK_TASK_MESH_FALLBACK=1` tries it. | ID | Chip | Models (pci-ids / amdgpu.ids) | | |---|---|---|---| | 0x73bf | Navi 21 | RX 6800, 6800 XT, 6900 XT | already in | | 0x73af | Navi 21 | RX 6900 XT (XTXH) | already in | | 0x73a5 | Navi 21 | RX 6950 XT | already in | | 0x73a1 | Navi 21 | Radeon Pro V620 | **new** (the rule) | | 0x73a2 | Navi 21 | Radeon Pro W6900X | **new** (the rule) | | 0x73a3 | Navi 21 | Radeon Pro W6800 | **new** (the rule) | | 0x73ab | Navi 21 | Radeon Pro W6800X, W6800X Duo | **new** (the rule) | | 0x73ae | Navi 21 | Radeon Pro V620 MxGPU | **new** (the rule) | | 0x73df | Navi 22 | RX 6700, 6700 XT, 6750 XT, 6750 GRE 12GB, 6700M/6800M/6850M XT | already in | | 0x73e0 | Navi 23 | RX 6600M (pci-ids: "Navi 23", no model) | **new** | | 0x73e1 | Navi 23 | Radeon Pro W6600M | **new** | | 0x73e3 | Navi 23 | Radeon Pro W6600 | **new** | | 0x73ef | Navi 23 | RX 6650 XT, 6650M, 6650M XT, 6700S, 6800S | **new** | | 0x73ff | Navi 23 | RX 6600, 6600 XT, 6600 LE, 6600M, 6600S; amdgpu.ids also lists an RX 6750 GRE 10GB revision here | **new** | Left out by the rule: Navi 21's 0x73a4, Navi 22's 0x73c4 and Navi 23's 0x73e4 (USB controllers); Navi 22's 0x73c3 (no model in either list) and 0x73ce (its SR-IOV function, no model); 0x73da is in neither list. Left out as Navi 24 (held): 0x743f, 0x7421, 0x7422, 0x7423, 0x7424. - tests: `tests/test_task_mesh_fallback_devices.py` compiles `mesh_mode.h` and checks that every listed ID is in the default for AMD only (not for NVIDIA or Intel with the same ID), and that RDNA 1, RDNA 3, the USB and unnamed IDs and all of Navi 24 stay out. It still reads `vk_main.cpp` to check that the default is Windows-only and that `RX_VK_TASK_MESH_FALLBACK` is read after it. It fails on `main` (no `task_mesh_fallback_default`), and fails with 0x743f put back. - docs: the `RX_VK_TASK_MESH_FALLBACK` row in `docs/development.md` names the chips, the rule and Navi 24's opt-in. The README's AMD row now claims only what reports show: the driver lost the GPU on an RX 6700 XT, an RX 6800 XT and, in one report in Mako, an RX 6600; another RX 6600 played 15-20 minutes on the native path (issue 130); the RX 6400 and 6500 XT keep their own mesh shaders. ### Two RX 6600 reports | | Mako's report (sharkiix) | [Longshot issue 130](https://git.magicbean.dev/MagicBeanDev/Longshot/issues/130) | |---|---|---| | Card, driver | RX 6600, Vulkan driver 0x800161 | RX 6600 8 GB, 26.10.1 (Vulkan driver 0x800161) | | Build | Mako 3.5 (merged Hookshot of 2026-11-11 plus Mako's own changes) | Hookshot v2.2.0-rc.1 (source 006e7dfe) | | Path | native task + mesh | native task + mesh (Navi 23 was not in that build's list) | | What happened | device lost on the session's first task + mesh draws: `OptimizeChangeBanc` `DrawMeshTasks` 1..3, then a 5 s GPU wait | 15-20 minutes (48,360 presents) through Market, Ganon's Castle, Kokiri Forest, the Lost Woods and Gerudo Valley, then device lost about 6 s after a teleport into Death Mountain Crater | | VRAM | not reported | at the driver's limit all session; last status `6125 MB used of 6317 MB allowed`, textures 1849 MB against a 1260 MB budget | | Log | none published: the commit message is all there is | quoted in the issue | How they fit together, as far as the evidence goes: - **Issue 130 shows the native path can run on Navi 23 for a long time.** Kokiri Forest and the Lost Woods are full of task + mesh foliage, and it drew them for minutes. So "lost on the first task + mesh draws" is not a rule for the chip on this driver. - **Both losses came at an area load.** `OptimizeChangeBanc` is the game's scene-change thread. So Mako's loss happened where VRAM and uploads peak too, the same moment as issue 130's. AMD's Windows driver gives no fault info, and "DrawMeshTasks 1..3, then a 5 s GPU wait" is the last work recorded before the timeout, not the work that faulted. Without the log there is no telling a mesh-path timeout from a paging timeout like issue 130's. - **Mako's tree differed from the build in issue 130.** At the merge it carried about 2,000 lines of its own changes in `gpu/vk`: AMD FSR Redstone frame generation, `vk_draw.cpp` +290 lines, a perf monitor, the recompiler's value probe, and a second copy of the storage-buffer rule for graphics stages (task and mesh included). Mako 3.5 also turned VRAM compaction on by default. 2d5a9d65 (small read-only storage buffers copied into the recording's stream while their chunk is imported) landed two minutes before the fallback commit, and both shipped in 3.5.1. Whether the reporter's build had it is unknown. None of these is known to cause a first-draw loss, but none is ruled out either, and Longshot main has only some of them. - **Settings:** none are known for Mako's report; issue 130 ran at 2048x1152 with nothing else changed that the log shows. ### What the fallback costs in VRAM From `fallback_buffers_of` in `gpu/vk/vk_draw.cpp` and the constants in `emit_spirv.h`: - **Records:** `(MESH_FALLBACK_HEADER_WORDS + MESH_FALLBACK_RECORD_WORDS) * 4` = (8 + 16 Mi words) × 4 B = **64 MB** per buffer pair. It is the same size for every program. - **Payload** (task programs only): `65535 * 4` B (a 256 KB map) + `ceil(65535 / task threads) * payload_words * 4` B. `payload_words` is the program's lines × 32 (at most 511 lines), so 128 B to 64 KB per task workgroup. At 32 task threads that is 256 KB + 2048 × (128 B to 64 KB), from about 0.5 MB up to about 128 MB. The source's own note puts it at about 6.5 MB at 800 words. - **How many:** one set of pairs per recording thread. By default there is one recording thread, the replay thread (`RX_VK_PARALLEL` is off). With `RX_VK_PARALLEL=n` there are n, up to 8, each with its own set. - **Growth:** a task program whose payload fits no existing pair makes a new pair: another 64 MB of records plus the larger payload. Grown pairs stay for the session, since a command buffer recorded earlier may still read them. So it is about 64 MB plus the payload for the first pair, and another 64 MB or more each time a larger payload first appears. How many times that happens in this game is not measured, and no log line counts it. - **Against issue 130:** at its last status the headroom was 192 MB (6125 of 6317 MB), and textures were 590 MB over their budget. One pair of about 70 MB is about 1% of that allowance. Three pairs (about 200 MB) would be all of the headroom that session had. The native path allocates none of this. On an 8 GB card at its limit, the fallback **can make issue 130's failure more likely**, and on 4 GB Navi 24 it is a bigger share still. The test run below watches for this. **On the default:** the evidence does not show yet that Navi 23 needs it. Issue 130 points to VRAM, not the mesh path. Mako's report has no log, and it came from a different tree. My proposal: this PR stays WIP until a Windows RX 6600-class run (T-V2MY) compares main and this PR with the `vk: VRAM:` status line watched. - If main loses the device on the native path where this PR doesn't, and VRAM stays under the allowance, Navi 23 goes in. - If main runs clean, or the PR's VRAM gets near the allowance, Navi 23 stays opt-in like Navi 24, and this PR keeps only the move to `mesh_mode.h`, the ID rule and the docs. ## Flags and settings | Flag | What it does | Default now | Recommendation | Helps on | Doesn't help on | Untested on | |---|---|---|---|---|---|---| | `RX_VK_TASK_MESH_FALLBACK=0/1` (existing) | Task + mesh draws through the compute fallback (1) or the driver's mesh shaders (0) | On for AMD Navi 21, 22 and 23 on Windows (was Navi 21 and 22 consumer IDs only); Navi 24 off | Navi 23 on only if the Windows RX 6600 run shows the native path losing the device and the fallback staying within VRAM; Navi 24 opt-in (`=1`) | Windows AMD RDNA 2 where the native path times out (Navi 21 and 22 reported) | Linux (RADV already uses the compute path), RDNA 3/4, NVIDIA, Intel: unchanged | Every Navi 23 card, Navi 21's Pro IDs; `=0` turns it off for a run | ## Measurements None possible: this PC has no RDNA 2 card (RTX 4070 Ti, driver 595.99.02, Linux), and the change only applies on Windows with AMD. The VRAM figures above are worked out from the source, not measured. main: fbd42024 (2026-11-13) this PR: fix/navi23-24-mesh-fallback @ ea448fe7 Hardware: none with the affected GPUs Scene: n/a Method: n/a. The motivating report is Mako's (by sharkiix): an RX 6600 on Windows, AMD Vulkan driver 0x800161, lost the device on the session's first task + mesh draws (`OptimizeChangeBanc` `DrawMeshTasks` 1..3, then a 5 s GPU wait). The counter-report is issue 130 (quoted above). How to reproduce: on an RX 6600 / 6600 XT / 6650 XT on Windows, the same save and settings on `main` and on this PR, from a fresh start into Kokiri Forest, then the Lost Woods, Hyrule Field, Castle Town and Death Mountain Crater, 15-20 minutes each. The log's `vk: task + mesh programs use the compute fallback` line says the fallback is on. Note every `vk: VRAM: N MB used of M MB allowed` line and the fps. | | main @ fbd42024 | this PR @ ea448fe7 | |---|---|---| | Device lost, RX 6600 (Mako's report) | on the first task + mesh draws | not measured | | Device lost, RX 6600 (issue 130, Hookshot v2.2.0-rc.1, same native path as main) | after 15-20 min, at the VRAM limit | not measured | | VRAM, fps | not measured | not measured | ``` (none from this PC; Mako's report: device lost after OptimizeChangeBanc DrawMeshTasks 1..3, then a 5 s GPU wait, driver 0x800161; issue 130: vk: VRAM: 6125 MB used of 6317 MB allowed (1061 MB of it free in the blocks); textures 1849 MB (budget 1260 MB), then vk: submit 339379 failed (-4) / VK_ERROR_DEVICE_LOST) ``` ## Testing **Tested:** game-free checks on Linux (RTX 4070 Ti, clang). `tests/test_task_mesh_fallback_devices.py` passes here. It fails on `main`, and fails with 0x743f put back in the list. `tests/test_mesh_mode_switch.py` passes. `python3 -I -B tests/run_all.py --jobs 4` (with `LONGSHOT_VULKAN_HEADERS` set) on ea448fe7: 498 passed, 1 failed, 30 skipped. The one failure, `tests/test_lift_cache.py` (`import lift, split_hot` fails: no numpy here), also fails on `main`. `vk_main.cpp` was not compiled here: it needs `windows.h`, and there is no mingw toolchain on this PC. Its change is one call into `mesh_mode.h`, which the test compiles with `-Wall -Wextra -Werror`. **Not tested:** not run in the game: no RDNA 2 card or Windows AMD system here. Not tested: whether the fallback stops a device lost on Navi 23, how much VRAM it takes in play, what it costs in frame rate there, and anything on Navi 21's Pro IDs. **Needs other testers:** - RX 6600 / 6600 XT / 6650 XT on Windows (8 GB): main, then this PR, then main again, same save and settings, 15-20 min from Kokiri Forest to Death Mountain Crater. Watch the `vk: VRAM:` lines and note any device lost, and compare fps with main. Expecting no device lost on the PR, VRAM under the allowance, fps within a few % of main. A clean run on main matters too: it says whether the default is needed (T-V2MY). ## Screenshots Nothing on screen. ## Risk and rollback Navi 23 (and Navi 21's Pro IDs) on Windows now take the compute fallback, which can be slower, and which holds at least 64 MB more VRAM per recording thread, more as payloads grow. On an 8 GB card at the driver's limit, that can bring on issue 130's device lost sooner. `RX_VK_TASK_MESH_FALLBACK=0` or `RX_VK_MESH_SHADERS=native` restores the native path for a run. Reverting the commits restores the old list. The pipeline cache's stamp already holds the mesh path, so the first start on an affected card translates the programs again. ## Reviewer notes - The ID rule's Navi 21 part (ea448fe7) is a separate commit so it can go on its own if you'd rather not widen Navi 21 here. - A log line when the fallback makes a buffer pair (its size, the thread) would make the VRAM cost exact in a test run. Not added, as the review asked for nothing in the code beyond the ID rule. Say if you want it here. ## Issues https://github.com/NotRexed/Hookshot/issues/996; https://git.magicbean.dev/MagicBeanDev/Longshot/issues/130 (the counter-report and the VRAM risk). ## Checklist ### For everyone - [x] One topic. - [x] The title is a Conventional Commit (`type(scope): description`). - [x] Rebased on current `main`. - [x] `python -I -B tests/run_all.py` run and passing (any failure that also fails on `main` is named above). - [ ] Tested in the game, or what wasn't is named under Testing. (not run in the game; no RDNA 2 card here: see Testing) - [x] Testing filled in: what was tested, what wasn't, and what needs other testers (with test requests). - [ ] Measured: main and this PR at named commits, on the same PC, scene and settings, at least 2 interleaved runs each, the median reported. (no affected hardware here; T-V2MY asks for it) - [x] No game files, dumps, build output or generated files. - [x] `third_party/` untouched (a new folder with a `PROVENANCE.md` instead). - [x] The license is OK: GPL-3.0-or-later, nothing incompatible and nothing decompiled. ### If applicable - [x] AI assistance recorded with `Assisted-by:` / `Co-Authored-By:` trailers. - [x] Flags noted, and the switch reference updated (docs/development.md, the README). - [x] A game-free test added for the fix, failing on `main` and passing here. - [x] A check under `tests/` that reads changed source updated in this PR, not weakened. - [x] Docs updated. - [ ] Host code builds on both Windows (llvm-mingw) and Linux, with UTF-8 paths. (Linux only: no llvm-mingw here. `mesh_mode.h` is portable C++ the test compiles; `vk_main.cpp`'s change is one call into it)
fix(vk): task + mesh compute fallback by default for Navi 23 and Navi 24 on Windows
Some checks failed
PR description / Description follows the template (pull_request_target) Successful in 3s
Details
Website / Website on Cloudflare (pull_request_target) Has been skipped
Details
CI / Conventional Commit title (pull_request) Has been cancelled
Details
CI / Python source checks (ubuntu-24.04, part 1/2) (pull_request) Has been cancelled
Details
CI / Python source checks (ubuntu-24.04, part 2/2) (pull_request) Has been cancelled
Details
CI / SPIR-V fixtures (global narrow load/store, direct surface atomics, F2I immediate) (pull_request) Has been cancelled
Details
CI / Workflow lint (actionlint) (pull_request) Has been cancelled
Details
Third-party parts / As their notes say (pull_request) Has been cancelled
Details
Third-party parts / The same as upstream (pull_request) Has been cancelled
Details
6cd317195b 
An RX 6600 (Navi 23, AMD driver 0x800161) lost the device on the session's first task + mesh draws
(OptimizeChangeBanc DrawMeshTasks 1..3, then a 5 s GPU wait), the issue 996 family that Navi 21 and 22
already get the fallback for. Navi 23 (0x73e0, 0x73e1, 0x73e3, 0x73ef, 0x73ff: RX 6600, 6600 XT, 6650 XT,
6600M, Pro W6600/W6600M) and Navi 24 (0x743f: RX 6400, 6500 XT), the same RDNA 2 mesh path, join the
Windows default.

The list moves from vk_main.cpp into mesh_rule::task_mesh_fallback_default in gpu/vk/mesh_mode.h, so
tests/test_task_mesh_fallback_devices.py compiles it and checks each ID, other makers and RDNA 2 IDs left
out, besides reading vk_main.cpp for the Windows guard and the RX_VK_TASK_MESH_FALLBACK override.

Ported from Mako, by sharkiix, c4fd465a55

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Assisted-by: Claude Opus 5.5
Co-authored-by: Cursor <[email protected]>
HumanBean reviewed 2026-11-13 15:55:01 +00:00
HumanBean left a comment

The code change is small and correct. The ID list moves into mesh_rule::task_mesh_fallback_default(), it is still asked for only under #ifdef _WIN32 (Linux RADV is unchanged), and RX_VK_MESH_SHADERS=native and RX_VK_TASK_MESH_FALLBACK still decide after it. The existing vk: task + mesh programs use the compute fallback log line covers the new cards. The new test compiles the header and checks AMD-only membership, which is better than the old regex. The Navi 23 and Navi 24 IDs that were added match pci-ids and amdgpu.ids.

What holds it back is the evidence, not the code:

  1. This makes a new default for every Windows Navi 23 and Navi 24 player, and no affected card has run it. AGENTS.md asks a new default to say which hardware it was measured on and what it costs where it wasn't. The PR names none for Navi 23 or 24. It needs at least one Windows RX 6600-class run (device lost gone, fps against main), and a Navi 24 run before 0x743f goes in. Asking for those through test requests is the right next step.
  2. Our own RX 6600 report points the other way on cost. #130 is an RX 6600 on the same driver (0x800161). It played 15-20 minutes through several areas on the native path. It then lost the device at the driver's VRAM limit, with about 6.1 of 6.3 GB in use. That doesn't fit "lost on the session's first task + mesh draws" as a rule for the chip. The fallback adds memory: its records buffer is 64 MB per recording thread (MESH_FALLBACK_RECORD_WORDS, fallback_buffers_of in gpu/vk/vk_draw.cpp), plus payloads, and grown buffers stay. So on 8 GB Navi 23 it could make issue 130's failure more likely. On 4 GB Navi 24 the cost is larger still. Please link issue 130 and say how the two reports fit together, and have the test run watch the VRAM status line.
  3. The ID choice isn't consistent. The workstation W6600 (0x73e3) and W6600M (0x73e1) are added "not reported", but the consumer RX 6300 (0x7424, same die as the 6400) and the W6400/W6300 are left out for the same reason. Pick one rule for both chips. Also, the README now says "RX 6400 to RX 6950 XT" and "as the driver lost the GPU with them", but nothing lost the GPU on Navi 24.
  4. The description's "See #996" links to Longshot's own #996. Per AGENTS.md, use https://github.com/NotRexed/Hookshot/issues/996.

Leaving this as a comment: it is WIP, and the code needs nothing beyond point 3. Points 1 and 2 decide whether it should merge.

The code change is small and correct. The ID list moves into `mesh_rule::task_mesh_fallback_default()`, it is still asked for only under `#ifdef _WIN32` (Linux RADV is unchanged), and `RX_VK_MESH_SHADERS=native` and `RX_VK_TASK_MESH_FALLBACK` still decide after it. The existing `vk: task + mesh programs use the compute fallback` log line covers the new cards. The new test compiles the header and checks AMD-only membership, which is better than the old regex. The Navi 23 and Navi 24 IDs that were added match pci-ids and amdgpu.ids. What holds it back is the evidence, not the code: 1. **This makes a new default for every Windows Navi 23 and Navi 24 player, and no affected card has run it.** AGENTS.md asks a new default to say which hardware it was measured on and what it costs where it wasn't. The PR names none for Navi 23 or 24. It needs at least one Windows RX 6600-class run (device lost gone, fps against main), and a Navi 24 run before 0x743f goes in. Asking for those through test requests is the right next step. 2. **Our own RX 6600 report points the other way on cost.** https://git.magicbean.dev/MagicBeanDev/Longshot/issues/130 is an RX 6600 on the same driver (0x800161). It played 15-20 minutes through several areas on the native path. It then lost the device at the driver's VRAM limit, with about 6.1 of 6.3 GB in use. That doesn't fit "lost on the session's first task + mesh draws" as a rule for the chip. The fallback adds memory: its records buffer is 64 MB per recording thread (`MESH_FALLBACK_RECORD_WORDS`, `fallback_buffers_of` in `gpu/vk/vk_draw.cpp`), plus payloads, and grown buffers stay. So on 8 GB Navi 23 it could make issue 130's failure more likely. On 4 GB Navi 24 the cost is larger still. Please link issue 130 and say how the two reports fit together, and have the test run watch the VRAM status line. 3. **The ID choice isn't consistent.** The workstation W6600 (0x73e3) and W6600M (0x73e1) are added "not reported", but the consumer RX 6300 (0x7424, same die as the 6400) and the W6400/W6300 are left out for the same reason. Pick one rule for both chips. Also, the README now says "RX 6400 to RX 6950 XT" and "as the driver lost the GPU with them", but nothing lost the GPU on Navi 24. 4. The description's "See #996" links to Longshot's own #996. Per AGENTS.md, use https://github.com/NotRexed/Hookshot/issues/996. Leaving this as a comment: it is WIP, and the code needs nothing beyond point 3. Points 1 and 2 decide whether it should merge.
gpu/vk/mesh_mode.h Outdated
@ -44,0 +46,4 @@
/// Windows, where AMD's driver timed out on the native task + mesh path of RDNA 2. Navi 22 first, then Navi 21: on an RX
/// 6800 XT (driver 0x800161) the native path lost the device within minutes at Hyrule Castle's entrance, while the
/// fallback played 25 minutes there with none. Navi 23: an RX 6600 (driver 0x800161) lost the device on the session's
/// first task + mesh draws (reported in Mako by sharkiix). Navi 24 has the same RDNA 2 mesh path, not tested on its own
HumanBean commented 2026-11-13 15:55:01 +00:00
Owner

#130 is an RX 6600 on this same driver (0x800161). It ran the native path for 15-20 minutes through several areas, then lost the device at the VRAM limit. So "first task + mesh draws" isn't universal on Navi 23, and the fallback's extra memory could make issue 130's failure more likely. Worth saying here, or at least in the PR, what tells the two reports apart.

https://git.magicbean.dev/MagicBeanDev/Longshot/issues/130 is an RX 6600 on this same driver (0x800161). It ran the native path for 15-20 minutes through several areas, then lost the device at the VRAM limit. So "first task + mesh draws" isn't universal on Navi 23, and the fallback's extra memory could make issue 130's failure more likely. Worth saying here, or at least in the PR, what tells the two reports apart.
gpu/vk/mesh_mode.h Outdated
@ -44,0 +55,4 @@
case 0x73a5: // Navi 21: RX 6950 XT
case 0x73df: // Navi 22: RX 6700, 6700 XT, 6750 XT, 6750 GRE 12GB
case 0x73e0: // Navi 23: RX 6600M
case 0x73e1: // Navi 23: Radeon Pro W6600M
HumanBean commented 2026-11-13 15:55:01 +00:00
Owner

The W6600M and W6600 (here and the next line) are added with no report, but the RX 6300 (0x7424, a consumer Navi 24 card) and the W6400/W6300 (0x7422/0x7423) stay out "as none reported". Use one rule for both chips: either the whole family of each chip, or only the cards someone reported on.

The W6600M and W6600 (here and the next line) are added with no report, but the RX 6300 (0x7424, a consumer Navi 24 card) and the W6400/W6300 (0x7422/0x7423) stay out "as none reported". Use one rule for both chips: either the whole family of each chip, or only the cards someone reported on.
gpu/vk/mesh_mode.h Outdated
@ -44,0 +59,4 @@
case 0x73e3: // Navi 23: Radeon Pro W6600
case 0x73ef: // Navi 23: RX 6650 XT
case 0x73ff: // Navi 23: RX 6600, 6600 XT, 6600 LE
case 0x743f: // Navi 24: RX 6400, 6500 XT
HumanBean commented 2026-11-13 15:55:01 +00:00
Owner

Navi 24 goes into the default with no report and no run ("not tested on its own"). These are 4 GB cards on PCIe x4. The fallback's records buffer is 64 MB per recording thread, plus payloads, and grown buffers stay (fallback_buffers_of, vk_draw.cpp). That makes this the card where the fallback's memory cost hurts most. I'd hold 0x743f until a 6400/6500 XT run on Windows shows the native path loses the device there and the fallback stays playable within VRAM.

Navi 24 goes into the default with no report and no run ("not tested on its own"). These are 4 GB cards on PCIe x4. The fallback's records buffer is 64 MB per recording thread, plus payloads, and grown buffers stay (`fallback_buffers_of`, vk_draw.cpp). That makes this the card where the fallback's memory cost hurts most. I'd hold 0x743f until a 6400/6500 XT run on Windows shows the native path loses the device there and the fallback stays playable within VRAM.
HumanBean added this to the v3.0.0 milestone 2026-11-13 16:17:58 +00:00
TrashPanda force-pushed fix/navi23-24-mesh-fallback from 6cd317195b
Some checks failed
PR description / Description follows the template (pull_request_target) Successful in 3s
Details
Website / Website on Cloudflare (pull_request_target) Has been skipped
Details
CI / Conventional Commit title (pull_request) Has been cancelled
Details
CI / Python source checks (ubuntu-24.04, part 1/2) (pull_request) Has been cancelled
Details
CI / Python source checks (ubuntu-24.04, part 2/2) (pull_request) Has been cancelled
Details
CI / SPIR-V fixtures (global narrow load/store, direct surface atomics, F2I immediate) (pull_request) Has been cancelled
Details
CI / Workflow lint (actionlint) (pull_request) Has been cancelled
Details
Third-party parts / As their notes say (pull_request) Has been cancelled
Details
Third-party parts / The same as upstream (pull_request) Has been cancelled
Details
to ea448fe7ba
Some checks failed
Website / Website on Cloudflare (pull_request) Blocked by required conditions
Details
PR description / Description follows the template (pull_request_target) Successful in 3s
Details
CI / Conventional Commit title (pull_request) Has been cancelled
Details
CI / Python source checks (ubuntu-24.04, part 1/2) (pull_request) Has been cancelled
Details
CI / Python source checks (ubuntu-24.04, part 2/2) (pull_request) Has been cancelled
Details
CI / SPIR-V fixtures (global narrow load/store, direct surface atomics, F2I immediate) (pull_request) Has been cancelled
Details
CI / Workflow lint (actionlint) (pull_request) Has been cancelled
Details
Third-party parts / As their notes say (pull_request) Has been cancelled
Details
Third-party parts / The same as upstream (pull_request) Has been cancelled
Details
2026-11-13 18:04:52 +00:00 Compare
TrashPanda changed title from WIP: fix(vk): task + mesh compute fallback by default for Navi 23 and Navi 24 on Windows to WIP: fix(vk): task + mesh compute fallback by default for Navi 23 on Windows, one rule for the IDs 2026-11-13 18:06:55 +00:00
TrashPanda commented 2026-11-13 18:06:56 +00:00
Author
Contributor

Thanks for the review. Rebased on main (fbd42024); the head is now ea448fe7. Point by point:

  1. This makes a new default for every Windows Navi 23 and Navi 24 player, and no affected card has run it. [...] It needs at least one Windows RX 6600-class run (device lost gone, fps against main), and a Navi 24 run before 0x743f goes in.
  • Navi 24: done in b61f1018. 0x743f is out of the default, and so is the rest of Navi 24. mesh_mode.h and docs/development.md say it is not on by default and that RX_VK_TASK_MESH_FALLBACK=1 tries it. The test now checks 0x743f stays out, and it fails if 0x743f is put back.
  • Navi 23: not run. There is no RDNA 2 card or Windows AMD system here. The test request is open as T-V2MY: an RX 6600-class card on Windows, main, then this PR, then main again, same save and settings, 15-20 min from Kokiri Forest to Death Mountain Crater. It watches the vk: VRAM: lines and any device lost, and compares fps with main. The PR stays WIP until it comes back.
  1. Our own RX 6600 report points the other way on cost. [...] Please link issue 130 and say how the two reports fit together, and have the test run watch the VRAM status line.

Done in the description ("Two RX 6600 reports", "What the fallback costs in VRAM"). Issue 130 is linked there, in the README row and in mesh_mode.h's comment. In short:

  • Same card and driver (0x800161), both on the native path. Issue 130 drew task + mesh foliage for 15-20 minutes (Kokiri Forest, the Lost Woods) and lost the device at the VRAM limit. So "lost on the first draws" is not a rule for the chip.
  • Both losses came at an area load: OptimizeChangeBanc is the scene-change thread. "DrawMeshTasks 1..3, then a 5 s wait" is the last work recorded before the timeout, not what faulted. AMD's Windows driver names nothing.
  • Mako published no log, VRAM figures or settings; the commit message is all there is. Its tree carried about 2,000 lines of its own gpu/vk changes, including Redstone frame generation, vk_draw.cpp +290 lines and a second copy of the storage-buffer rule for task and mesh stages. A storage-buffer change landed two minutes before the fallback in the same 3.5.1. None is known to cause it, but none is ruled out.
  • The cost: 64 MB of records per buffer pair ((8 + MESH_FALLBACK_RECORD_WORDS) * 4), plus a payload of 0.5 MB to about 128 MB at 32 task threads. That is per recording thread: one by default, up to 8 with RX_VK_PARALLEL. A bigger payload makes a new pair (another 64 MB), and the old pairs stay. Against issue 130's last status (192 MB of headroom), one pair is about 1% of the allowance and three would be all of the headroom.

Plainly: the evidence doesn't yet show Navi 23 needs this default, and it can make issue 130's failure more likely. My proposal is that it stays WIP until T-V2MY decides. If main loses the device where the PR doesn't, and VRAM stays under the allowance, Navi 23 goes in. Otherwise Navi 23 becomes opt-in like Navi 24, and the PR keeps only the move to mesh_mode.h, the ID rule and the docs.

  1. The ID choice isn't consistent. [...] Pick one rule for both chips. Also, the README now says "RX 6400 to RX 6950 XT" and "as the driver lost the GPU with them", but nothing lost the GPU on Navi 24.
  • The rule: done in ea448fe7, stated in mesh_mode.h's comment and the description. An included chip brings every ID that pci-ids or amdgpu.ids name a card for, consumer, mobile and Pro alike. Not its USB or audio functions, nor unnamed IDs.
    • Navi 23 keeps all five of its IDs (W6600 and W6600M included).
    • Navi 24 is out as a whole (0x743f and 0x7421 to 0x7424), so the RX 6300 question goes away for now.
    • Checking Navi 21 against the rule: it had its consumer IDs only. So its Pro IDs come in too: 0x73a1 V620, 0x73a2 W6900X, 0x73a3 W6800, 0x73ab W6800X, 0x73ae V620 MxGPU. That is a separate commit, so it can be dropped if you'd rather not widen Navi 21 here; then the rule would read "consumer and mobile", and W6600 and W6600M would go too.
  • README: done in b61f1018. It now says the RX 6600 to RX 6950 XT (Navi 21 to 23) use the fallback by default, and that the driver lost the GPU on an RX 6700 XT, an RX 6800 XT and, in one report in Mako, an RX 6600. It adds that another RX 6600 played 15-20 minutes on the native path (issue 130), and that the RX 6400 and 6500 XT keep their own mesh shaders.
  1. The description's "See #996" links to Longshot's own #996.

Done: the description, the commit messages and the comments this PR adds (mesh_mode.h, vk_main.cpp, the test) now use https://github.com/NotRexed/Hookshot/issues/996. The first commit's message was reworded for it. That also dropped a stray Co-authored-by: Cursor trailer, which should not have been there.

Line comments:

(mesh_mode.h, 0x73e1/0x73e3) Use one rule for both chips: either the whole family of each chip, or only the cards someone reported on.

The whole family of each chip, as in point 3 (ea448fe7).

(mesh_mode.h, 0x743f) I'd hold 0x743f until a 6400/6500 XT run on Windows shows the native path loses the device there and the fallback stays playable within VRAM.

Held, in b61f1018. All of Navi 24 is out. There is no Navi 24 request yet; one only makes sense after the Navi 23 run.

(mesh_mode.h, the comment) Worth saying here, or at least in the PR, what tells the two reports apart.

Both. The comment says the Mako report has no log, that issue 130's RX 6600 played 15-20 minutes on the native path and lost the device only at the VRAM limit, and that the fallback costs VRAM of its own. The PR has the full comparison.

Tests: python3 -I -B tests/run_all.py --jobs 4 on ea448fe7: 498 passed, 1 failed (test_lift_cache.py, no numpy here; it fails on main too), 30 skipped.

Thanks for the review. Rebased on main (fbd42024); the head is now ea448fe7. Point by point: > 1. This makes a new default for every Windows Navi 23 and Navi 24 player, and no affected card has run it. [...] It needs at least one Windows RX 6600-class run (device lost gone, fps against main), and a Navi 24 run before 0x743f goes in. - **Navi 24:** done in b61f1018. 0x743f is out of the default, and so is the rest of Navi 24. `mesh_mode.h` and `docs/development.md` say it is not on by default and that `RX_VK_TASK_MESH_FALLBACK=1` tries it. The test now checks 0x743f stays out, and it fails if 0x743f is put back. - **Navi 23:** not run. There is no RDNA 2 card or Windows AMD system here. The test request is open as **T-V2MY**: an RX 6600-class card on Windows, main, then this PR, then main again, same save and settings, 15-20 min from Kokiri Forest to Death Mountain Crater. It watches the `vk: VRAM:` lines and any device lost, and compares fps with main. The PR stays WIP until it comes back. > 2. Our own RX 6600 report points the other way on cost. [...] Please link issue 130 and say how the two reports fit together, and have the test run watch the VRAM status line. Done in the description ("Two RX 6600 reports", "What the fallback costs in VRAM"). Issue 130 is linked there, in the README row and in `mesh_mode.h`'s comment. In short: - Same card and driver (0x800161), both on the native path. Issue 130 drew task + mesh foliage for 15-20 minutes (Kokiri Forest, the Lost Woods) and lost the device at the VRAM limit. So "lost on the first draws" is not a rule for the chip. - Both losses came at an area load: `OptimizeChangeBanc` is the scene-change thread. "DrawMeshTasks 1..3, then a 5 s wait" is the last work recorded before the timeout, not what faulted. AMD's Windows driver names nothing. - Mako published no log, VRAM figures or settings; the commit message is all there is. Its tree carried about 2,000 lines of its own `gpu/vk` changes, including Redstone frame generation, `vk_draw.cpp` +290 lines and a second copy of the storage-buffer rule for task and mesh stages. A storage-buffer change landed two minutes before the fallback in the same 3.5.1. None is known to cause it, but none is ruled out. - The cost: 64 MB of records per buffer pair (`(8 + MESH_FALLBACK_RECORD_WORDS) * 4`), plus a payload of 0.5 MB to about 128 MB at 32 task threads. That is per recording thread: one by default, up to 8 with `RX_VK_PARALLEL`. A bigger payload makes a new pair (another 64 MB), and the old pairs stay. Against issue 130's last status (192 MB of headroom), one pair is about 1% of the allowance and three would be all of the headroom. Plainly: the evidence doesn't yet show Navi 23 needs this default, and it can make issue 130's failure more likely. My proposal is that it stays WIP until T-V2MY decides. If main loses the device where the PR doesn't, and VRAM stays under the allowance, Navi 23 goes in. Otherwise Navi 23 becomes opt-in like Navi 24, and the PR keeps only the move to `mesh_mode.h`, the ID rule and the docs. > 3. The ID choice isn't consistent. [...] Pick one rule for both chips. Also, the README now says "RX 6400 to RX 6950 XT" and "as the driver lost the GPU with them", but nothing lost the GPU on Navi 24. - **The rule:** done in ea448fe7, stated in `mesh_mode.h`'s comment and the description. An included chip brings every ID that pci-ids or amdgpu.ids name a card for, consumer, mobile and Pro alike. Not its USB or audio functions, nor unnamed IDs. - Navi 23 keeps all five of its IDs (W6600 and W6600M included). - Navi 24 is out as a whole (0x743f and 0x7421 to 0x7424), so the RX 6300 question goes away for now. - Checking Navi 21 against the rule: it had its consumer IDs only. So its Pro IDs come in too: 0x73a1 V620, 0x73a2 W6900X, 0x73a3 W6800, 0x73ab W6800X, 0x73ae V620 MxGPU. That is a separate commit, so it can be dropped if you'd rather not widen Navi 21 here; then the rule would read "consumer and mobile", and W6600 and W6600M would go too. - **README:** done in b61f1018. It now says the RX 6600 to RX 6950 XT (Navi 21 to 23) use the fallback by default, and that the driver lost the GPU on an RX 6700 XT, an RX 6800 XT and, in one report in Mako, an RX 6600. It adds that another RX 6600 played 15-20 minutes on the native path (issue 130), and that the RX 6400 and 6500 XT keep their own mesh shaders. > 4. The description's "See #996" links to Longshot's own #996. Done: the description, the commit messages and the comments this PR adds (`mesh_mode.h`, `vk_main.cpp`, the test) now use https://github.com/NotRexed/Hookshot/issues/996. The first commit's message was reworded for it. That also dropped a stray `Co-authored-by: Cursor` trailer, which should not have been there. Line comments: > (mesh_mode.h, 0x73e1/0x73e3) Use one rule for both chips: either the whole family of each chip, or only the cards someone reported on. The whole family of each chip, as in point 3 (ea448fe7). > (mesh_mode.h, 0x743f) I'd hold 0x743f until a 6400/6500 XT run on Windows shows the native path loses the device there and the fallback stays playable within VRAM. Held, in b61f1018. All of Navi 24 is out. There is no Navi 24 request yet; one only makes sense after the Navi 23 run. > (mesh_mode.h, the comment) Worth saying here, or at least in the PR, what tells the two reports apart. Both. The comment says the Mako report has no log, that issue 130's RX 6600 played 15-20 minutes on the native path and lost the device only at the VRAM limit, and that the fallback costs VRAM of its own. The PR has the full comparison. Tests: `python3 -I -B tests/run_all.py --jobs 4` on ea448fe7: 498 passed, 1 failed (`test_lift_cache.py`, no numpy here; it fails on main too), 30 skipped.
TrashPanda force-pushed fix/navi23-24-mesh-fallback from ea448fe7ba
Some checks failed
Website / Website on Cloudflare (pull_request) Blocked by required conditions
Details
PR description / Description follows the template (pull_request_target) Successful in 3s
Details
CI / Conventional Commit title (pull_request) Has been cancelled
Details
CI / Python source checks (ubuntu-24.04, part 1/2) (pull_request) Has been cancelled
Details
CI / Python source checks (ubuntu-24.04, part 2/2) (pull_request) Has been cancelled
Details
CI / SPIR-V fixtures (global narrow load/store, direct surface atomics, F2I immediate) (pull_request) Has been cancelled
Details
CI / Workflow lint (actionlint) (pull_request) Has been cancelled
Details
Third-party parts / As their notes say (pull_request) Has been cancelled
Details
Third-party parts / The same as upstream (pull_request) Has been cancelled
Details
to 3f85a37581
Some checks are pending
CI / Conventional Commit title (pull_request) Blocked by required conditions
Details
CI / Python source checks (ubuntu-24.04, part 1/2) (pull_request) Blocked by required conditions
Details
CI / Python source checks (ubuntu-24.04, part 2/2) (pull_request) Blocked by required conditions
Details
CI / SPIR-V fixtures (global narrow load/store, direct surface atomics, F2I immediate) (pull_request) Blocked by required conditions
Details
CI / Workflow lint (actionlint) (pull_request) Blocked by required conditions
Details
Third-party parts / The same as upstream (pull_request) Blocked by required conditions
Details
Third-party parts / As their notes say (pull_request) Blocked by required conditions
Details
PR description / Description follows the template (pull_request_target) Successful in 4s
Details
2026-11-13 18:07:52 +00:00 Compare
TrashPanda commented 2026-11-13 18:07:56 +00:00
Author
Contributor

Reworded the last two commits' messages only (an unwanted tool trailer removed), no code change: b61f1018 is now 6fc9dbe2 and ea448fe7 is now 3f85a375. The review answer's hashes map to these.

Reworded the last two commits' messages only (an unwanted tool trailer removed), no code change: b61f1018 is now 6fc9dbe2 and ea448fe7 is now 3f85a375. The review answer's hashes map to these.
Some checks are pending
CI / Conventional Commit title (pull_request) Blocked by required conditions
Details
CI / Python source checks (ubuntu-24.04, part 1/2) (pull_request) Blocked by required conditions
Details
CI / Python source checks (ubuntu-24.04, part 2/2) (pull_request) Blocked by required conditions
Details
CI / SPIR-V fixtures (global narrow load/store, direct surface atomics, F2I immediate) (pull_request) Blocked by required conditions
Details
CI / Workflow lint (actionlint) (pull_request) Blocked by required conditions
Details
Third-party parts / The same as upstream (pull_request) Blocked by required conditions
Details
Third-party parts / As their notes say (pull_request) Blocked by required conditions
Details
PR description / Description follows the template (pull_request_target) Successful in 4s
Details
This pull request is marked as a work in progress.
Some workflows are waiting to be reviewed.
This branch is out-of-date with the base branch
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u 'fix/navi23-24-mesh-fallback:TrashPanda-fix/navi23-24-mesh-fallback'
git switch 'TrashPanda-fix/navi23-24-mesh-fallback'
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
area/accessibility
Barriers for people with disabilities

  
area/audio
Sound and music

  
area/input
Controllers, keyboard, mouse

  
area/install
Installing, updating, building from your game

  
area/menu
In-game menu and settings

  
area/renderer
Vulkan renderer, shaders, effects

  
area/saves
Save files

  
area/upscaling
DLSS, FSR, frame generation

  
good first issue
A good start for a new contributor

  
gpu/amd
AMD GPUs

  
gpu/igpu
Integrated GPUs

  
gpu/intel
Intel GPUs

  
gpu/nvidia
NVIDIA GPUs

  
help wanted
Extra hands or knowledge wanted

  
kind
bug
 Something doesn't work as it should

  
kind
chore
 Build, CI, dependencies, tidying

  
kind
docs
 Documentation

  
kind
feature
 A new feature or an improvement

  
kind
performance
 Frame rate, frame time, loading, memory

  
kind
question
 A question rather than a change

  
needs measurements
Waiting for before/after measurements

  
platform/linux
Linux only

  
platform/steam-deck
Steam Deck

  
platform/windows
Windows only

  
preview
Maintainers: deploy a preview of this PR's website (read its changes first). Removed after the run.

  
priority
critical
 Crashes, data loss, or blocks most players

  
priority
high
 Important: next in line

  
priority
low
 Nice to have

  
status
blocked
 Waits on something else first

  
status
confirmed
 Reproduced or agreed on

  
status
duplicate
 Already reported or proposed

  
status
invalid
 Not a problem in this project

  
status
needs-info
 Waiting for more information from the reporter

  
status
wontfix
 Will not be worked on

  
testing wanted
Wanted: a test on other hardware (posts a test request in #test-requests)

No labels
area/accessibility
area/audio
area/input
area/install
area/menu
area/renderer
area/saves
area/upscaling
good first issue
gpu/amd
gpu/igpu
gpu/intel
gpu/nvidia
help wanted
kind
bug
kind
chore
kind
docs
kind
feature
kind
performance
kind
question
needs measurements
platform/linux
platform/steam-deck
platform/windows
preview
priority
critical
priority
high
priority
low
status
blocked
status
confirmed
status
duplicate
status
invalid
status
needs-info
status
wontfix
testing wanted
Milestone
Clear milestone
No items
No milestone
v3.0.0
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
MagicBeanDev/Longshot!219
No description provided.