[naga/wgsl-out]: polyfill inverse function

[chyyran]

Connections

• [msl-out] Decide whether we're going to handle MathFunction::Inverse for matrices  #4330
• Feature Request: Support for Matrix Inverse Function gpuweb/gpuweb#4115
• Using inverse in GLSL appears to cause an issue when parsing resulting WGSL (wgpu v0.8.1) naga#893

Description
inverse is not currently supported by WGSL and might never be. However this leaves shaders that do need these functions fundamentally incompatible with WGSL unless they get polyfilled. This PR allows wgsl-out to emit polyfills for GLSL inverse functions.

The polyfills provided are ported from an old Mesa commit, and have been pre-validated with naga-cli.

outer is not included as part of this patch as it's much more rarer than inverse, and another approach would probably be better. For example SPIRV-Cross just expands the calculation inline.

Pre-emptive support for f16 is included as well. Note that the polyfill files are intentionally not templated to reduce large allocations during shader compilation. This allows InversePolyfill to be 2 ’static pointers and no larger.

Testing
Added an inverse-polyfill.frag test to the in/glsl folder.

This test is then run to validate the changes.

$ cargo test convert_glsl_folder --features="glsl-in,wgsl-out"

Checklist

• Run cargo fmt.
• Run cargo clippy. If applicable, add:
  • --target wasm32-unknown-unknown
  • --target wasm32-unknown-emscripten
• Run cargo xtask test to run tests.
• Add change to CHANGELOG.md. See simple instructions inside file.

[chyyran]

Fixed clippy errors and applied the suggestion from @teoxoy. Will await consensus from @jimblandy before moving forward with whether to keep the flag. I don't mind either way, but the idea to have the flag stemmed from concerns in #4330 where OP seemed to have reservations about the injected polyfill being "quite long".

[jimblandy]

Unless I'm missing something, the polyfill names all need to start with __, a double underscore. A single underscore isn't a reserved prefix (see back::wgsl::Writer::reset's call to Namer::reset), so these injected polyfills could conflict with a definition supplied by the user for _naga_inverse_blah.

[chyyran]

@jimblandy Made the emitted polyfills start with a double underscore and further namespaced them as __naga_polyfill. I've had to add an exception to wgsl-in to allow __naga_polyfill in the lexer otherwise wgsl-out would output WGSL that wgsl-in would reject.

[jimblandy]

@chyyran No, you're right, double underscore isn't something that the code that we generate can define. We should be producing WGSL that other WGSL implementations would accept. Sorry for the bad advice.

I think instead you should change the polyfill names back, so they start with _naga again, and just add "_naga" to the list of reserved prefixes that the WGSL back end passes to Namer::reset. The namer will take care of consistently adjusting any identifiers coming from the naga::Module, so that should just work. Then we can use _naga in the WGSL backend for any future injected stuff.

[chyyran]

@jimblandy dropped the changes to add the double underscore and added _naga to the list of reserved prefixes in Namer in 8309067

[teoxoy]

LGTM, thanks!

[teoxoy]

@chyyran it looks like the snapshots need updating.

[chyyran]

Looks like its sensitive to insertion order. I’ll switch it to use an indexset.

[chyyran]

@teoxoy switched required_polyfills to an indexset in a0a81ac, could you rerun workflows?

concern was addressed