WGSL loop and while that should behave the same behave differently
#7561
-
|
I'm not familiar with synchronization yet so I'm not sure whether it's WGSL being weird or I'm having wrong expectations. A friendly warning that running the test code below may make your computer hang. Consider these compute shaders, where an atomic var<workgroup> lock: atomic<u32>;
@group(0) @binding(0)
var<storage, read_write> ctr: u32;
@compute @workgroup_size(2, 1, 1)
fn loop_atomic(@builtin(global_invocation_id) id: vec3u) {
loop {
if atomicOr(&lock, 1u) == 1u { continue; }
ctr++;
atomicAnd(&lock, 0u);
break;
}
}
@compute @workgroup_size(2, 1, 1)
fn while_atomic(@builtin(global_invocation_id) id: vec3u) {
while atomicOr(&lock, 1u) == 1u { }
ctr++;
atomicAnd(&lock, 0u);
}I expect the 2 shaders to do the same thing: each starts 2 threads, and the threads each acquires the lock, add to the I'm using I've put my testing code here: https://github.com/suguruwataru/wgsl-loop. I also tried to recreate the logic in Rust in the testing code. They work like the |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
|
So there's actually a couple problems here. It's actually impossible to write a working mutex in wgsl for two reasons:
Then there's control flow issues which I think are causing your problem:
|
Beta Was this translation helpful? Give feedback.
So there's actually a couple problems here. It's actually impossible to write a working mutex in wgsl for two reasons: