Repository navigation
Volatile Loads/Stores #513
Description
I'm trying to use volatile loads and stores like so:
#[inline(always)]
pub fn get_item(&self, offset: u32) -> T {
unsafe {
let ptr = self
.items
.get_unchecked(((self.start_ticket + offset) % self.max_capacity) as usize);
core::ptr::read_volatile(ptr)
}
}
#[inline(always)]
pub fn set_item(&mut self, offset: u32, item: T) {
unsafe {
let ptr = self
.items
.get_unchecked_mut(((self.start_ticket + offset) % self.max_capacity) as usize);
core::ptr::write_volatile(ptr, item);
}
}But when compiling I get an error saying this is not supported yet.
error: store_with_flags is not supported yet: MemFlags(VOLATILE)
--> /home/peyton/.rustup/toolchains/nightly-2025-06-30-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ptr/mod.rs:2180:9
|
2180 | intrinsics::volatile_store(dst, src);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^It would be very useful to be able to specify this in loads. It seems like its possible in SPIRV using Memory Operands is there any way to do this currently?
System Info
- SPIR-V: SPIRV-Tools v2025.4 v2025.4-0-g7f2d9ee9
Targets:
SPIR-V 1.0
SPIR-V 1.1
SPIR-V 1.2
SPIR-V 1.3
SPIR-V 1.4
SPIR-V 1.5
SPIR-V 1.6
SPIR-V 1.2 (under OpenCL 2.2 Full Profile semantics)
SPIR-V 1.0 (under Vulkan 1.0 semantics)
SPIR-V 1.3 (under Vulkan 1.1 semantics)
SPIR-V 1.4 (under Vulkan 1.1 semantics)
SPIR-V 1.5 (under Vulkan 1.2 semantics)
SPIR-V 1.6 (under Vulkan 1.3 semantics) SPIR-V 1.6 (under Vulkan 1.4 semantics)
Activity
Firestar99 commentedon Jan 13, 2026
SPIR-V doesn't have an equivalent to volatile. And I do not understand how this would be useful in any way either.
For intra-workgroup communication (within compute shaders) there's shared memory and subgroup ops.
But if you really want cross-workgroup communication, you need to have a look at the Vulkan Memory Model, specifically Acquire, Release, MakeAvailable and MakeVisible, all of which are so rarely used that you won't find any samples for it and likely a lot of driver bugs.
voxelbee commentedon Jan 13, 2026
Ok thanks for the help on MakeAvailable and MakeVisible as that actually fixed my problem. I think reading though the specs I got a bit confused finding volatile within the Memory Operands for loads / stores.
Adding a memory barrier to my code after my writes fixed this bug for me:
I still wonder if it would be possible to define the memory semantics in the load / store operation it's self so I could drop this memory barrier and use
MakePointerVisibleandMakePointerAvailableon the memory operations themselves.Firestar99 commentedon Jan 13, 2026
Probably not anytime soon, there's just too many other basic things to get working first (like
Option...)But it's super interesting to me that you are indeed doing cross-workgroup communication! Cause I've been looking for examples of that online and couldn't find any.
Just be aware for the forward progress guarantee that Vulkan requires of your shader, according to spec you can't be idling infinitely waiting for some other workgroup to send you data, as on a small enough GPU that other workgroup may not spawn due to the resources being occupied by e.g. the waiting workgroup.
voxelbee commentedon Jan 15, 2026
Alright yeah that makes sense. I mean it's working for now so that's good! I'm working on a lock free queue and worker system for the GPU so cross workgroup communication is needed for synchronization. Once I've got it working I'll probably put it up on GitHub so maybe it will be useful to see as a use case with Rust GPU.