metal: Set preserveInvariance for shader options

[scoopr]

This fixes, for example, depth prepass resulting in ever so slightly
different depth values for later render passes.

Connections
BVE-Reborn/rend3#317

Description
By default, metal enables "fastMath" optimizations for shaders, which may result in ever so slightly values for, for example depth, or other values. Setting the preserveInvariance pessimizes this for vertex shader locations, so that depth prepasses work consistently.

Testing
With rend3 examples

[scoopr]

Not sure what the webgpu spec says about these accuracy issues, but I'm guessing that disabling fastMath itself shouldn't be needed, but preserveInvariance makes sense at least as a default, as it is a portability issue.

[kvark]

First the user code is expected to put [[invariant]] on the position output for this to be portable.
Honestly, my preference was to just force it unconditionally, but the group wanted it to be optional.
Then, given [[invariant]] the implementations are expected to do the thing, but MSL doesn't universally support it, so it becomes an unofficial best-effort scenario.

That is to say, I'm fully on board with calling set_preserve_invariance whenever it's available.

[scoopr]

Ah, so the "right" way to do it, is to add [[invariant]] to the position in the wgsl, and that should percolate to [[invariant]] in msl, invariant in glsl, the decorator in spirv, and I guess precise in hlsl?

But I suppose it is not currently doing that in naga?

[kvark]

Right, unfortunately. Filed gfx-rs/naga#1659 to follow-up.

[scoopr]

I actually thought the [[invariant]] would replace the need for the preserveInvariance setting, but I just now took another look at the msl spec

This calculation is now
guaranteed to be invariant when passing -fpreserve-invariance option or setting the
preserveInvariance on the MTLCompilerOptions from the Metal API for runtime
compilation. Note that [[invariant]] is ignored if the options are not passed.

So, it needs both the flag and the decoration? But just the option still seems to fix the issues? I don't get it?

Also for the older versions, it says

Compilers prior to IOS 14.0 and macOS 11.0,
the calculation is likely (although not guaranteed) to be invariant.

[kvark]

Compilers prior to IOS 14.0 and macOS 11.0,
the calculation is likely (although not guaranteed) to be invariant.

Oh fun! I wonder if it's a new edit.

Anyway, looks like a mess, but we should proceed with the same plan. I.e. we'll always set preserveInvariance on the host side, and shaders may or may not have [[invariant]] spewed in them.

[scoopr]

Cleaned out the possibly misleading comment. Ok now?

[kvark]

Nice!

[kvark]

published in wgpu-hal-0.12.3