[SPIR-V] `fma` emits `GLSL.std.450 Fma` instead of `OpFmaKHR`

[kmpeng]

Description
When compiling the HLSL fma intrinsic to SPIR-V, DXC emits the GLSL.std.450 Fma instruction. According to the Vulkan spec, this instruction is not guaranteed to be implemented in hardware as a fused operation. HLSL's fma intrinsic specifically requires fused semantics, so emitting this GLSL instruction does not seem correct. This also appears to be the root cause of this issue in the offload-test-suite. On Intel Vulkan, the driver gives the wrong output for one of the precision sensitive constant-folding cases (though the buffer equivalent case produces the correct result).

The fix for this would be to emit OpFmaKHR from SPV_KHR_fma instead, which guarantees a fused operation. This is also what Clang currently does.

Repro
https://godbolt.org/z/ezEexaGMa

[kmpeng]

@s-perron Here's the issue we talked about earlier

[s-perron]

To use SPV_KHR_fma, we need to enable VK_KHR_shader_fma, which is very recent. The Vulkan extension was released 2025-06-10. It will not be available on many, if any, mobile devices yet. We could add it, but it would have to be under an option, and not the default.

See the GPUInfo for the support for this feature: https://vulkan.gpuinfo.org/displayextensiondetail.php?extension=VK_KHR_shader_fma

[s-perron]

I also don't want to stop using the glsl.std FMA instruction in favour of an emulation because it will cause performance degradation that people are not expecting.

[tex3d]

Right. The HLSL fma() intrinsic was added specifically to target this DXBC operation:
https://microsoft.github.io/DirectX-Specs/d3d/archive/D3D11_3_FunctionalSpec.htm#22.14.7%20dfma

I also don't want to stop using the glsl.std FMA instruction in favour of an emulation because it will cause performance degradation that people are not expecting.

This is not meant to be a general-purpose maybe-fused multiply+add, for that you use mad() (or you can simply use a * b + c without precise). mad() may be fused or not, depending on whatever's fast on the HW. It may or may not use additional precision and/or preserve denorms in intermediates. precise means that it must be exactly the same computation (fused or not) no matter where it's used (can't be split to FMUL+FADD for partial CSE or algebraically rearranged, for instance).

To use SPV_KHR_fma, we need to enable VK_KHR_shader_fma, which is very recent. The Vulkan extension was released 2025-06-10. It will not be available on many, if any, mobile devices yet. We could add it, but it would have to be under an option, and not the default.

Use of this op on D3D requires additional feature support from a device beyond just double support, which only some hardware has: ExtendedDoublesShaderInstructions.

It's not meant to be emulated or produced from optimizations if not explicitly calling HLSL fma(). A shader that uses it can't be created on a device that doesn't support the strict op. It was added for strict needs of scientific computing applications.

The closest fit appears to be the VK_KHR_shader_fma extension.

For glsl.std FMA, you should be translating mad() to that and optimizing regular mul+add to that (if not precise).

[tex3d]

Just as a minor clarification, it appears that D3D12 incorporated ExtendedDoublesShaderInstructions into the base DoublePrecisionFloatShaderOps feature, so any D3D12 device that reports double support must support this instruction. Still, that is a subset of the hardware that supports D3D12, and likely not most consumer hardware nor any mobile hardware.