fix(vk): Arc B-series no longer loses the device in Kokiri Forest: float adds are the GPU's own atomic

nyannoying commented

2026-11-14 14:18:04 +00:00

First-time contributor

Why

On an Intel Arc B580 the game loses the GPU device the moment Kokiri Forest comes up after the opening, in every run: a black screen, then the game ends.

What changed

vk: native_fadd_wanted() in gpu/vk/vk_main.cpp now also asks for the GPU's own float atomic add (VK_EXT_shader_atomic_float) by default on the Arc B-series, Battlemage (PCI device 0xE2xx), from Intel's Windows driver 101.9154 on, as it already does for Meteor Lake and Arrow Lake from 101.9175. The comment there says what was run. The log line that names the reason says Battlemage too.
tests: tests/test_native_float_atomic_add.py's table of 42 cases has the B-series ones (on from 101.9154, off on an older driver and on Arc A-series). It fails on main.
docs: the RX_VK_NATIVE_FADD row in docs/development.md.

Flags and settings

Flag	What it does	Default now	Recommendation	Helps on	Doesn't help on	Untested on
`RX_VK_NATIVE_FADD=0/1`	1: the shaders' float adds to storage buffers are the GPU's own atomic; 0: a compare-exchange loop	1 on NVIDIA's driver, on Intel's Windows driver on Meteor Lake and Arrow Lake from 101.9175, and now on Battlemage from 101.9154; 0 elsewhere	On by default on Battlemage	Arc B580 (no device loss entering Kokiri Forest)	—	Arc B570, B580 on other drivers than 101.9154, Arc A-series (unchanged: 0), Battlemage on Linux (unchanged: 0)

Measurements

main: cf605c85 (2026-11-14)
this PR: fix/arc-battlemage-native-fadd @ 2d01cc38
Hardware: Intel Arc B580 12 GB (PCI device 0xE20B), driver 32.0.101.9154; Core i5-13600K; 64 GB; Windows 11 Pro (26100-series Insider, 10.0.29704)
Scene: from the start into the save's Kokiri Forest (child), then standing on Link's balcony; 2048x1152 output, frame generation off
Method: 4 runs, interleaved (main, this PR, main, this PR), the game started and driven through the control bridge each time; the device loss and the frame counts from longshot_log.txt, fps from its vi: ... frames presented (... fps over the last 5.0 s) lines.
How to reproduce: on a B580 start a game and let Kokiri Forest load; RX_VK_NATIVE_FADD=0 gives main's behaviour.

