WGSL loop
and while
that should behave the same behave differently
#7561
Unanswered
suguruwataru
asked this question in
Q&A
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.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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
u32
is used as a mutex withatomicOr
ing with 1 locking it andatomicAnd
ing with 0 unlocking it:I expect the 2 shaders to do the same thing: each starts 2 threads, and the threads each acquires the lock, add to the
ctr
variable, release the lock, and finish. And in CPU code I check whether thectr
variable actually reaches 2.loop_atomic
does this. However,while_atomic
hangs my computer for several seconds, and in this casectr
is zero when checked in CPU.I'm using
wgpu 25.0.0
and am running on Linux.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
loop
case, not thewhile
case. Each case is written as a test,cargo
is configured to run all the tests with only one thread, and the WGSLwhile
case is#[ignore]
, so one can safely runcargo test
and see how the other cases go. To run thewhile
case, which may make your computer hang,cargo test -- --ignored
.Beta Was this translation helpful? Give feedback.
All reactions