WIP: fix(vk): Intel's Windows driver no longer loses the device on float adds to storage buffers: they are the GPU's own atomic #191

Guep · 2026-11-13T12:49:27Z

Guep commented

2026-11-13 12:49:27 +00:00

First-time contributor

Why

On Intel's Meteor Lake iGPU under Windows the game loses the device (VK_ERROR_DEVICE_LOST) in most runs, in compute programs that add floats to storage buffers: 2 of 3 runs of main in this series, both in Kakariko Village, and 12 of 18 runs with the float-add loop over two series; 0 of 6 with this change. On Intel those adds are still a compare-and-swap loop (NotRexed/Hookshot#2306 made the GPU's own float add the default on NVIDIA's driver only, "until someone posts an Arc run in Kakariko and on Death Mountain Trail with RX_VK_NATIVE_FADD=1"): this is that run.

The loop is bounded (it gives up after CAS_LOOP_MAX_TRIES, 1024 attempts), so it cannot spin forever; the likely mechanism is that heavy contention on a few words (the sky's light sums many invocations into one) makes a dispatch long enough to pass Windows' GPU timeout (TDR, 2 s by default) on an iGPU at 5 to 8 fps, and Windows resets the device. One native atomic per add takes that contention out. Of the programs that lost the device, 499dbfd0 is a float add to a storage buffer and ab7699ee likely one; aba5e6af, 435a0138 and 45ab4d73 are not classified, so whether all of them are covered is not shown, only that none lost the device with the native add.

What changed

vk device: native_fadd_wanted (gpu/vk/vk_main.cpp) asks for VK_EXT_shader_atomic_float's shaderBufferFloat32AtomicAdd by default, besides NVIDIA's driver, with Intel's Windows driver (VK_DRIVER_ID_INTEL_PROPRIETARY_WINDOWS) on what it was run on only: the Xe-LPG iGPUs of Meteor Lake and Arrow Lake (PCI device 0x7Dxx; run on a 0x7D55), from driver 101.9175 (Intel's Windows driverVersion, 101 << 14 | 9175). Intel's other GPUs on Windows (Iris Xe and UHD, Arc discrete, Lunar Lake), older drivers, Mesa's Intel driver, AMD and NVK keep the loop. The feature check after it still applies: a GPU that does not report shaderBufferFloat32AtomicAdd keeps the loop. The log line names the driver.
tests: tests/test_native_float_atomic_add.py's table: unset, Intel's Windows driver is native on 0x7Dxx from 101.9175 only (not on 101.9174, nor on a Lunar Lake, Iris Xe, Arc A770 or Battlemage ID); RX_VK_NATIVE_FADD=1 still asks for it on any of them and =0 keeps the loop.
docs: docs/development.md's RX_VK_NATIVE_FADD row.

Flags and settings

Flag	What it does	Default now	Recommendation	Helps on	Doesn't help on	Untested on
`RX_VK_NATIVE_FADD` (default changed)	`1`: float adds to storage buffers are the GPU's own atomic where it has one; `0`: the compare-and-swap loop	`1` with NVIDIA's driver, and Intel's Windows driver from 101.9175 on Meteor Lake and Arrow Lake iGPUs (`0x7Dxx`); `0` elsewhere	On by default where measured: NVIDIA (NotRexed/Hookshot#2306) and Intel's Meteor Lake iGPU on Windows	Intel Arc iGPU (Meteor Lake), Windows; NVIDIA	-	Arrow Lake (same family, default on, not run), Iris Xe and UHD (Tiger Lake, Alder Lake, the Gen9-11 legacy driver), Arc discrete, Lunar Lake, older Intel drivers, Mesa ANV, AMD RDNA 3/4: all keep the loop by default

Measurements

main: 9a186f71 (2026-11-13)
this PR: ls/perf-intel-native-fadd @ c4df9364
Hardware: Lenovo 83DJ; Intel Arc Graphics (Core Ultra 7 155H iGPU, Meteor Lake), driver 32.0.101.9175; Core Ultra 7 155H; 32 GB; Windows 11 Pro (26300)
Scene: a save in Kokiri Forest, then the control bridge's teleport to Kakariko Village and to Death Mountain Trail, about 130 s in each; output 1920x1080, Render resolution 4, handheld profile
Method: 3 runs per side, interleaved with the other Intel PRs' builds (main, split, pcache, fadd, then again), RX_VK_NO_PREDICT=1 on every side; this PR's side in a game folder of its own, since the program cache's stamp holds the float add's choice and its cache differs from main's. Per run and area: the median of the fps over the last 5 s windows (the first 4 after the teleport left out: the load) and of the GPU time ... ms a frame lines in longshot_log.txt; an area counts only with 5 windows or more. The table gives the median over the runs, n the runs that count, and the runs that ended in a device loss, with where
How to reproduce: a save outside Link's house, the options above, RX_VK_NO_PREDICT=1; teleport with the control bridge (cheats: teleport) to Kakariko Village, then Death Mountain Trail, about 130 s each; read the fps and GPU time lines of longshot_log.txt per area

	main @ `9a186f71`	this PR @ `c4df9364`	Δ
Kokiri Forest: fps, median	5.5 (n=3)	5.5 (n=3)	+0.0 fps (0%)
Kokiri Forest: GPU time a frame, median	160.5 ms (n=3)	164.1 ms (n=3)	+3.6 ms (+2%)
Kakariko Village: fps, median	7.4 (n=2)	8.3 (n=3)	+0.9 fps (+12%)
Kakariko Village: GPU time a frame, median	120.4 ms (n=2)	106.3 ms (n=3)	-14.1 ms (-12%)
Death Mountain Trail: fps, median	8.7 (n=1)	9.2 (n=3)	+0.5 fps (+6%)
Death Mountain Trail: GPU time a frame, median	102.0 ms (n=1)	93.9 ms (n=3)	-8.1 ms (-8%)
Runs measured	3	3
Runs that lost the device	2 of 3 (Kakariko Village x2)	0 of 3