Baseline: main @ cf605c85, the main this was written and run on. The runs were made with 80e0e5ee, this change on cf605c85; the branch has since been rebased onto main 5e072fc8 (2d01cc38) with the same diff plus the log line's wording, and was not run in the game again: native_fadd_wanted() and what reads it did not change between the two mains (git diff cf605c85 5e072fc8 -- gpu/vk/vk_main.cpp is empty), and a build of main 5e072fc8 with only #443's change in it (the replay's, nothing of the float add) still lost the device entering the forest on this card in 4 of 4 starts on 2026-11-14 (those logs were not kept). In all, 191 logged sessions on this card ran with the native add (the work behind #443 among them), none losing the device.

	main @ `cf605c85`	this PR @ `2d01cc38` (run as 80e0e5ee on `cf605c85`)
Device lost entering Kokiri Forest, 2 runs each	2 of 2 (frames 942 and 936)	0 of 2 (3,379 and 3,321 frames, ended by the script)
fps in the forest (5 s windows)	no frame of it	38-45

main1: [hos host] vk: float atomic add on storage buffers: compare-exchange loop, by default only with NVIDIA's driver and Intel's Windows driver on Meteor Lake and Arrow Lake (RX_VK_NATIVE_FADD=1: native where the GPU has it)
main1: [hos Presentation Thread] vi: 898 frames presented (60.0 fps over the last 5.0 s, interval 1)
main1: [hos Presentation Thread] vk: FATAL: the GPU device was lost (VK_ERROR_DEVICE_LOST): the driver stopped or reset the GPU, and nothing sent to it runs any more
main1: [hos Presentation Thread] vk:   stage 0x1: marker 26322 (dispatch of program 499dbfd0721d2858, frame 942)
main2: [hos Presentation Thread] vi: 898 frames presented (60.0 fps over the last 5.0 s, interval 1)
main2: [hos sead::MainThread] vk: FATAL: the GPU device was lost (VK_ERROR_DEVICE_LOST): the driver stopped or reset the GPU, and nothing sent to it runs any more
fadd1: [hos host] vk: float atomic add on storage buffers: native (VK_EXT_shader_atomic_float), Intel's Windows driver, Meteor Lake or Arrow Lake
fadd1 fps: 58.8 60.0 59.8 9.4 33.8 39.9 40.8 40.6 38.4 40.3 39.1 40.1 43.2 43.5 41.8 44.5
fadd2 fps: 58.0 60.3 60.0 15.8 29.6 41.3 44.2 44.9 43.4 44.5 44.5 44.7 44.0 42.9 43.3

(The first three windows of each run are the title and the load; fadd1's reason reads "Meteor Lake or Arrow Lake" because the log line had no word for Battlemage yet, which this PR adds.)

Testing

Tested: Arc B580, 101.9154, Windows 11: the four runs above (files in docs/tested/), and Kokiri Forest stood in and walked through in 191 logged sessions with the native add, none losing the device. python -I -B tests/run_all.py: 485 passed, 6 failed, 70 skipped; the 6 are test_module_ids, test_pad_layout, test_tested_configurations, test_oot_state_tap, test_fpx_sticky and test_spawn_emit, which fail the same way on main 5e072fc8 here. tests/test_native_float_atomic_add.py is skipped by the runner on this PC (no spirv-val); run by hand with SPIRV-Tools v2026.4's spirv-val it passes here and fails on main 5e072fc8.

Not tested: other areas than Kokiri Forest; the Arc B570; other drivers than 101.9154; this PR's rebased head in the game (see Baseline); a Linux build (no Linux compiler on this PC: the change is one condition in native_fadd_wanted() and a log string, so the template's two-platform box is left out, not ticked). With this default a B-series card translates its shaders again once: the float add is part of the program cache's stamp.

Needs other testers:

Arc B570, or a B580 on another driver (101.9175 or newer), Windows: start a game and let Kokiri Forest load, expecting no device loss and float atomic add on storage buffers: native in the log (T-9FES)

Risk and rollback

Only Battlemage cards on Intel's Windows driver 101.9154 or newer change. Their program cache is made again once, because the float add is part of its stamp. RX_VK_NATIVE_FADD=0 keeps the loop; reverting the commit is enough.

Reviewer notes

The gate is the driver that was run, 101.9154, not the 101.9175 the iGPUs use: 101.9154 is what this B580 has, and the extension's add ran right on it in every session since.
Why the loop loses the device on this card is not known; the loop gives up after CAS_LOOP_MAX_TRIES, so a fault in Intel's compiler or a timeout are both possible.
#443 (white shards on the same card) was measured on a build that carries this change, since main alone does not reach the forest there.

Issues

See #343

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.
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 file in docs/tested/ for each new measured run (format in docs/tested-configurations.md; no appended row or assembled view).
A game-free test added for the fix, failing on main and passing here.
Docs updated.

🤖 Generated with Claude Code

## Why On an Intel Arc B580 the game loses the GPU device the moment Kokiri Forest comes up after the opening, in every run: a black screen, then the game ends. ## What changed - vk: `native_fadd_wanted()` in `gpu/vk/vk_main.cpp` now also asks for the GPU's own float atomic add (`VK_EXT_shader_atomic_float`) by default on the Arc B-series, Battlemage (PCI device 0xE2xx), from Intel's Windows driver 101.9154 on, as it already does for Meteor Lake and Arrow Lake from 101.9175. The comment there says what was run. The log line that names the reason says Battlemage too. - tests: `tests/test_native_float_atomic_add.py`'s table of 42 cases has the B-series ones (on from 101.9154, off on an older driver and on Arc A-series). It fails on `main`. - docs: the `RX_VK_NATIVE_FADD` row in `docs/development.md`. ## Flags and settings | Flag | What it does | Default now | Recommendation | Helps on | Doesn't help on | Untested on | |---|---|---|---|---|---|---| | `RX_VK_NATIVE_FADD=0/1` | 1: the shaders' float adds to storage buffers are the GPU's own atomic; 0: a compare-exchange loop | 1 on NVIDIA's driver, on Intel's Windows driver on Meteor Lake and Arrow Lake from 101.9175, and now on Battlemage from 101.9154; 0 elsewhere | On by default on Battlemage | Arc B580 (no device loss entering Kokiri Forest) | — | Arc B570, B580 on other drivers than 101.9154, Arc A-series (unchanged: 0), Battlemage on Linux (unchanged: 0) | ## Measurements main: cf605c85 (2026-11-14) this PR: fix/arc-battlemage-native-fadd @ 2d01cc38 Hardware: Intel Arc B580 12 GB (PCI device 0xE20B), driver 32.0.101.9154; Core i5-13600K; 64 GB; Windows 11 Pro (26100-series Insider, 10.0.29704) Scene: from the start into the save's Kokiri Forest (child), then standing on Link's balcony; 2048x1152 output, frame generation off Method: 4 runs, interleaved (main, this PR, main, this PR), the game started and driven through the control bridge each time; the device loss and the frame counts from `longshot_log.txt`, fps from its `vi: ... frames presented (... fps over the last 5.0 s)` lines. How to reproduce: on a B580 start a game and let Kokiri Forest load; `RX_VK_NATIVE_FADD=0` gives main's behaviour. Baseline: main @ cf605c85, the main this was written and run on. The runs were made with 80e0e5ee, this change on cf605c85; the branch has since been rebased onto main 5e072fc8 (2d01cc38) with the same diff plus the log line's wording, and was not run in the game again: `native_fadd_wanted()` and what reads it did not change between the two mains (`git diff cf605c85 5e072fc8 -- gpu/vk/vk_main.cpp` is empty), and a build of main 5e072fc8 with only #443's change in it (the replay's, nothing of the float add) still lost the device entering the forest on this card in 4 of 4 starts on 2026-11-14 (those logs were not kept). In all, 191 logged sessions on this card ran with the native add (the work behind #443 among them), none losing the device. | | main @ cf605c85 | this PR @ 2d01cc38 (run as 80e0e5ee on cf605c85) | |---|---|---| | Device lost entering Kokiri Forest, 2 runs each | 2 of 2 (frames 942 and 936) | 0 of 2 (3,379 and 3,321 frames, ended by the script) | | fps in the forest (5 s windows) | no frame of it | 38-45 | ``` main1: [hos host] vk: float atomic add on storage buffers: compare-exchange loop, by default only with NVIDIA's driver and Intel's Windows driver on Meteor Lake and Arrow Lake (RX_VK_NATIVE_FADD=1: native where the GPU has it) main1: [hos Presentation Thread] vi: 898 frames presented (60.0 fps over the last 5.0 s, interval 1) main1: [hos Presentation Thread] vk: FATAL: the GPU device was lost (VK_ERROR_DEVICE_LOST): the driver stopped or reset the GPU, and nothing sent to it runs any more main1: [hos Presentation Thread] vk: stage 0x1: marker 26322 (dispatch of program 499dbfd0721d2858, frame 942) main2: [hos Presentation Thread] vi: 898 frames presented (60.0 fps over the last 5.0 s, interval 1) main2: [hos sead::MainThread] vk: FATAL: the GPU device was lost (VK_ERROR_DEVICE_LOST): the driver stopped or reset the GPU, and nothing sent to it runs any more fadd1: [hos host] vk: float atomic add on storage buffers: native (VK_EXT_shader_atomic_float), Intel's Windows driver, Meteor Lake or Arrow Lake fadd1 fps: 58.8 60.0 59.8 9.4 33.8 39.9 40.8 40.6 38.4 40.3 39.1 40.1 43.2 43.5 41.8 44.5 fadd2 fps: 58.0 60.3 60.0 15.8 29.6 41.3 44.2 44.9 43.4 44.5 44.5 44.7 44.0 42.9 43.3 ``` (The first three windows of each run are the title and the load; `fadd1`'s reason reads "Meteor Lake or Arrow Lake" because the log line had no word for Battlemage yet, which this PR adds.) ## Testing **Tested:** Arc B580, 101.9154, Windows 11: the four runs above (files in `docs/tested/`), and Kokiri Forest stood in and walked through in 191 logged sessions with the native add, none losing the device. `python -I -B tests/run_all.py`: 485 passed, 6 failed, 70 skipped; the 6 are `test_module_ids`, `test_pad_layout`, `test_tested_configurations`, `test_oot_state_tap`, `test_fpx_sticky` and `test_spawn_emit`, which fail the same way on main 5e072fc8 here. `tests/test_native_float_atomic_add.py` is skipped by the runner on this PC (no `spirv-val`); run by hand with SPIRV-Tools v2026.4's `spirv-val` it passes here and fails on main 5e072fc8. **Not tested:** other areas than Kokiri Forest; the Arc B570; other drivers than 101.9154; this PR's rebased head in the game (see Baseline); a Linux build (no Linux compiler on this PC: the change is one condition in `native_fadd_wanted()` and a log string, so the template's two-platform box is left out, not ticked). With this default a B-series card translates its shaders again once: the float add is part of the program cache's stamp. **Needs other testers:** - Arc B570, or a B580 on another driver (101.9175 or newer), Windows: start a game and let Kokiri Forest load, expecting no device loss and `float atomic add on storage buffers: native` in the log (T-9FES) ## Risk and rollback Only Battlemage cards on Intel's Windows driver 101.9154 or newer change. Their program cache is made again once, because the float add is part of its stamp. `RX_VK_NATIVE_FADD=0` keeps the loop; reverting the commit is enough. ## Reviewer notes - The gate is the driver that was run, 101.9154, not the 101.9175 the iGPUs use: 101.9154 is what this B580 has, and the extension's add ran right on it in every session since. - Why the loop loses the device on this card is not known; the loop gives up after `CAS_LOOP_MAX_TRIES`, so a fault in Intel's compiler or a timeout are both possible. - https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/443 (white shards on the same card) was measured on a build that carries this change, since main alone does not reach the forest there. ## Issues See https://git.magicbean.dev/MagicBeanDev/Longshot/issues/343 ## 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. - [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 file in `docs/tested/` for each new measured run (format in `docs/tested-configurations.md`; no appended row or assembled view). - [x] A game-free test added for the fix, failing on `main` and passing here. - [x] Docs updated. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

nyannoying added 2 commits

2026-11-14 14:18:04 +00:00

fix(vk): Arc B-series no longer loses the device in Kokiri Forest: float adds are the GPU's own atomic 2d01cc383a

On an Arc B580 (driver 101.9154) the game lost the device on entering Kokiri Forest in every run, in the sky's light
sums (499dbfd0) and 435a0138: float adds to storage buffers run as a compare-exchange loop on Intel's discrete cards.
native_fadd_wanted now asks for VK_EXT_shader_atomic_float's add by default on Battlemage (PCI device 0xE2xx) from
101.9154, as #191 did for Meteor Lake and Arrow Lake. RX_VK_NATIVE_FADD=0 keeps the loop.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

docs(tested): the Battlemage float-add runs on an Arc B580, four files

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 / As their notes say (pull_request) Blocked by required conditions

Details

Third-party parts / The same as upstream (pull_request) Blocked by required conditions

Details

Website / Website on Cloudflare (pull_request) Blocked by required conditions

Details

Website / Website on Cloudflare (pull_request_target) Has been skipped

Details

PR description / Description follows the template (pull_request_target) Successful in 5s

Details

6bc8011756

Co-Authored-By: Claude Fable 5.2 <[email protected]>

mooki added the

labels

2026-11-14 14:18:18 +00:00

nyannoying commented

2026-11-14 14:18:20 +00:00

Author

First-time contributor

The test request is open (T-9FES: an Arc B570, or a B580 on driver 101.9175 or newer) and named in the description; it waits for a maintainer's testing wanted label. #343 looks like the same loss on a B580 with 101.9175, which this gate covers.

The test request is open (T-9FES: an Arc B570, or a B580 on driver 101.9175 or newer) and named in the description; it waits for a maintainer's testing wanted label. https://git.magicbean.dev/MagicBeanDev/Longshot/issues/343 looks like the same loss on a B580 with 101.9175, which this gate covers.

nyannoying changed title from ~~WIP: fix(vk): Arc B-series no longer loses the device in Kokiri Forest: float adds are the GPU's own atomic~~ to fix(vk): Arc B-series no longer loses the device in Kokiri Forest: float adds are the GPU's own atomic

2026-11-14 14:18:22 +00:00

nyannoying referenced this pull request

2026-11-14 14:18:33 +00:00

fix(vk): Arc B580 no longer draws white shards while moving: a part ends only right before a plain draw #443

nyannoying referenced this pull request

2026-11-14 14:18:34 +00:00

fix(vk): Arc B580 no longer draws white shards while moving: a part ends only right before a plain draw #443

nyannoying referenced this pull request

2026-11-14 14:23:55 +00:00

fix(vk): Arc discrete cards no longer lose Kokiri Forest to the sky: uniforms snapshotted on every Intel GPU #446

nyannoying referenced this pull request

2026-11-14 14:24:29 +00:00