SPIR-V: a fallback for GlobalAtomicAddF32 at an untracked global address #598

Merged
Joey-Magnus merged 1 commit from fix/global-atomic-add-f32 into main 2026-11-08 16:49:22 +00:00
Joey-Magnus commented 2026-11-08 13:54:47 +00:00 (Migrated from github.com)

OoT's compute program 499dbfd0721d2858 did not translate on main (a598b9f):

vk: program 499dbfd0721d2858 not translated: SPIR-V Instruction is not implemented (GlobalAtomicAddF32) is not implemented

The float add's address isn't tracked to a storage buffer, and unlike the 32-bit integer atomics, GlobalAtomicAddF32 had no fallback.

Change (SPIR-V back end only): EmitGlobalAtomicAddF32 now calls a DontInline helper built like the integer atomics' fallbacks. It searches the storage buffers by address, then the page table where stores follow it (gp_level >= 3). It computes the sum in a compare-exchange loop, as the storage buffers' f32_add_cas does, and each attempt expects the word the previous exchange returned. When nothing holds the address it returns 0.0 and stores nothing.

Tested on an RTX 4070 Ti (NVIDIA 595.99.02), Ubuntu 26.04, Linux build:

  • RX_VK_PREPARE_AGAIN=1: the program translates. The 6 failures left on this branch are ATOMG.CAS, fixed separately in #597. With both branches together, the run prepares all 31985 programs with 0 failures.
  • RX_VK_DUMP_SPV: this program's SPIR-V and the other 3812 dumped in that run all pass spirv-val --target-env vulkan1.3 --scalar-block-layout.
  • tests/test_global_atomic_add_f32.py (added to source-regressions) fails on main and passes here.

I didn't find which effect this program drives, so this shows it now translates and is valid SPIR-V, not a visible change.

Assisted-by: Claude Opus 5.5

OoT's compute program 499dbfd0721d2858 did not translate on `main` (a598b9f): ``` vk: program 499dbfd0721d2858 not translated: SPIR-V Instruction is not implemented (GlobalAtomicAddF32) is not implemented ``` The float add's address isn't tracked to a storage buffer, and unlike the 32-bit integer atomics, `GlobalAtomicAddF32` had no fallback. **Change** (SPIR-V back end only): `EmitGlobalAtomicAddF32` now calls a `DontInline` helper built like the integer atomics' fallbacks. It searches the storage buffers by address, then the page table where stores follow it (`gp_level >= 3`). It computes the sum in a compare-exchange loop, as the storage buffers' `f32_add_cas` does, and each attempt expects the word the previous exchange returned. When nothing holds the address it returns 0.0 and stores nothing. **Tested** on an RTX 4070 Ti (NVIDIA 595.99.02), Ubuntu 26.04, Linux build: - `RX_VK_PREPARE_AGAIN=1`: the program translates. The 6 failures left on this branch are `ATOMG.CAS`, fixed separately in #597. With both branches together, the run prepares all 31985 programs with 0 failures. - `RX_VK_DUMP_SPV`: this program's SPIR-V and the other 3812 dumped in that run all pass `spirv-val --target-env vulkan1.3 --scalar-block-layout`. - `tests/test_global_atomic_add_f32.py` (added to source-regressions) fails on `main` and passes here. I didn't find which effect this program drives, so this shows it now translates and is valid SPIR-V, not a visible change. Assisted-by: Claude Opus 5.5
Commenting is not possible because the repository is archived.
No description provided.