feature: Parse enable directives & SHADER-F16 support

[FL33TW00D]

Resolves #5476.
Resolves #4384.

• Test multiple redundant directives (I think there may be a cleaner way to do this: https://github.com/gfx-rs/wgpu/pull/5701/files#diff-9ef835ffc5f7d7313243db5bfa371d3115b82c0705d4f1df75c98dfe07d927a1R2175)
• MSL out
• HLSL out
• SPV out
• Arbitrary for F16 on half-rs: feature: Arbitrary starkat99/half-rs#111. Currently we are using a git dep on my fork which is causing CI to fail.
• hexf_parse f16 support: https://github.com/lifthrasiir/hexf. This one won't be fun. Did some work on it here: lifthrasiir/hexf@master...FL33TW00D:hexf:feature/f16 .

References:
F16 is available in >=SM6.2: https://github.com/microsoft/DirectXShaderCompiler/wiki/16-Bit-Scalar-Types

[FL33TW00D]

I've marked this as ready for review, as the wgpu specific logic is implemented and would be great to start iterating on it.

2 main blockers are:

1. Merging of the PR on half-rs.
2. hexf-parse improved implementation.

[FL33TW00D]

Dogfooding works! Fixed a few bugs in 30e12b5. Still waiting on upstream.

[teoxoy]

We don't use this field at all, we might in the future but I think it will end up looking differently. Extensions and language extensions can be bitflags, and global diagnostic modifiers will have their own shapes.

I think we should either remove this field or replace it with an extensions bitflags.

[teoxoy]

Could you squash all the existing commits into 1? It will make it easier to look at the PR once the feedback is addressed.

[FL33TW00D]

Could you squash all the existing commits into 1? It will make it easier to look at the PR once the feedback is addressed.

@teoxoy 100% - thanks for the review let me address and squash!

[teoxoy]

One thing I'm concerned is that the polyfills we have in some of the backends might not support f16. It would be worth adding more tests covering the built-in functions and operations that support f16. Execution tests would be great as well, they live in tests/tests/shader.

[teoxoy]

It would be best for review to squash first so that the commits addressing various parts are by themselves.

[ErichDonGubler]

I have not reviewed this PR in-depth as @teoxoy has, but the broad strokes of the const. eval code look correct to me, FWIW. 🫡

[FL33TW00D]

@teoxoy not actually sure about this now.
gpuweb/gpuweb#2512 (comment)
Seems some of these are optional. If you enable them all you lose most devices on Vulkan.

[teoxoy]

What ended up in the spec requires all of the Vulkan features. Some more context from the follow-up meetings:
gpuweb/gpuweb#2512 (comment)
gpuweb/gpuweb#2512 (comment)

[teoxoy]

@FL33TW00D please request a re-review once ready.

[FL33TW00D]

@FL33TW00D please request a re-review once ready.

@teoxoy will do apologies this got deprioritised.

[teoxoy]

No worries, I just want to make sure to get back to it.

[tgross35]

Would it be feasible, either here or in a followup, to support the builtin f16 as an alternative to half? It is still unstable so needs to be behind a feature gate, but it would be great to start working it into the ecosystem and help us find more bugs.

Bytemuck just needs its nightly_float feature enabled to support it.

[teoxoy]

The buffers are all just a bunch of bytes, so you can use whichever type you want then put it in the buffer. The usage of half is internal to naga.

[FL33TW00D]

Taking a look at this again @teoxoy on a rented EC2 machine to check Vulkan.
Seems like the NVDA Vulkan driver doesn't seem to allow F16 (which seems off):

HAS SHADER FLOAT16: Some((PhysicalDeviceShaderFloat16Int8Features { s_type: PHYSICAL_DEVICE_SHADER_FLOAT16_INT8_FEATURES, p_next: 0x7ffdc4f00a68, shader_float16: 1, shader_int8: 1, _marker: PhantomData<&()> }, PhysicalDevice16BitStorageFeatures { s_type: PHYSICAL_DEVICE_16BIT_STORAGE_FEATURES, p_next: 0x7ffdc4f00af8, storage_buffer16_bit_access: 1, uniform_and_storage_buffer16_bit_access: 1, storage_push_constant16: 1, storage_input_output16: 0, _marker: PhantomData<&()> }))

This is because the storage_input_output16 is 0.

https://forums.developer.nvidia.com/t/nvidia-driver-should-enable-the-storageinputoutput16-feature/275835

Any ideas here? I'd expect a T4 to offer this?

EDIT:
wow turns out Turing didn't even support f16 and it isn't a bug.

Nvidia Turing-based hardware currently [reports support](https://vulkan.gpuinfo.org/displayreport.php?id=6907#extended) for shaderFloat16, shaderInt8, storageBuffer16BitAccess, uniformAndStorageBuffer16BitAccess, and storagePushConstant16, but not storageInputOutput16

[teoxoy]

It is possible to use FP16 in user-defined pipeline input/output variables. However some Vulkan devices, which support other usages in this extension like FP16 built-in function and storage buffer, don’t support this usage. For capabilities reasons, we may suggest not enabling using FP16 as pipeline input or output with this extension. However, this usage can also be emulated on Vulkan devices with no native support for this usage (storageInputOutput16).

from gpuweb/gpuweb#2512

I think we have to do the casting ourselves. Dawn also seems to do this. We can do it in a different PR though.

What I find interesting is that the proposal talked about SM6.2 & Native16BitShaderOpsSupported enabling support for f16 IO, I guess the Nvidia compiler that ingests DXIL will do the casting. It probably does the casting regardless of frontend and that's why people report this working on Vulkan as well despite storageInputOutput16 not being supported. While it's unlikely this will change we shouldn't rely on this behavior.