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
u32is used as a mutex withatomicOring with 1 locking it andatomicAnding 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
ctrvariable, release the lock, and finish. And in CPU code I check whether thectrvariable actually reaches 2.loop_atomicdoes this. However,while_atomichangs my computer for several seconds, and in this casectris zero when checked in CPU.I'm using
wgpu 25.0.0and 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
loopcase, not thewhilecase. Each case is written as a test,cargois configured to run all the tests with only one thread, and the WGSLwhilecase is#[ignore], so one can safely runcargo testand see how the other cases go. To run thewhilecase, which may make your computer hang,cargo test -- --ignored.Beta Was this translation helpful? Give feedback.
All reactions