auberonedu

I just haven't made those pages yet, which is why I don't link to them from anywhere on my site :)

Amusingly, some of this is technically already happening. The shaders pass through downstream compilers that complain if they see what they determine to be a no-op infinite loop. To prove to the compilers that the loop terminates, most WebGPU implementations inject a u64 counter (technically a vec2<u32>) that counts down from u64:MAX and terminates the loop once it reaches 0. But that's such a large amount to count that the WindowServer is long gone. Fun discussion on this PR for wgpu, a Rust implementation of WebGPU: https://github.com/gfx-rs/wgpu/issues/6572

In my testing, a looping compute shader was enough to crash the tab on its own, but it needed waiting render shaders to crash the WindowServer.

Interestingly though there was another way to make only the tab crash, even if I had all three shaders in the pipeline: If I placed the canvas far offscreen using position: absolute, only the tab would crash even if the render shaders were waiting! There's some weird interactions going on I don't yet fully understand.