Not a performance case: Kokiri Forest is +2 % GPU time, and main's Kakariko (n=2) and Death Mountain Trail (n=1) medians count only the runs that survived, so the fps differences there are not a result. The result is the device losses.

(tools/arm_medians.py over tools/route_report.py, which read the runs' longshot_log.txt)
main    runs 3  kokiri: fps  5.5 gpu  160.5 (n=3) | Kakariko: fps  7.4 gpu  120.4 (n=2) | DeathMou: fps  8.7 gpu  102.0 (n=1)  lost 2/3 n_main2:KakarikoVill n_main3:KakarikoVill
fadd    runs 3  kokiri: fps  5.5 gpu  164.1 (n=3) | Kakariko: fps  8.3 gpu  106.3 (n=3) | DeathMou: fps  9.2 gpu   93.9 (n=3)  lost 0/3

Testing

Tested: Windows 11, Intel Arc iGPU (Meteor Lake): the route above, 3 runs per side in this series, and 3 more in an earlier one on 77f605a2 (same route, same settings). The native add lost the device in 0 of 6 runs; the loop (main and the two other Intel PRs' builds) in 12 of 18. The picture is the same in Kakariko Village and on Death Mountain Trail, captures compared; the flat grey mountainside on Death Mountain Trail shows on main as well, so it is not from this change.

Not tested: Arrow Lake (default on, as the same Xe-LPG family), Iris Xe and UHD on Windows (default off), Arc discrete, Lunar Lake, older Intel drivers, Mesa's Intel driver (its UHD 770 has no buffer float add, per NotRexed/Hookshot#2306), adult Link's places, night.

Needs other testers:

Intel Arc discrete or Lunar Lake, Windows, with RX_VK_NATIVE_FADD=1: Kakariko Village and Death Mountain Trail, 150 s each, expecting the same picture, equal or less GPU time and no device lost, before the default covers them (request to open)
An Iris Xe (Xe-LP) laptop on the current Intel driver, with RX_VK_NATIVE_FADD=1 and =0: the same, and whether the log says the driver reports the float add at all (request to open)

Screenshots

To add: main and this PR at the same spot, from this series' captures.

Risk and rollback

A wrong picture where the light, haze and sky come from these compute programs, if Intel's float add were wrong; none was seen.

The first start after the update, on a Meteor Lake or Arrow Lake iGPU under Windows, is a long one: support_float32_atomic_add is one word of translator_stamp(), so program_cache_stamp() changes for the whole file, and that start drops all of longshot_programs.bin (and its .idx), the prepare's record and, through pcache_drop_stale, mkw_vk_pipelines.bin. Everything is translated and prepared again. That is needed (a program made with OpAtomicFAddEXT must not survive into a loop build, nor the reverse), and the same full reset happens for anyone who toggles RX_VK_NATIVE_FADD. RX_VK_NATIVE_FADD=0 restores the loop; reverting the commit is enough.

Reviewer notes

The device losses were in compute programs 499dbfd0721d2858 (the sky's light, a float add to a storage buffer, from global_memory_to_storage_buffer_pass.cpp), ab7699ee7f536755 (likely a float add too), and aba5e6af8d4683eb, 435a0138b9013040 and 45ab4d73f7099d62, not classified yet; none was lost with the native add.

Issues

See NotRexed/Hookshot#999, NotRexed/Hookshot#2306

Checklist

For everyone

One topic.
The title is a Conventional Commit (type(scope): description).
Rebased on current main. (on fbd42024; measured on 9a186f71 before the rebase)
python -I -B tests/run_all.py run and passing (any failure that also fails on main is named above). (not run on ebaae3e6 yet: stopped for a measurement series; its own check, tests/test_native_float_atomic_add.py, needs spirv-val (Linux), and its source and switch halves pass here)
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). (the test requests are still to open)
Measured: main and this PR at named commits, on the same PC, scene and settings, at least 2 interleaved runs each, the median reported. (fewer than 2 runs that count: main Death Mountain Trail: 1 run)
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).
Screenshots for a change that shows on screen. (to add: main and this PR at the same spot)
A row in docs/tested-configurations.md for each measured run. (none yet in this branch)
A check under tests/ that reads changed source updated in this PR, not weakened.
Host code builds on both Windows (llvm-mingw) and Linux, with UTF-8 paths. (built on Windows only)
Docs updated.

## Why On Intel's Meteor Lake iGPU under Windows the game loses the device (`VK_ERROR_DEVICE_LOST`) in most runs, in compute programs that add floats to storage buffers: 2 of 3 runs of main in this series, both in Kakariko Village, and 12 of 18 runs with the float-add loop over two series; 0 of 6 with this change. On Intel those adds are still a compare-and-swap loop ([NotRexed/Hookshot#2306](https://github.com/NotRexed/Hookshot/pull/2306) made the GPU's own float add the default on NVIDIA's driver only, "until someone posts an Arc run in Kakariko and on Death Mountain Trail with `RX_VK_NATIVE_FADD=1`"): this is that run. The loop is bounded (it gives up after `CAS_LOOP_MAX_TRIES`, 1024 attempts), so it cannot spin forever; the likely mechanism is that heavy contention on a few words (the sky's light sums many invocations into one) makes a dispatch long enough to pass Windows' GPU timeout (TDR, 2 s by default) on an iGPU at 5 to 8 fps, and Windows resets the device. One native atomic per add takes that contention out. Of the programs that lost the device, 499dbfd0 is a float add to a storage buffer and ab7699ee likely one; aba5e6af, 435a0138 and 45ab4d73 are not classified, so whether all of them are covered is not shown, only that none lost the device with the native add. ## What changed - vk device: `native_fadd_wanted` (`gpu/vk/vk_main.cpp`) asks for `VK_EXT_shader_atomic_float`'s `shaderBufferFloat32AtomicAdd` by default, besides NVIDIA's driver, with Intel's Windows driver (`VK_DRIVER_ID_INTEL_PROPRIETARY_WINDOWS`) on what it was run on only: the Xe-LPG iGPUs of Meteor Lake and Arrow Lake (PCI device `0x7Dxx`; run on a `0x7D55`), from driver 101.9175 (Intel's Windows `driverVersion`, `101 << 14 | 9175`). Intel's other GPUs on Windows (Iris Xe and UHD, Arc discrete, Lunar Lake), older drivers, Mesa's Intel driver, AMD and NVK keep the loop. The feature check after it still applies: a GPU that does not report `shaderBufferFloat32AtomicAdd` keeps the loop. The log line names the driver. - tests: `tests/test_native_float_atomic_add.py`'s table: unset, Intel's Windows driver is native on `0x7Dxx` from 101.9175 only (not on 101.9174, nor on a Lunar Lake, Iris Xe, Arc A770 or Battlemage ID); `RX_VK_NATIVE_FADD=1` still asks for it on any of them and `=0` keeps the loop. - docs: `docs/development.md`'s `RX_VK_NATIVE_FADD` row. ## Flags and settings | Flag | What it does | Default now | Recommendation | Helps on | Doesn't help on | Untested on | |---|---|---|---|---|---|---| | `RX_VK_NATIVE_FADD` (default changed) | `1`: float adds to storage buffers are the GPU's own atomic where it has one; `0`: the compare-and-swap loop | `1` with NVIDIA's driver, and Intel's Windows driver from 101.9175 on Meteor Lake and Arrow Lake iGPUs (`0x7Dxx`); `0` elsewhere | On by default where measured: NVIDIA ([NotRexed/Hookshot#2306](https://github.com/NotRexed/Hookshot/pull/2306)) and Intel's Meteor Lake iGPU on Windows | Intel Arc iGPU (Meteor Lake), Windows; NVIDIA | - | Arrow Lake (same family, default on, not run), Iris Xe and UHD (Tiger Lake, Alder Lake, the Gen9-11 legacy driver), Arc discrete, Lunar Lake, older Intel drivers, Mesa ANV, AMD RDNA 3/4: all keep the loop by default | ## Measurements main: 9a186f71 (2026-11-13) this PR: ls/perf-intel-native-fadd @ c4df9364 Hardware: Lenovo 83DJ; Intel Arc Graphics (Core Ultra 7 155H iGPU, Meteor Lake), driver 32.0.101.9175; Core Ultra 7 155H; 32 GB; Windows 11 Pro (26300) Scene: a save in Kokiri Forest, then the control bridge's teleport to Kakariko Village and to Death Mountain Trail, about 130 s in each; output 1920x1080, Render resolution 4, handheld profile Method: 3 runs per side, interleaved with the other Intel PRs' builds (main, split, pcache, fadd, then again), `RX_VK_NO_PREDICT=1` on every side; this PR's side in a game folder of its own, since the program cache's stamp holds the float add's choice and its cache differs from main's. Per run and area: the median of the `fps over the last 5 s` windows (the first 4 after the teleport left out: the load) and of the `GPU time ... ms a frame` lines in `longshot_log.txt`; an area counts only with 5 windows or more. The table gives the median over the runs, n the runs that count, and the runs that ended in a device loss, with where How to reproduce: a save outside Link's house, the options above, `RX_VK_NO_PREDICT=1`; teleport with the control bridge (cheats: teleport) to Kakariko Village, then Death Mountain Trail, about 130 s each; read the fps and GPU time lines of `longshot_log.txt` per area | | main @ 9a186f71 | this PR @ c4df9364 | Δ | |---|---|---|---| | Kokiri Forest: fps, median | 5.5 (n=3) | 5.5 (n=3) | +0.0 fps (0%) | | Kokiri Forest: GPU time a frame, median | 160.5 ms (n=3) | 164.1 ms (n=3) | +3.6 ms (+2%) | | Kakariko Village: fps, median | 7.4 (n=2) | 8.3 (n=3) | +0.9 fps (+12%) | | Kakariko Village: GPU time a frame, median | 120.4 ms (n=2) | 106.3 ms (n=3) | -14.1 ms (-12%) | | Death Mountain Trail: fps, median | 8.7 (n=1) | 9.2 (n=3) | +0.5 fps (+6%) | | Death Mountain Trail: GPU time a frame, median | 102.0 ms (n=1) | 93.9 ms (n=3) | -8.1 ms (-8%) | | Runs measured | 3 | 3 | | | Runs that lost the device | 2 of 3 (Kakariko Village x2) | 0 of 3 | | Not a performance case: Kokiri Forest is +2 % GPU time, and main's Kakariko (n=2) and Death Mountain Trail (n=1) medians count only the runs that survived, so the fps differences there are not a result. The result is the device losses. ``` (tools/arm_medians.py over tools/route_report.py, which read the runs' longshot_log.txt) main runs 3 kokiri: fps 5.5 gpu 160.5 (n=3) | Kakariko: fps 7.4 gpu 120.4 (n=2) | DeathMou: fps 8.7 gpu 102.0 (n=1) lost 2/3 n_main2:KakarikoVill n_main3:KakarikoVill fadd runs 3 kokiri: fps 5.5 gpu 164.1 (n=3) | Kakariko: fps 8.3 gpu 106.3 (n=3) | DeathMou: fps 9.2 gpu 93.9 (n=3) lost 0/3 ``` ## Testing **Tested:** Windows 11, Intel Arc iGPU (Meteor Lake): the route above, 3 runs per side in this series, and 3 more in an earlier one on 77f605a2 (same route, same settings). The native add lost the device in 0 of 6 runs; the loop (main and the two other Intel PRs' builds) in 12 of 18. The picture is the same in Kakariko Village and on Death Mountain Trail, captures compared; the flat grey mountainside on Death Mountain Trail shows on main as well, so it is not from this change. **Not tested:** Arrow Lake (default on, as the same Xe-LPG family), Iris Xe and UHD on Windows (default off), Arc discrete, Lunar Lake, older Intel drivers, Mesa's Intel driver (its UHD 770 has no buffer float add, per [NotRexed/Hookshot#2306](https://github.com/NotRexed/Hookshot/pull/2306)), adult Link's places, night. **Needs other testers:** - Intel Arc discrete or Lunar Lake, Windows, with `RX_VK_NATIVE_FADD=1`: Kakariko Village and Death Mountain Trail, 150 s each, expecting the same picture, equal or less GPU time and no `device lost`, before the default covers them (request to open) - An Iris Xe (Xe-LP) laptop on the current Intel driver, with `RX_VK_NATIVE_FADD=1` and `=0`: the same, and whether the log says the driver reports the float add at all (request to open) ## Screenshots To add: main and this PR at the same spot, from this series' captures. ## Risk and rollback A wrong picture where the light, haze and sky come from these compute programs, if Intel's float add were wrong; none was seen. The first start after the update, on a Meteor Lake or Arrow Lake iGPU under Windows, is a long one: `support_float32_atomic_add` is one word of `translator_stamp()`, so `program_cache_stamp()` changes for the whole file, and that start drops all of `longshot_programs.bin` (and its `.idx`), the prepare's record and, through `pcache_drop_stale`, `mkw_vk_pipelines.bin`. Everything is translated and prepared again. That is needed (a program made with `OpAtomicFAddEXT` must not survive into a loop build, nor the reverse), and the same full reset happens for anyone who toggles `RX_VK_NATIVE_FADD`. `RX_VK_NATIVE_FADD=0` restores the loop; reverting the commit is enough. ## Reviewer notes The device losses were in compute programs 499dbfd0721d2858 (the sky's light, a float add to a storage buffer, from `global_memory_to_storage_buffer_pass.cpp`), ab7699ee7f536755 (likely a float add too), and aba5e6af8d4683eb, 435a0138b9013040 and 45ab4d73f7099d62, not classified yet; none was lost with the native add. ## Issues See [NotRexed/Hookshot#999](https://github.com/NotRexed/Hookshot/issues/999), [NotRexed/Hookshot#2306](https://github.com/NotRexed/Hookshot/pull/2306) ## Checklist ### For everyone - [x] One topic. - [x] The title is a Conventional Commit (`type(scope): description`). - [x] Rebased on current `main`. (on fbd42024; measured on 9a186f71 before the rebase) - [ ] `python -I -B tests/run_all.py` run and passing (any failure that also fails on `main` is named above). (not run on ebaae3e6 yet: stopped for a measurement series; its own check, tests/test_native_float_atomic_add.py, needs spirv-val (Linux), and its source and switch halves pass here) - [x] 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). (the test requests are still to open) - [ ] Measured: main and this PR at named commits, on the same PC, scene and settings, at least 2 interleaved runs each, the median reported. (fewer than 2 runs that count: main Death Mountain Trail: 1 run) - [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). - [ ] Screenshots for a change that shows on screen. (to add: main and this PR at the same spot) - [ ] A row in `docs/tested-configurations.md` for each measured run. (none yet in this branch) - [x] A check under `tests/` that reads changed source updated in this PR, not weakened. - [ ] Host code builds on both Windows (llvm-mingw) and Linux, with UTF-8 paths. (built on Windows only) - [x] Docs updated.

Guep added 1 commit

2026-11-13 12:49:27 +00:00

perf(vk): on Intel's Windows driver float adds to storage buffers are the GPU's own atomic

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

c4df93642b

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

HumanBean requested changes

2026-11-13 16:17:52 +00:00

HumanBean left a comment

The change is small and sits on the existing safe path. native_fadd_wanted only decides whether the native add is asked for. The translator still gets OpAtomicFAddEXT only when VK_EXT_shader_atomic_float is present and shaderBufferFloat32AtomicAdd is reported: dev.float_atomic_add = atomic_float && afloat.shaderBufferFloat32AtomicAdd, and that one feature is enabled at vkCreateDevice. make_profile passes it on as support_float32_atomic_add, and DefineStorageBuffers also requires descriptor aliasing and a shader that uses the add. An Intel Windows GPU that doesn't report the feature keeps the loop. NVIDIA, AMD (proprietary and RADV), Mesa's Intel driver (ANV) and NVK behave exactly as before. The switch check gets its table updated, including RX_VK_NATIVE_FADD=0 on Intel Windows, and nothing in it is weakened. The 0-of-6 against 12-of-18 device-loss evidence is persuasive. The unticked rebase box is honest: main has moved 16 commits (to 1ef93e79) and changed vk_main.cpp and docs/development.md, but not in these hunks.

Must change

The title type should be fix, not perf. The PR exists because Intel loses the device in Kokiri Forest. The evidence is a bug reproduced on main and gone with the change (2/3 and 12/18 runs lost against 0/3 and 0/6), which is CONTRIBUTING's proof for fix. The version bump is the same (both are a patch), but git-cliff files perf under Performance. Intel players looking for the crash in the Fixes section of the v3.0.0-rc notes would miss it. The perf numbers also don't hold up as a perf case. Kokiri Forest is +2% GPU time (worse). Main's Kakariko (n=2) and Death Mountain Trail (n=1) medians count only the runs that survived, because the losses dropped the others. perf also asks for the 1% low and p99, which aren't given. Suggested title: fix(vk): Intel's Windows driver no longer loses the device on float adds to storage buffers: they are the GPU's own atomic. Rename the commit to match, and make "Why" lead with the crash.

Should change

No driver-version or architecture gate, and the largest Intel group is untested. VK_DRIVER_ID_INTEL_PROPRIETARY_WINDOWS covers every Intel GPU on Windows: Arc discrete, Lunar Lake, and also Iris Xe and UHD (Tiger Lake/Alder Lake, plus the Gen9–Gen11 legacy driver branch). Wherever those drivers report shaderBufferFloat32AtomicAdd, the PR turns the native add on with no runs behind it. Only one Meteor Lake iGPU on driver 32.0.101.9175 was tried. The "Untested on" column leaves out Iris Xe and UHD entirely. Either name them and open a test request for at least one Xe-LP laptop on the current driver, or gate the default to what was measured (a minimum driverVersion, or Xe-LPG and later). Say which choice you made, as CONTRIBUTING asks of a new default. I couldn't check which of these drivers report the feature.
The cache cost is described wrongly. The description says "the first start after the update translates the programs that add floats again". In fact support_float32_atomic_add is one word of translator_stamp() (vk_shader.cpp), so program_cache_stamp() changes for the whole file. On Intel Windows the first start drops the entire longshot_programs.bin (and its .idx), the prepare record and, through pcache_drop_stale, mkw_vk_pipelines.bin. Everything is translated and prepared again. That invalidation is correct and needed, since a program carrying OpAtomicFAddEXT must not survive into a loop build, and the reverse. But on the slowest GPUs Longshot supports it means one long first start. Say so in "Risk and rollback". The same full reset happens again for anyone who toggles RX_VK_NATIVE_FADD.
Explain why a bounded loop loses the device. The CAS loop gives up after CAS_LOOP_MAX_TRIES (1024) attempts, so it can't spin forever. The likely mechanism is that heavy contention pushes a dispatch past Windows' TDR timeout on an iGPU running at about 6 fps. One sentence on that in "Why" would tell reviewers the fix targets the cause. It would also show whether the three unclassified programs (aba5e6af…, 435a0138…, 45ab4d73…) are expected to be covered. Small related point: the description says Kokiri Forest, but main's two losses in this series were both in Kakariko Village.
Nit: the new native_fadd_wanted comment adds "an RTX 5080" to the NVIDIA runs. No row in docs/tested-configurations.md or in this PR backs it. Link the run, or drop it.

Still open on the PR's own list: rebase, tests/run_all.py, the test request, screenshots, the tested-configurations rows, and the Linux build (this touches only Windows-relevant behaviour, but vk_main.cpp builds on both).

The change is small and sits on the existing safe path. `native_fadd_wanted` only decides whether the native add is *asked for*. The translator still gets `OpAtomicFAddEXT` only when `VK_EXT_shader_atomic_float` is present and `shaderBufferFloat32AtomicAdd` is reported: `dev.float_atomic_add = atomic_float && afloat.shaderBufferFloat32AtomicAdd`, and that one feature is enabled at `vkCreateDevice`. `make_profile` passes it on as `support_float32_atomic_add`, and `DefineStorageBuffers` also requires descriptor aliasing and a shader that uses the add. An Intel Windows GPU that doesn't report the feature keeps the loop. NVIDIA, AMD (proprietary and RADV), Mesa's Intel driver (ANV) and NVK behave exactly as before. The switch check gets its table updated, including `RX_VK_NATIVE_FADD=0` on Intel Windows, and nothing in it is weakened. The 0-of-6 against 12-of-18 device-loss evidence is persuasive. The unticked rebase box is honest: main has moved 16 commits (to 1ef93e79) and changed `vk_main.cpp` and `docs/development.md`, but not in these hunks. ## Must change 1. **The title type should be `fix`, not `perf`.** The PR exists because Intel loses the device in Kokiri Forest. The evidence is a bug reproduced on main and gone with the change (2/3 and 12/18 runs lost against 0/3 and 0/6), which is CONTRIBUTING's proof for `fix`. The version bump is the same (both are a patch), but git-cliff files `perf` under Performance. Intel players looking for the crash in the Fixes section of the v3.0.0-rc notes would miss it. The perf numbers also don't hold up as a perf case. Kokiri Forest is +2% GPU time (worse). Main's Kakariko (n=2) and Death Mountain Trail (n=1) medians count only the runs that survived, because the losses dropped the others. `perf` also asks for the 1% low and p99, which aren't given. Suggested title: `fix(vk): Intel's Windows driver no longer loses the device on float adds to storage buffers: they are the GPU's own atomic`. Rename the commit to match, and make "Why" lead with the crash. ## Should change 2. **No driver-version or architecture gate, and the largest Intel group is untested.** `VK_DRIVER_ID_INTEL_PROPRIETARY_WINDOWS` covers every Intel GPU on Windows: Arc discrete, Lunar Lake, and also Iris Xe and UHD (Tiger Lake/Alder Lake, plus the Gen9–Gen11 legacy driver branch). Wherever those drivers report `shaderBufferFloat32AtomicAdd`, the PR turns the native add on with no runs behind it. Only one Meteor Lake iGPU on driver 32.0.101.9175 was tried. The "Untested on" column leaves out Iris Xe and UHD entirely. Either name them and open a test request for at least one Xe-LP laptop on the current driver, or gate the default to what was measured (a minimum `driverVersion`, or Xe-LPG and later). Say which choice you made, as CONTRIBUTING asks of a new default. I couldn't check which of these drivers report the feature. 3. **The cache cost is described wrongly.** The description says "the first start after the update translates the programs that add floats again". In fact `support_float32_atomic_add` is one word of `translator_stamp()` (`vk_shader.cpp`), so `program_cache_stamp()` changes for the whole file. On Intel Windows the first start drops the entire `longshot_programs.bin` (and its `.idx`), the prepare record and, through `pcache_drop_stale`, `mkw_vk_pipelines.bin`. Everything is translated and prepared again. That invalidation is correct and needed, since a program carrying `OpAtomicFAddEXT` must not survive into a loop build, and the reverse. But on the slowest GPUs Longshot supports it means one long first start. Say so in "Risk and rollback". The same full reset happens again for anyone who toggles `RX_VK_NATIVE_FADD`. 4. **Explain why a bounded loop loses the device.** The CAS loop gives up after `CAS_LOOP_MAX_TRIES` (1024) attempts, so it can't spin forever. The likely mechanism is that heavy contention pushes a dispatch past Windows' TDR timeout on an iGPU running at about 6 fps. One sentence on that in "Why" would tell reviewers the fix targets the cause. It would also show whether the three unclassified programs (aba5e6af…, 435a0138…, 45ab4d73…) are expected to be covered. Small related point: the description says Kokiri Forest, but main's two losses in this series were both in Kakariko Village. 5. **Nit:** the new `native_fadd_wanted` comment adds "an RTX 5080" to the NVIDIA runs. No row in `docs/tested-configurations.md` or in this PR backs it. Link the run, or drop it. Still open on the PR's own list: rebase, `tests/run_all.py`, the test request, screenshots, the tested-configurations rows, and the Linux build (this touches only Windows-relevant behaviour, but `vk_main.cpp` builds on both).

gpu/vk/vk_main.cpp Outdated

					
				@ -253,3 +253,1 @@

				/// value on); unset, only with NVIDIA's driver, the one the native add was tried on in the game (an RTX 4090 in Kakariko

				/// and on Death Mountain Trail). AMD's RDNA 3 and later and Intel's Arc report the feature too but were not tried: they

				/// keep the loop unless the switch asks, until runs on them say otherwise

				/// value on); unset, with NVIDIA's driver (an RTX 4090 and an RTX 5080 in Kakariko and on Death Mountain Trail) and

Nit: "an RTX 5080" is new here, and no row in docs/tested-configurations.md backs it. Link the run, or drop it.

gpu/vk/vk_main.cpp Outdated

					
				@ -256,3 +256,3 @@

				static bool native_fadd_wanted(const char* env, VkDriverId driver) {

				    if (env) return !env_value_off(env);

				    return driver == VK_DRIVER_ID_NVIDIA_PROPRIETARY;

				    return driver == VK_DRIVER_ID_NVIDIA_PROPRIETARY || driver == VK_DRIVER_ID_INTEL_PROPRIETARY_WINDOWS;

This turns the native add on for every Intel GPU on Windows that reports shaderBufferFloat32AtomicAdd, at any driver version: Iris Xe and UHD (Tiger Lake/Alder Lake, the Gen9-11 legacy branch), Arc discrete and Lunar Lake as well as the one Meteor Lake iGPU measured (32.0.101.9175). The feature check after this keeps it safe where the feature is missing, but none of the GPUs that report it were run besides that one. Either gate it (a minimum driverVersion, or Xe-LPG and later) or name Iris Xe/UHD under Untested and get one test-request run on an Xe-LP laptop.

This turns the native add on for every Intel GPU on Windows that reports `shaderBufferFloat32AtomicAdd`, at any driver version: Iris Xe and UHD (Tiger Lake/Alder Lake, the Gen9-11 legacy branch), Arc discrete and Lunar Lake as well as the one Meteor Lake iGPU measured (32.0.101.9175). The feature check after this keeps it safe where the feature is missing, but none of the GPUs that report it were run besides that one. Either gate it (a minimum `driverVersion`, or Xe-LPG and later) or name Iris Xe/UHD under Untested and get one test-request run on an Xe-LP laptop.

gpu/vk/vk_main.cpp Outdated

					
				@ -508,2 +509,3 @@

				        else logf("vk: float atomic add on storage buffers: %s, %s", how,

				                  fadd_wanted ? "NVIDIA's driver" : "by default only with NVIDIA's driver (RX_VK_NATIVE_FADD=1: native where the GPU has it)");

				                  !fadd_wanted ? "by default only with NVIDIA's and Intel's Windows drivers (RX_VK_NATIVE_FADD=1: native where the GPU has it)"

				                  : fadd_driver.driverID == VK_DRIVER_ID_NVIDIA_PROPRIETARY ? "NVIDIA's driver" : "Intel's Windows driver");

Fine: with RX_VK_NATIVE_FADD unset, fadd_wanted can only be NVIDIA or Intel Windows, so the else-branch naming Intel is exact. Worth knowing: switching the default flips translator_stamp()'s float_add word, so on Intel Windows the first start after the update drops the whole program cache and mkw_vk_pipelines.bin (pcache_drop_stale), not only "the programs that add floats" as the description says. That's correct, but on these iGPUs it is one long first start: say so under Risk.

Fine: with RX_VK_NATIVE_FADD unset, `fadd_wanted` can only be NVIDIA or Intel Windows, so the else-branch naming Intel is exact. Worth knowing: switching the default flips `translator_stamp()`'s float_add word, so on Intel Windows the first start after the update drops the whole program cache and mkw_vk_pipelines.bin (pcache_drop_stale), not only "the programs that add floats" as the description says. That's correct, but on these iGPUs it is one long first start: say so under Risk.

HumanBean added this to the v3.0.0 milestone

2026-11-13 16:28:47 +00:00

HumanBean added the

testing wanted

label

2026-11-13 16:51:07 +00:00

Guep force-pushed perf-intel-native-fadd from c4df93642b

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 ebaae3e659

CI / Workflow lint (actionlint) (pull_request) Blocked by required conditions

Details

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

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

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

Details

2026-11-13 18:40:54 +00:00

Compare

Guep changed title from ~~WIP: perf(vk): on Intel's Windows driver float adds to storage buffers are the GPU's own atomic~~ to WIP: fix(vk): Intel's Windows driver no longer loses the device on float adds to storage buffers: they are the GPU's own atomic

2026-11-13 18:41:18 +00:00

Guep referenced this pull request

2026-11-13 18:41:30 +00:00

WIP: fix(vk): on Intel iGPUs a split submission's uniform updates are written by its last part #189

Guep referenced this pull request

2026-11-13 18:41:31 +00:00

WIP: fix(vk): on Intel iGPUs a split submission's uniform updates are written by its last part #189

Guep commented

2026-11-13 18:41:46 +00:00

First-time contributor

Thank you. Rebased on fbd42024; the changes are in 9cb92cde and ebaae3e6.

Type. The title and the commit are fix now, and "Why" leads with the device losses, with the right place: Kakariko Village, where main's two losses of this series were.
Gate. Narrowed to what was run, as the person I work for asked of a new default: Intel's Windows driver on the Xe-LPG iGPUs of Meteor Lake and Arrow Lake (PCI device 0x7Dxx; the run was on a 0x7D55), from driver 101.9175 (101 << 14 | 9175, the encoding the log's driver 0x1963d7 confirms). Iris Xe and UHD, Arc discrete, Lunar Lake and older drivers keep the loop and are named under Untested; a test request for an Xe-LP laptop on the current driver is listed. The table covers 101.9174, Lunar Lake, Iris Xe, A770 and Battlemage IDs. Arrow Lake is on by family, not by a run: say if you would rather leave it out.
Cache cost. "Risk and rollback" and the switch's row now say the first start drops the whole program cache, the prepare's record and mkw_vk_pipelines.bin, and that toggling the switch does the same.
Why a bounded loop loses the device. One paragraph in "Why": contention likely pushes a dispatch past Windows' GPU timeout on an iGPU at 5 to 8 fps; it says too that three of the programs are not classified, so their coverage is shown only by the runs.
RTX 5080. Dropped.

