Confusing "cannot use `AtomicOrdering::SeqCst` on Vulkan memory model"

[nazar-pc]

I'm getting the following error when trying to use AtomicU32:

  error: cannot use `AtomicOrdering::SeqCst` on Vulkan memory model (check if `AcqRel` fits your needs)
      --> /home/nazar-pc/.rustup/toolchains/nightly-2025-06-23-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/sync/atomic.rs:3984:23
       |
  3984 |             SeqCst => intrinsics::atomic_xadd::<T, { AO::SeqCst }>(dst, val),
       |                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
       |
  note: used from within `core::sync::atomic::atomic_add::<u32>`
      --> /home/nazar-pc/.rustup/toolchains/nightly-2025-06-23-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/sync/atomic.rs:3984:23
       |
  3984 |             SeqCst => intrinsics::atomic_xadd::<T, { AO::SeqCst }>(dst, val),
       |                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  note: called by `<core::sync::atomic::AtomicU32>::fetch_add`
      --> /home/nazar-pc/.rustup/toolchains/nightly-2025-06-23-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/sync/atomic.rs:3748:1
       |
  3748 | / atomic_int! {
  3749 | |     cfg(target_has_atomic = "32"),
  3750 | |     cfg(target_has_atomic_equal_alignment = "32"),
  3751 | |     stable(feature = "integer_atomics_stable", since = "1.34.0"),
  ...    |
  3764 | |     u32 AtomicU32
  3765 | | }
       | |_^
  note: called by `ab_proof_of_space_gpu::shader::find_matches_in_buckets::log_message`
      --> crates/farmer/ab-proof-of-space-gpu/src/shader/find_matches_in_buckets.rs:109:34
       |
  109  |     let write_at = debug_counter.fetch_add(message_length, Ordering::Relaxed);
       |                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The confusing part is that I'm not using SeqCst. Looks like the code that references SeqCst is technically compiled in and causes issues even though it is practically unreachable.

Would have been nice for it to compile successfully.

After above failure I tried spirv_std::arch::atomic_i_add(), which did work, but it has a bit strange syntax due to the need to provide not just ordering semantics, but also scope and it doesn't work on AtomicU32, only on u32. It is also unsafe for some reason.

Ultimately I think the error should say to use spirv_std::arch::atomic_i_add() (because I don't think hiding/guessing scope is a great idea) and spirv_std::arch::atomic_i_add() should support Atomic32, which has the same memory layout as regular u32.

[Firestar99]

rust-gpu TLDR: We don't actually support any of core's Atomics. There's probably some garbage code there that's emitting something which spirv-val doesn't like. You need to use the spirv_std::arch::atomic* functions. The vulkan memory model disallows SeqCst completely and only has Acquire, Release, Relaxed and AcqRel (next to MakeVisible and MakeAvailable, unique to GPUs, don't worry about them).

Some background: Atomics and memory models on graphics cards are a mess. Vulkan originally launched with atomics but without a proper memory model to explain how they actually work. Then they introduced the vulkan memory model back in 2018, and support has only been required since Vulkan 1.3, released 2022. And webgpu just "[...] follows the Vulkan Memory Model".

A properly defined memory model and atomic operations is actually something quite new to shader languages.

A unique thing you can do on GPUs is have an atomic counter be atomic during the execution of one shader, and then use plain loads in the following shader. As wgpu will place appropriate barriers between the two shader dispatches that flushes / invalidates caches, which make the plain read the correct value. In Vulkan you can also run multiple shaders in parallel that all access the same atomic, which isn't possible in wgpu due to it automatically placing the appropriate barriers.

[nazar-pc]

There could be multiple complementary solutions here. Since the error is happening before spirv-opt, it should be possible to correct it to suggest using spirv_std::arch_atomic*() instead.

Separately, it might be possible to change those intriniscs to use core::sync::Atomic* types to further clarify things.

It is clear that current status quo is clearly suboptimal and can/should be improved.