gpuweb / cts

WebGPU Conformance Test Suite
https://gpuweb.github.io/cts/
BSD 3-Clause "New" or "Revised" License
121 stars 72 forks source link

webgpu:shader,execution,expression,call,builtin,bitcast:vec2f_to_vec4h should allow preservation of denormals #3758

Open mwyrzykowski opened 1 month ago

mwyrzykowski commented 1 month ago

In the following test case: https://gpuweb.github.io/cts/standalone/?q=webgpu:shader,execution,expression,call,builtin,bitcast:vec2f_to_vec4h:inputSource=%22uniform%22;alias=false

compiling with a Metal backend using fastMathEnabled = YES, we see the following failure:

(vec2<f32>(NaN.0 (0x7fc00000), NaN.0 (0x7fc00000)))
    returned: vec4<f16>(0.0 (0x0000 subnormal), NaN.0 (0x7fc0), 0.0 (0x0000 subnormal), NaN.0 (0x7fc0))
    expected: [[{ 'f16', [0.0 (0x8000 subnormal)] }],[{ 'f16', [-Infinity,Infinity] }],[{ 'f16', [-19.203125 (0xcccd)] }],[{ 'f16', [-Infinity,Infinity] }]]

However, as_type(0x7fc00000) = { 0x7fc0, 0000 } when fastMathEnabled = YES as denormals and NaNs are not considered.

Should the CTS be updated to allow both expectations @zoddicus ? That seems to be the conclusion from https://github.com/gpuweb/gpuweb/issues/4450

zoddicus commented 1 month ago

I agree the test needs to be updated.

The bitcast tests as-is currently exists outside the numeric framework that does the heavy lifting of taking the union of FTZ or !FTZ paths, so probably is only considering the FTZ path somewhere. I will need to either convert it to use the numeric framework more, or spot fix the bespoke implementation.

I won't be able to address immediately, since I am OOO later this week, but I plan on taking a look when I have time.