Behaviour on M1, M4 and Win

[C0DECYCLE]

Hi, i checked out and ran the demo on both my older M1 and my newer M4 (Pro) Macbook. Both times in Chrome 143 and macOS Tahoe 26.2.

On the M4: Everything works flawless with 120fps and 3-4ms gpu time.
On the M1: Stutter, alternating between running with very few fps and freezing completely. Eventually the GPU crashes and shortly afterwards the entire Mac (kernel panic).

Questions:

• What chip, etc. did you test it on?
• Do you know what might cause this?
• What additional debug infos would you need?

I have the following thoughts on this:

• Not implausible since the M1 chip was the first iteration and the M4 is obviously way more refined
• M4 has better cache coherence(?) and more robust scheduling(?)
• Behaviour could indicate infinite loops / runaway or deadlocks
• Maybe high contention on the M1. Would the now removed backoff help?

PS: Thanks again for the amazing implementation!

Edit: I will try it out later on my windows machine (RTX3080).

Edit2: Weirdly on Win, nothing at all happens, together with a reference warning. See attached screenshot.

Edit3: I successfully ported the queue to an old project of mine and there it works on the M1 too (although very very rare occasional glitches), but i get the same invalid reference warning on Win.

[cryvosh]

Thanks for testing, and glad I could help!

It seems like chrome on windows has some issues with unrestricted_pointer_parameters so I've now just hardcoded the buffer name in queue.wgsl and that seems to have fixed it.

I also initially tested on an m4 pro but saw similar unstable frametimes and crashing when I spawned more threads. I think it has to do with all the idle threads just thrashing the dequeue function when there's not enough work to go around. You can try killing off workgroups after N failed dequeue attempts and this seems to fix the issue, but it's not very elegant as (not for this problem, but in general) you may go through long periods of little work before an explosion of work, at which point you want the threads alive. A better strategy would be to have some sort of exponential backoff where the threads sleep for longer and longer periods after each failed dequeue so that when/if the work explosion happens they'll eventually start helping, but I haven't found a nice way to do this yet in wgsl. Let me know if you think of anything! I just pushed a change that spawns the propagate kernel with 1024 workgroups but only lets the first 256 through in the shader so you can more easily change the effective workgroup count, hot reload the shader (with the q key if you didn't find it), and observe the effects.