Still to do before pr ready: the test requests, screenshots, the tested-configurations rows, a Linux build.

tests/run_all.py not run on ebaae3e6 yet (stopped for a measurement series); the check's source and switch halves pass here, the SPIR-V half needs spirv-val.

Thank you. Rebased on fbd42024; the changes are in 9cb92cde and ebaae3e6. 1. **Type.** The title and the commit are `fix` now, and "Why" leads with the device losses, with the right place: Kakariko Village, where main's two losses of this series were. 2. **Gate.** Narrowed to what was run, as the person I work for asked of a new default: Intel's Windows driver on the Xe-LPG iGPUs of Meteor Lake and Arrow Lake (PCI device `0x7Dxx`; the run was on a `0x7D55`), from driver 101.9175 (`101 << 14 | 9175`, the encoding the log's `driver 0x1963d7` confirms). Iris Xe and UHD, Arc discrete, Lunar Lake and older drivers keep the loop and are named under Untested; a test request for an Xe-LP laptop on the current driver is listed. The table covers 101.9174, Lunar Lake, Iris Xe, A770 and Battlemage IDs. Arrow Lake is on by family, not by a run: say if you would rather leave it out. 3. **Cache cost.** "Risk and rollback" and the switch's row now say the first start drops the whole program cache, the prepare's record and `mkw_vk_pipelines.bin`, and that toggling the switch does the same. 4. **Why a bounded loop loses the device.** One paragraph in "Why": contention likely pushes a dispatch past Windows' GPU timeout on an iGPU at 5 to 8 fps; it says too that three of the programs are not classified, so their coverage is shown only by the runs. 5. **RTX 5080.** Dropped. Still to do before `pr ready`: the test requests, screenshots, the tested-configurations rows, a Linux build. `tests/run_all.py` not run on ebaae3e6 yet (stopped for a measurement series); the check's source and switch halves pass here, the SPIR-V half needs spirv-val.

HumanBean referenced this pull request

2026-11-13 18:57:15 +00:00

WIP: fix(vk): on Intel iGPUs a split submission's uniform updates are written by its last part #189

HumanBean reviewed

2026-11-13 18:57:19 +00:00

HumanBean left a comment

Re-review at ebaae3e6. Code only: I didn't build it, run the tests or run the game.

Earlier points:

Type perf → fix: addressed. The title and both commits are fix, and "Why" now leads with the device losses, in Kakariko Village.
Gate: addressed. The default is now Intel's Windows driver on PCI device 0x7Dxx from 101.9175 only. I checked both halves:
- The mask: (device & 0xFF00u) == 0x7D00u is exactly 0x7D00–0x7DFF. That range is Meteor Lake (0x7D40, 0x7D45, 0x7D55, 0x7D60, 0x7DD5) and Arrow Lake (0x7D41, 0x7D51, 0x7D67, 0x7DD1), and as far as I know nothing else. Lunar Lake (0x64xx), Iris Xe (0x9Axx/0x46xx), Arc A-series (0x56xx) and Battlemage (0xE2xx) all fall outside it. The vendor isn't checked, but VK_DRIVER_ID_INTEL_PROPRIETARY_WINDOWS already implies Intel.
- The version: Intel's Windows driverVersion is 18.14 bits (build in the low 14). 101 << 14 | 9175 = 1663959 = 0x1963d7, which matches the run's log. The comparison is parenthesised, so >= doesn't bind before |. 9175 fits in 14 bits. Older branches (100.x, 30.0.100.x) compare lower, and a later major compares higher. dev.props is filled in pick_device before create_device reads it.
- The table covers 101.9174, a much older build, Lunar Lake, Iris Xe, A770 and Battlemage IDs (all the loop), plus =1 on Iris Xe and =0 on the measured GPU. Iris Xe/UHD are now named under Untested, with a test request planned.
- You asked about Arrow Lake: keeping it is fine with me. ARL-U/S are the same Xe-LPG IP and ARL-H is Xe-LPG+, on the same driver, and it is named as untested.
Cache cost: addressed. "Risk and rollback" and the docs/development.md row both say the first start, and any toggle of the switch, empty the whole program cache and mkw_vk_pipelines.bin.
Why a bounded loop loses the device: addressed. The TDR paragraph is in "Why". It says honestly that the three unclassified programs are covered only by the runs.
RTX 5080 nit: addressed. It's gone.

New since then:

The log line's three branches are exact. With the switch unset, fadd_wanted is true only for NVIDIA's driver or the gated Intel case.
The rebase is fine. main has moved 9 commits past fbd42024. Of the files this touches, only docs/development.md changed there, in a hunk away from the RX_VK_NATIVE_FADD row. No shaders or *_spv.h are touched.
Nit (inline): one comment line in create_device is now 155 columns, followed by a two-word line. Re-wrap it. The test's docstring has the same kind of break ("NVK); set," / "RX_VK_NATIVE_FADD").

Verdict: comment, not changes. The code is right and every earlier point is settled. Before pr ready:

tests/run_all.py on ebaae3e6 (or CI's run on it).
One game start on ebaae3e6 (not c4df9364). The measured runs predate the gate, so paste the vk: float atomic add on storage buffers: native ..., Intel's Windows driver, Meteor Lake or Arrow Lake line, to show the gate fires on the real deviceID/driverVersion.
The two test requests opened and linked under Testing.
Screenshots.
The docs/tested-configurations.md rows.
The Linux build box.
The Measured box. My reading is that it holds: 3 interleaved runs a side at named commits, with medians. main's n=1 on Death Mountain Trail is the device loss itself, which is the result. Tick it with that note, or add runs.

Re-review at ebaae3e6. Code only: I didn't build it, run the tests or run the game. Earlier points: 1. **Type `perf` → `fix`:** addressed. The title and both commits are `fix`, and "Why" now leads with the device losses, in Kakariko Village. 2. **Gate:** addressed. The default is now Intel's Windows driver on PCI device `0x7Dxx` from 101.9175 only. I checked both halves: - The mask: `(device & 0xFF00u) == 0x7D00u` is exactly `0x7D00`–`0x7DFF`. That range is Meteor Lake (`0x7D40`, `0x7D45`, `0x7D55`, `0x7D60`, `0x7DD5`) and Arrow Lake (`0x7D41`, `0x7D51`, `0x7D67`, `0x7DD1`), and as far as I know nothing else. Lunar Lake (`0x64xx`), Iris Xe (`0x9Axx`/`0x46xx`), Arc A-series (`0x56xx`) and Battlemage (`0xE2xx`) all fall outside it. The vendor isn't checked, but `VK_DRIVER_ID_INTEL_PROPRIETARY_WINDOWS` already implies Intel. - The version: Intel's Windows `driverVersion` is 18.14 bits (build in the low 14). `101 << 14 | 9175` = 1663959 = `0x1963d7`, which matches the run's log. The comparison is parenthesised, so `>=` doesn't bind before `|`. 9175 fits in 14 bits. Older branches (100.x, 30.0.100.x) compare lower, and a later major compares higher. `dev.props` is filled in `pick_device` before `create_device` reads it. - The table covers 101.9174, a much older build, Lunar Lake, Iris Xe, A770 and Battlemage IDs (all the loop), plus `=1` on Iris Xe and `=0` on the measured GPU. Iris Xe/UHD are now named under Untested, with a test request planned. - You asked about Arrow Lake: keeping it is fine with me. ARL-U/S are the same Xe-LPG IP and ARL-H is Xe-LPG+, on the same driver, and it is named as untested. 3. **Cache cost:** addressed. "Risk and rollback" and the `docs/development.md` row both say the first start, and any toggle of the switch, empty the whole program cache and `mkw_vk_pipelines.bin`. 4. **Why a bounded loop loses the device:** addressed. The TDR paragraph is in "Why". It says honestly that the three unclassified programs are covered only by the runs. 5. **RTX 5080 nit:** addressed. It's gone. New since then: - The log line's three branches are exact. With the switch unset, `fadd_wanted` is true only for NVIDIA's driver or the gated Intel case. - The rebase is fine. main has moved 9 commits past fbd42024. Of the files this touches, only `docs/development.md` changed there, in a hunk away from the `RX_VK_NATIVE_FADD` row. No shaders or `*_spv.h` are touched. - Nit (inline): one comment line in `create_device` is now 155 columns, followed by a two-word line. Re-wrap it. The test's docstring has the same kind of break ("NVK); set," / "RX_VK_NATIVE_FADD"). Verdict: comment, not changes. The code is right and every earlier point is settled. Before `pr ready`: - `tests/run_all.py` on ebaae3e6 (or CI's run on it). - One game start on ebaae3e6 (not c4df9364). The measured runs predate the gate, so paste the `vk: float atomic add on storage buffers: native ..., Intel's Windows driver, Meteor Lake or Arrow Lake` line, to show the gate fires on the real `deviceID`/`driverVersion`. - The two test requests opened and linked under Testing. - Screenshots. - The `docs/tested-configurations.md` rows. - The Linux build box. - The Measured box. My reading is that it holds: 3 interleaved runs a side at named commits, with medians. main's n=1 on Death Mountain Trail is the device loss itself, which is the result. Tick it with that note, or add runs.

gpu/vk/vk_main.cpp

					
				@ -268,2 +271,3 @@

				    if (env) return !env_value_off(env);

				    return driver == VK_DRIVER_ID_NVIDIA_PROPRIETARY;

				    if (driver == VK_DRIVER_ID_NVIDIA_PROPRIETARY) return true;

				    return driver == VK_DRIVER_ID_INTEL_PROPRIETARY_WINDOWS && (device & 0xFF00u) == 0x7D00u && version >= (101u << 14 | 9175u);

Checked: the mask is exactly 0x7D00-0x7DFF, which is Meteor Lake and Arrow Lake only. 101u << 14 | 9175u is 0x1963d7 in Intel's 18.14 encoding and matches the run's log. The parentheses keep >= from binding before |. Good.

Checked: the mask is exactly 0x7D00-0x7DFF, which is Meteor Lake and Arrow Lake only. `101u << 14 | 9175u` is 0x1963d7 in Intel's 18.14 encoding and matches the run's log. The parentheses keep `>=` from binding before `|`. Good.

gpu/vk/vk_main.cpp

					
				@ -357,2 +361,2 @@

				    // spirv_emit_context.cpp DefineStorageBuffers). By default with NVIDIA's driver only (native_fadd_wanted);

				    // RX_VK_NATIVE_FADD=1 asks for it on any GPU, =0 keeps the loop on every one, the extension not even enabled

				    // spirv_emit_context.cpp DefineStorageBuffers). By default with NVIDIA's driver, and Intel's Windows driver on the

				    // Meteor Lake and Arrow Lake iGPUs (native_fadd_wanted); RX_VK_NATIVE_FADD=1 asks for it on any GPU, =0 keeps the loop on every one, the extension not

Nit: this line is 155 columns, and the next one is just "even enabled". Re-wrap the comment.

CI / Workflow lint (actionlint) (pull_request) Blocked by required conditions

Details

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

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

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

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 'perf-intel-native-fadd:Guep-perf-intel-native-fadd'

git switch 'Guep-perf-intel-native-fadd'

Sign in to join this conversation.

No reviewers

No milestone

No project

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!191

Rows
Columns