Jim Blandy

It's worth noting that you're taking advantage of the [`unrestricted_pointer_parameters`](https://gpuweb.github.io/gpuweb/wgsl/#language_extension-unrestricted_pointer_parameters) language extension. Without that, you'll break this rule: > Each argument of pointer type to a [user-defined function](https://gpuweb.github.io/gpuweb/wgsl/#user-defined-function) [must](https://gpuweb.github.io/gpuweb/wgsl/#shader-creation-error) have...

If implementing WGSL's division semantics happens to work around this FXC bug, that'd be great. The Naga HLSL back end code implementing the workaround should mention this FXC bug, so...

Even once we fully implement WGSL's semantics for division by zero, there will still be times where wgpu simply can't anticipate what FXC will reject, and we will need to...

WGSL requires that division by zero in a runtime expression returns the left operand (surprising!). Implementing that check should clear this up on FXC, so we're re-purposing this issue to...

I tend to feel the same way as @greggman. But even if we're not enthusiastic proposed solution, we should definitely pay close attention to the problem the OP is complaining...

@jowens One thing you should really do is talk to the WESL people about whether they'd be up for implementing some of these ideas in WESL. We'd like to use...

> My work is entirely in WGSL, however, I must say, and I'm committed to continuing it in WGSL. Since WGSL is a web standard, changes affect an extremely large...

One point to consider is that we have a global limit on the amount of workgroup memory a shader can use, something like 16k. So even if the function's type...

@mwyrzykowski Those optimizations can certainly increase register pressure. I guess if they need to spill temporaries, then they might start consuming workgroup memory as well. But I would expect compilers...

This seems reasonable on the face. I'd like to hear thoughts from others with a lot of experience writing shaders. cc @magcius @mighdoll @greggman @toji