You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I seem to run into this quite a bit recently. Some for loop is eventually dependant on some uniform (often iTime) and therefore might be an infinite loop. Infinite loops with hard coded values do get compiled away and are not an issue it seems.
since this behaviour isn't going to be changed in wgpu-core, and the uncaptured error isn't captured in wgpu-py this will panic with a "device is lost", after essentially some timeout.
If we want to mimic the behaviour on the website, this should somehow just work. Maybe by skipping the 0th frame or something, if it starts to hang.
I tried to help the compiler by wrapping the uniforms in max(), min() or maybe abs() (since negative numbers in that examples are a problem) - but nothing seems to help.
Using this issue to track changes to the behaviour in the upstream deps and maybe finding a solution someday.
The text was updated successfully, but these errors were encountered:
with 22.1 Vulkan seems to handle some infinite loops (0 increment), but not others(negative).
I will try to figure out what the exact difference is, I suspect it might be the compiler putting in a while True instead.
There is also a translation issue regarding loops, that cause loops to unintentionally become infinite: gfx-rs/wgpu#6208
connection: gfx-rs/wgpu#5926
I seem to run into this quite a bit recently. Some for loop is eventually dependant on some uniform (often iTime) and therefore might be an infinite loop. Infinite loops with hard coded values do get compiled away and are not an issue it seems.
since this behaviour isn't going to be changed in wgpu-core, and the uncaptured error isn't captured in wgpu-py this will panic with a "device is lost", after essentially some timeout.
If we want to mimic the behaviour on the website, this should somehow just work. Maybe by skipping the 0th frame or something, if it starts to hang.
I tried to help the compiler by wrapping the uniforms in
max()
,min()
or maybeabs()
(since negative numbers in that examples are a problem) - but nothing seems to help.Using this issue to track changes to the behaviour in the upstream deps and maybe finding a solution someday.
The text was updated successfully, but these errors were encountered: