MagicBeanDev/Longshot
MagicBeanDev/Longshot
Watch
55
68
Fork
You've already forked Longshot
 71
Code Issues 125 Pull requests 195 Projects Releases 8 Packages Wiki Activity Actions 445

fix(vk): the graphics in AMD's desktop CPUs decode ASTC on the CPU, so Kokiri Forest no longer resets the GPU #489

Open
Yeetbot90 wants to merge 1 commit from Yeetbot90/Longshot:fix/amd-igpu-astc-cpu into main
pull from: Yeetbot90/Longshot:fix/amd-igpu-astc-cpu
merge into: MagicBeanDev:main
Conversation 1 Commits 1 Files changed 2 +22 -1
Yeetbot90 commented 2026-11-14 16:30:26 +00:00
Contributor

Why

On the graphics built into AMD's desktop CPUs (a Ryzen 9 7900X's Radeon Graphics: 2 CUs, the iGPU of a CPU, not an APU; Windows) the game lost the GPU device (VK_ERROR_DEVICE_LOST, then FATAL) within seconds of Kokiri Forest loading in 7 runs of 8. With the ASTC textures decoded on the CPU it loaded Kokiri Forest 4 times of 4 (the last with this PR's own build), at the cost of a pause of about 12 s as the area loads.

What changed

The cause, from the runs' logs: as Kokiri Forest loads, the terrain's two material arrays (1365 x 1365 x 90 layers, 11 levels, ASTC 8x8, 57 MB each) are decoded by the GPU and re-encoded as BC3, one layer and one level at a time. All of it goes into the recording's single upload command buffer: some 2000 dispatches in one submission. On a 2-CU GPU that runs for seconds: in every lost run the game's wait for the GPU took 4-6 s (nvn: GPU waits in 5 s: 1 sync waits (4176-6305 ms)) before Windows reset the GPU. Decoded on the CPU, each array took 5.9-6.7 s on the replay thread, and the device was not lost.

  • ASTC: astc_on_cpu() in gpu/vk/vk_texture.cpp, asked by astc_ready(). RX_VK_ASTC_CPU already sent ASTC to the CPU decoder; unset, it is now on, on Windows, for the iGPU of AMD's Ryzen 7000 (Raphael, PCI 0x164E, the one tested) and Ryzen 9000 (Granite Ridge, 0x13C0) desktop CPUs: the same 2-CU RDNA 2 part. The APUs' larger iGPUs (680M, 780M, 890M) and every other AMD GPU keep the GPU decoder. RX_VK_ASTC_CPU=0 gives the GPU decoder back. The switch is read by the switches' rule (env_value_off), and the log says when the CPU decodes.
  • docs: docs/development.md, RX_VK_ASTC_CPU.
  • Deliberately unchanged: every other GPU (AMD's APUs and dedicated cards, Intel, NVIDIA, Linux and the Steam Deck) keeps the GPU decoder and BC3.

Flags and settings

Flag What it does Default now Recommendation Helps on Doesn't help on Untested on
RX_VK_ASTC_CPU (existing; new default) 1: ASTC decoded on the CPU, kept as RGBA8. 0: the GPU decoder, big textures re-encoded as BC3 Unset: on for the iGPU of AMD's Ryzen 7000 and 9000 desktop CPUs on Windows, off elsewhere On there: the GPU decoder's submission resets the GPU in Kokiri Forest Ryzen 9 7900X's Radeon Graphics (Raphael, RDNA 2, 2 CUs), Windows APUs and dedicated cards: off there, unchanged Ryzen 9000's iGPU (same part, 0x13C0); Linux (default off)

Measurements

main: f804b7b8 (2026-11-14)
this PR: fix/amd-igpu-astc-cpu @ 105bb206
Rebased from 9c9d69ed onto f804b7b8 (#385: the build's split of giant lifted functions, no renderer file); the measurements and the run_all numbers are from 9c9d69ed and still hold, the renderer being the same
Baseline: main @ f804b7b8. In the game its side is the GPU decoder, this PR's side RX_VK_ASTC_CPU=1, both with a renderer built from e072164e (#404's branch: main @ 0caf0618 plus two Intel commits) swapped into one game folder: a renderer from a newer main changes the shader translator and would restart the shader preparation each run. astc_on_cpu() is the only change; the code it switches is the same on both bases.
Hardware: Ryzen 9 7900X's AMD Radeon(TM) Graphics (RDNA 2, 2 CUs), AMD proprietary driver 26.10.1 (Vulkan driver 0x800161), no mesh shaders (the compute fallback), Windows 11; the screen on an RX 9070 XT, so the iGPU's frames are presented across adapters
Scene: New Game or a save, then Kokiri Forest (map: KokiriForest_Child); output resolution 2048x1152
Method: played by hand, one Kokiri Forest load per run, until the device was lost or the game was closed; the numbers are lines from each run's longshot_log.txt. The checks: tests/run_all.py on main and on this PR
How to reproduce: on a Ryzen 7000 or 9000 desktop CPU's iGPU on Windows, walk into Kokiri Forest with RX_VK_ASTC_CPU=0 (main's decoder), then with this PR and no switch

main @ f804b7b8 (GPU decoder) this PR @ 105bb206 (RX_VK_ASTC_CPU=1)
Kokiri Forest loads that lost the device 7 of 8 0 of 4
Upload of each terrain array (replay thread) 29-113 ms to record; the GPU's work then 4-6 s 5917, 5934, 6084, 6155, 6250, 6414, 6466, 6683 ms
Textures held once both arrays are made 1242 MB (325 textures) 2511 MB (310 textures)
tests/run_all.py 531 passed, 5 failed, 34 skipped 531 passed, 5 failed, 34 skipped (the same 5)

The eight runs with the GPU decoder also had other switches (markers, a skipped program, the VRAM mirrors, the issue 817 task shader skipped); none of them kept the device, and the one that did keep it (110 min, markers before every command) uploaded the two arrays at different moments. The three runs with RX_VK_ASTC_CPU=1 had markers before every command on (a build of the closed #466); markers alone did not keep the device (#466's last run). The fourth is this PR's own build with no switch and no markers: Kokiri Forest loaded, about 28 minutes, no device lost.

GPU decoder (RX_VK_CHECKPOINTS=all build, no other switch):
[hos BaseProcExecutor5] map: KokiriForest_Child (child)
[hos Presentation Thread] vk: big ASTC textures are kept as BC3 (re-encoded on the GPU; ASTC as RGBA8 or RX_VK_ASTC_RGBA8=1: as RGBA8)
[hos Presentation Thread] vk: texture 0x10a22aa600 1365x1365x1 x90 levels 11 NVN 0x8e -> vk 137 (ASTC decoded) (324 textures, 1024 MB)
[hos Presentation Thread] vk: slow upload 29.4 ms: #337 0x10a22aa600 1365x1365x1 x90 levels 11 NVN 0x8e ASTC (BC3), 57825 of 57825 KB
[hos Presentation Thread] vk: texture 0x10a5b22c00 1365x1365x1 x90 levels 11 NVN 0x80 -> vk 137 (ASTC decoded) (325 textures, 1242 MB)
[hos sead::MainThread] vk: a capture's wait for write-back 470380 timed out (done 470376)
[hos sead::MainThread] nvn: GPU waits in 5 s: 1 sync waits (5468 ms), 0 polls timed out (0 ms), 0 queue finishes (0 ms)
[hos Presentation Thread] vk: submit 470388 failed (-4)
[hos Presentation Thread] vk: FATAL: the GPU device was lost (VK_ERROR_DEVICE_LOST): the driver stopped or reset the GPU, ...

RX_VK_ASTC_CPU=1:
[hos Presentation Thread] vk: ASTC not sampled by this GPU: blocks are decoded on upload
[hos BaseProcExecutor1] map: KokiriForest_Child (child)
[hos Presentation Thread] vk: texture 0x10a22aa600 1365x1365x1 x90 levels 11 NVN 0x8e -> vk 37 (ASTC decoded) (309 textures, 1651 MB)
[hos Presentation Thread] vk: slow upload 6083.8 ms: #320 0x10a22aa600 1365x1365x1 x90 levels 11 NVN 0x8e ASTC, 57825 of 57825 KB
[hos Presentation Thread] vk: texture 0x10a5b22c00 1365x1365x1 x90 levels 11 NVN 0x80 -> vk 37 (ASTC decoded) (310 textures, 2511 MB)
[hos Presentation Thread] vk: slow upload 6250.1 ms: #321 0x10a5b22c00 1365x1365x1 x90 levels 11 NVN 0x80 ASTC, 57825 of 57825 KB
(no device lost in any of the three; the third ran 24 minutes, Kokiri Forest in them, and was closed)

this PR @ 105bb206's change, no switch:
[hos Presentation Thread] vk: ASTC decoded on the CPU (RX_VK_ASTC_CPU=0: by the GPU; on by default for the graphics in AMD's Ryzen 7000 and 9000 desktop CPUs on Windows)

run_all.py, failing on both sides (this PC's setup; none reads vk_texture.cpp): test_release, test_oot_state_tap,
test_tested_configurations, test_dev_packs, test_walk_key

Testing

Tested: On the iGPU above, the twelve Kokiri Forest loads in Measurements, played by hand. tests/run_all.py on main and on this PR, Windows 11, llvm-mingw from nightly-132-5e072fc8: the same 5 fail on both. test_env_on caught the switch read as set-means-on in a first version; it now uses the switches' rule. The renderer (RX_VK_ONLY) builds on 9c9d69ed and on e072164e. With no switch, the log on the iGPU says ASTC is decoded on the CPU.

This PR's own build with no switch: Kokiri Forest loaded (5934 and 6466 ms for the two arrays) and the game ran about 28 minutes (101760 presents) with no device lost.

Not tested: Frame rate against main: main loses the device in Kokiri Forest. Hyrule Field and the other areas with the same arrays. A PC with 16 GB of RAM or less (a smaller texture budget, with the arrays at 4x their BC3 size). Ryzen 9000's iGPU (the same 2-CU part, 0x13C0: on by default, not run) and newer drivers. AMD's APUs are left as they are. A Linux build was not run: the change is standard C++ under #ifdef _WIN32, so Linux keeps main's behaviour.

Needs other testers:

  • A Ryzen 9000 desktop CPU's iGPU on Windows: walk into Kokiri Forest with this PR, expecting no lost device and the log line "ASTC decoded on the CPU" (request to open)
  • An AMD APU (680M, 780M) on Windows: walk into Kokiri Forest with this PR, expecting the GPU decoder as before (no "ASTC decoded on the CPU") and no lost device; if it is lost, RX_VK_ASTC_CPU=1 says whether APUs need the same (request to open)

Screenshots

Nothing on screen beyond the pause as the area loads: the textures are the same ASTC decoded, kept as RGBA8 instead of BC3.

Risk and rollback

  • A pause of about 6 s for each terrain array as an area loads (12 s for Kokiri Forest), on the replay thread. A crash is worse, but it is long.
  • Memory: decoded ASTC as RGBA8 holds 4x what BC3 does (2511 MB against 1242 MB at the same moment here). With less RAM the texture budget of an integrated GPU is smaller, so textures may be evicted and uploaded again (each time another CPU decode).
  • RX_VK_ASTC_CPU=0 restores the GPU decoder; reverting the commit restores main's behaviour.

Reviewer notes

The proper fix is in the upload path: split a big array's decode and re-encode over several submissions (or frames), so that no single submission holds a weak GPU for seconds, and then let these GPUs decode on the GPU again. This PR only keeps the game from crashing on them until then. It replaces #466 (markers before every command), whose last run lost the device all the same: closed.

Issues

See the Kokiri Forest device loss on AMD integrated graphics (#466; no issue on the tracker yet).

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.
  • 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. (Pass/fail over 8 and 3 runs, and each upload's time as logged; main has no frame rate in Kokiri Forest to compare.)
  • 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).
  • Docs updated.
## Why On the graphics built into AMD's desktop CPUs (a Ryzen 9 7900X's Radeon Graphics: 2 CUs, the iGPU of a CPU, not an APU; Windows) the game lost the GPU device (`VK_ERROR_DEVICE_LOST`, then FATAL) within seconds of Kokiri Forest loading in 7 runs of 8. With the ASTC textures decoded on the CPU it loaded Kokiri Forest 4 times of 4 (the last with this PR's own build), at the cost of a pause of about 12 s as the area loads. ## What changed The cause, from the runs' logs: as Kokiri Forest loads, the terrain's two material arrays (1365 x 1365 x 90 layers, 11 levels, ASTC 8x8, 57 MB each) are decoded by the GPU and re-encoded as BC3, one layer and one level at a time. All of it goes into the recording's single upload command buffer: some 2000 dispatches in one submission. On a 2-CU GPU that runs for seconds: in every lost run the game's wait for the GPU took 4-6 s (`nvn: GPU waits in 5 s: 1 sync waits (4176-6305 ms)`) before Windows reset the GPU. Decoded on the CPU, each array took 5.9-6.7 s on the replay thread, and the device was not lost. - ASTC: `astc_on_cpu()` in `gpu/vk/vk_texture.cpp`, asked by `astc_ready()`. `RX_VK_ASTC_CPU` already sent ASTC to the CPU decoder; unset, it is now on, on Windows, for the iGPU of AMD's Ryzen 7000 (Raphael, PCI `0x164E`, the one tested) and Ryzen 9000 (Granite Ridge, `0x13C0`) desktop CPUs: the same 2-CU RDNA 2 part. The APUs' larger iGPUs (680M, 780M, 890M) and every other AMD GPU keep the GPU decoder. `RX_VK_ASTC_CPU=0` gives the GPU decoder back. The switch is read by the switches' rule (`env_value_off`), and the log says when the CPU decodes. - docs: `docs/development.md`, `RX_VK_ASTC_CPU`. - Deliberately unchanged: every other GPU (AMD's APUs and dedicated cards, Intel, NVIDIA, Linux and the Steam Deck) keeps the GPU decoder and BC3. ## Flags and settings | Flag | What it does | Default now | Recommendation | Helps on | Doesn't help on | Untested on | |---|---|---|---|---|---|---| | `RX_VK_ASTC_CPU` (existing; new default) | `1`: ASTC decoded on the CPU, kept as RGBA8. `0`: the GPU decoder, big textures re-encoded as BC3 | Unset: on for the iGPU of AMD's Ryzen 7000 and 9000 desktop CPUs on Windows, off elsewhere | On there: the GPU decoder's submission resets the GPU in Kokiri Forest | Ryzen 9 7900X's Radeon Graphics (Raphael, RDNA 2, 2 CUs), Windows | APUs and dedicated cards: off there, unchanged | Ryzen 9000's iGPU (same part, `0x13C0`); Linux (default off) | ## Measurements main: f804b7b8 (2026-11-14) this PR: fix/amd-igpu-astc-cpu @ 105bb206 Rebased from 9c9d69ed onto f804b7b8 (#385: the build's split of giant lifted functions, no renderer file); the measurements and the run_all numbers are from 9c9d69ed and still hold, the renderer being the same Baseline: main @ f804b7b8. In the game its side is the GPU decoder, this PR's side `RX_VK_ASTC_CPU=1`, both with a renderer built from e072164e (#404's branch: main @ 0caf0618 plus two Intel commits) swapped into one game folder: a renderer from a newer main changes the shader translator and would restart the shader preparation each run. `astc_on_cpu()` is the only change; the code it switches is the same on both bases. Hardware: Ryzen 9 7900X's AMD Radeon(TM) Graphics (RDNA 2, 2 CUs), AMD proprietary driver 26.10.1 (Vulkan driver 0x800161), no mesh shaders (the compute fallback), Windows 11; the screen on an RX 9070 XT, so the iGPU's frames are presented across adapters Scene: New Game or a save, then Kokiri Forest (`map: KokiriForest_Child`); output resolution 2048x1152 Method: played by hand, one Kokiri Forest load per run, until the device was lost or the game was closed; the numbers are lines from each run's `longshot_log.txt`. The checks: `tests/run_all.py` on main and on this PR How to reproduce: on a Ryzen 7000 or 9000 desktop CPU's iGPU on Windows, walk into Kokiri Forest with `RX_VK_ASTC_CPU=0` (main's decoder), then with this PR and no switch | | main @ f804b7b8 (GPU decoder) | this PR @ 105bb206 (`RX_VK_ASTC_CPU=1`) | |---|---|---| | Kokiri Forest loads that lost the device | 7 of 8 | 0 of 4 | | Upload of each terrain array (replay thread) | 29-113 ms to record; the GPU's work then 4-6 s | 5917, 5934, 6084, 6155, 6250, 6414, 6466, 6683 ms | | Textures held once both arrays are made | 1242 MB (325 textures) | 2511 MB (310 textures) | | `tests/run_all.py` | 531 passed, 5 failed, 34 skipped | 531 passed, 5 failed, 34 skipped (the same 5) | The eight runs with the GPU decoder also had other switches (markers, a skipped program, the VRAM mirrors, the issue 817 task shader skipped); none of them kept the device, and the one that did keep it (110 min, markers before every command) uploaded the two arrays at different moments. The three runs with `RX_VK_ASTC_CPU=1` had markers before every command on (a build of the closed #466); markers alone did not keep the device (#466's last run). The fourth is this PR's own build with no switch and no markers: Kokiri Forest loaded, about 28 minutes, no device lost. ``` GPU decoder (RX_VK_CHECKPOINTS=all build, no other switch): [hos BaseProcExecutor5] map: KokiriForest_Child (child) [hos Presentation Thread] vk: big ASTC textures are kept as BC3 (re-encoded on the GPU; ASTC as RGBA8 or RX_VK_ASTC_RGBA8=1: as RGBA8) [hos Presentation Thread] vk: texture 0x10a22aa600 1365x1365x1 x90 levels 11 NVN 0x8e -> vk 137 (ASTC decoded) (324 textures, 1024 MB) [hos Presentation Thread] vk: slow upload 29.4 ms: #337 0x10a22aa600 1365x1365x1 x90 levels 11 NVN 0x8e ASTC (BC3), 57825 of 57825 KB [hos Presentation Thread] vk: texture 0x10a5b22c00 1365x1365x1 x90 levels 11 NVN 0x80 -> vk 137 (ASTC decoded) (325 textures, 1242 MB) [hos sead::MainThread] vk: a capture's wait for write-back 470380 timed out (done 470376) [hos sead::MainThread] nvn: GPU waits in 5 s: 1 sync waits (5468 ms), 0 polls timed out (0 ms), 0 queue finishes (0 ms) [hos Presentation Thread] vk: submit 470388 failed (-4) [hos Presentation Thread] vk: FATAL: the GPU device was lost (VK_ERROR_DEVICE_LOST): the driver stopped or reset the GPU, ... RX_VK_ASTC_CPU=1: [hos Presentation Thread] vk: ASTC not sampled by this GPU: blocks are decoded on upload [hos BaseProcExecutor1] map: KokiriForest_Child (child) [hos Presentation Thread] vk: texture 0x10a22aa600 1365x1365x1 x90 levels 11 NVN 0x8e -> vk 37 (ASTC decoded) (309 textures, 1651 MB) [hos Presentation Thread] vk: slow upload 6083.8 ms: #320 0x10a22aa600 1365x1365x1 x90 levels 11 NVN 0x8e ASTC, 57825 of 57825 KB [hos Presentation Thread] vk: texture 0x10a5b22c00 1365x1365x1 x90 levels 11 NVN 0x80 -> vk 37 (ASTC decoded) (310 textures, 2511 MB) [hos Presentation Thread] vk: slow upload 6250.1 ms: #321 0x10a5b22c00 1365x1365x1 x90 levels 11 NVN 0x80 ASTC, 57825 of 57825 KB (no device lost in any of the three; the third ran 24 minutes, Kokiri Forest in them, and was closed) this PR @ 105bb206's change, no switch: [hos Presentation Thread] vk: ASTC decoded on the CPU (RX_VK_ASTC_CPU=0: by the GPU; on by default for the graphics in AMD's Ryzen 7000 and 9000 desktop CPUs on Windows) run_all.py, failing on both sides (this PC's setup; none reads vk_texture.cpp): test_release, test_oot_state_tap, test_tested_configurations, test_dev_packs, test_walk_key ``` ## Testing **Tested:** On the iGPU above, the twelve Kokiri Forest loads in Measurements, played by hand. `tests/run_all.py` on main and on this PR, Windows 11, llvm-mingw from `nightly-132-5e072fc8`: the same 5 fail on both. `test_env_on` caught the switch read as set-means-on in a first version; it now uses the switches' rule. The renderer (`RX_VK_ONLY`) builds on 9c9d69ed and on e072164e. With no switch, the log on the iGPU says ASTC is decoded on the CPU. This PR's own build with no switch: Kokiri Forest loaded (5934 and 6466 ms for the two arrays) and the game ran about 28 minutes (101760 presents) with no device lost. **Not tested:** Frame rate against main: main loses the device in Kokiri Forest. Hyrule Field and the other areas with the same arrays. A PC with 16 GB of RAM or less (a smaller texture budget, with the arrays at 4x their BC3 size). Ryzen 9000's iGPU (the same 2-CU part, `0x13C0`: on by default, not run) and newer drivers. AMD's APUs are left as they are. A Linux build was not run: the change is standard C++ under `#ifdef _WIN32`, so Linux keeps main's behaviour. **Needs other testers:** - A Ryzen 9000 desktop CPU's iGPU on Windows: walk into Kokiri Forest with this PR, expecting no lost device and the log line "ASTC decoded on the CPU" (request to open) - An AMD APU (680M, 780M) on Windows: walk into Kokiri Forest with this PR, expecting the GPU decoder as before (no "ASTC decoded on the CPU") and no lost device; if it is lost, `RX_VK_ASTC_CPU=1` says whether APUs need the same (request to open) ## Screenshots Nothing on screen beyond the pause as the area loads: the textures are the same ASTC decoded, kept as RGBA8 instead of BC3. ## Risk and rollback - A pause of about 6 s for each terrain array as an area loads (12 s for Kokiri Forest), on the replay thread. A crash is worse, but it is long. - Memory: decoded ASTC as RGBA8 holds 4x what BC3 does (2511 MB against 1242 MB at the same moment here). With less RAM the texture budget of an integrated GPU is smaller, so textures may be evicted and uploaded again (each time another CPU decode). - `RX_VK_ASTC_CPU=0` restores the GPU decoder; reverting the commit restores main's behaviour. ## Reviewer notes The proper fix is in the upload path: split a big array's decode and re-encode over several submissions (or frames), so that no single submission holds a weak GPU for seconds, and then let these GPUs decode on the GPU again. This PR only keeps the game from crashing on them until then. It replaces #466 (markers before every command), whose last run lost the device all the same: closed. ## Issues See the Kokiri Forest device loss on AMD integrated graphics (#466; no issue on the tracker yet). ## 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). - [x] Tested in the game, or what wasn't is named under Testing. - [x] Testing filled in: what was tested, what wasn't, and what needs other testers (with test requests). - [x] Measured: main and this PR at named commits, on the same PC, scene and settings, at least 2 interleaved runs each, the median reported. (Pass/fail over 8 and 3 runs, and each upload's time as logged; main has no frame rate in Kokiri Forest to compare.) - [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] Docs updated.
fix(vk): AMD's integrated GPUs decode ASTC on the CPU, so Kokiri Forest no longer resets the GPU
Some checks failed
PR description / Description follows the template (pull_request_target) Successful in 7s
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
56ae077e0d 
A Ryzen 9 7900X's Radeon Graphics (2 CUs, driver 26.10.1, the screen on another card) lost the device
(VK_ERROR_DEVICE_LOST) within seconds of Kokiri Forest loading in 7 runs of 8. The area's terrain arrays, two
1365 x 1365 x 90 ASTC textures, are decoded by the GPU and re-encoded as BC3 in one upload submission, some 2000
dispatches; the GPU then stood still for 4-6 s before Windows reset it. With RX_VK_ASTC_CPU=1 (decoded on the CPU,
about 6 s an array on the replay thread, the textures kept as RGBA8) it loaded Kokiri Forest 3 times of 3.

astc_on_cpu() in vk_texture.cpp: RX_VK_ASTC_CPU by the switches' rule; unset, on for AMD integrated GPUs on Windows.
docs/development.md: the switch.

Co-Authored-By: Cursor <[email protected]>
Yeetbot90 changed title from WIP: fix(vk): AMD's integrated GPUs decode ASTC on the CPU, so Kokiri Forest no longer resets the GPU to fix(vk): AMD's integrated GPUs decode ASTC on the CPU, so Kokiri Forest no longer resets the GPU 2026-11-14 16:58:37 +00:00
Yeetbot90 commented 2026-11-14 16:58:39 +00:00
Author
Contributor

Tested this PR's own build (56ae077e's change on the game folder's renderer), no switch, no markers, on the Ryzen 9 7900X's Radeon Graphics: the log says ASTC decoded on the CPU, Kokiri Forest loaded (the terrain arrays in 5934 and 6466 ms on the replay thread) and the game ran about 28 minutes (101760 presents) with no device lost. With the GPU decoder 7 of 8 loads lost it; with the CPU decoder 0 of 4. Marked ready.

Tested this PR's own build (56ae077e's change on the game folder's renderer), no switch, no markers, on the Ryzen 9 7900X's Radeon Graphics: the log says `ASTC decoded on the CPU`, Kokiri Forest loaded (the terrain arrays in 5934 and 6466 ms on the replay thread) and the game ran about 28 minutes (101760 presents) with no device lost. With the GPU decoder 7 of 8 loads lost it; with the CPU decoder 0 of 4. Marked ready.
Merge branch 'main' into fix/amd-igpu-astc-cpu
Some checks failed
PR description / Description follows the template (pull_request_target) Successful in 12s
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
d29f8038d8
Yeetbot90 force-pushed fix/amd-igpu-astc-cpu from d29f8038d8
Some checks failed
PR description / Description follows the template (pull_request_target) Successful in 12s
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 dc0b9c05ae
Some checks failed
PR description / Description follows the template (pull_request_target) Successful in 16s
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-14 17:02:31 +00:00 Compare
Yeetbot90 force-pushed fix/amd-igpu-astc-cpu from dc0b9c05ae
Some checks failed
PR description / Description follows the template (pull_request_target) Successful in 16s
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 105bb206c1
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 14s
Details
Website / Website on Cloudflare (pull_request_target) Has been skipped
Details
2026-11-14 17:03:10 +00:00 Compare
Yeetbot90 changed title from fix(vk): AMD's integrated GPUs decode ASTC on the CPU, so Kokiri Forest no longer resets the GPU to fix(vk): the graphics in AMD's desktop CPUs decode ASTC on the CPU, so Kokiri Forest no longer resets the GPU 2026-11-14 17:04:01 +00:00
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 14s
Details
Website / Website on Cloudflare (pull_request_target) Has been skipped
Details
This pull request doesn't have enough approvals yet. 0 of 1 approvals granted.
Some workflows are waiting to be reviewed.
This branch is out-of-date with the base branch
You are not authorized to merge this pull request.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u 'fix/amd-igpu-astc-cpu:Yeetbot90-fix/amd-igpu-astc-cpu'
git switch 'Yeetbot90-fix/amd-igpu-astc-cpu'
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
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
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!489
No description provided.