WGSL built in functions are very under specified

[starmole]

None of the WGSL built in functions specify their edge case behavior.

For a practical example, consider the pow(x,y) function.
What happens with negative values of x?
D3D does a very good job at this: https://learn.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-pow
MSL does not, but has two different functions pow and powr.
T pow(T x, T y) Compute x to the power y.
T powr(T x, T y) Compute x to the power y, where x is >= 0.
via https://developer.apple.com/metal/Metal-Shading-Language-Specification.pdf
In this case, should a wgsl to msl implementation emit pow or powr?

I don't think WGSL should actually specify behavior, but should specify in which cases behavior is undefined - and conversely in which cases it is.

This applies to pretty much all built in functions. Substitute pow with sqrt. Or sin of inf instead of a negative input to sqrt.

[dneto0]

This is very much like #4219

A first step is already in place, relating WGSL's fp edge case behaviours to IEEE 754 exception cases. See https://gpuweb.github.io/gpuweb/wgsl/#floating-point-evaluation
IEEE 754 is already a normative reference.

That said, access to IEEE 754 is behind a paywall, so we still have work to (hopefully captured by #4219) to spell out the various cases.

[dneto0]

I posted an analysis at gpuweb/cts#3549 (review)

The test implements the rule: for pow(a,b):

• fail when a< 0 or (a==0 and b <= 0)

This is the same rule as GLSL.

Also, MSL says for both pow and powr:
"Implemented as exp2(y * log2(x)).
Undefined for x = 0 and y = 0"
Because it uses log2(x) , then x < 0 is disallowed.

HLSL doesn't say anything useful for pow.

WGSL's accuracy table says pow(x,y) accuracy inherits from exp2(y * log2(x)), implying it can be implemented that way. This is in the same spirit as IEEE's powr.

IEEE 754-2018 defines pown, pow, and powr.

• pown: exponent is an integer
• pow exponent y is real, but must agree with pown when y is integral. Domain is [-inf,+inf]x[-inf,+inf]
• powr is implemented as exp( y * log(x)) so domain is [ 0, +inf ] x [-inf, +inf].

So powr is the closest to we have in shader languages.

Taking the intersection of GLSL, MSL, and IEEE powr, we end up using GLSL's rule.

[starmole]

thanks for the update! but i am not sure i understand what failing the test means.
does it mean "undefined behavior", or defined nan?
also the "WGSL's accuracy table says pow(x,y) accuracy inherits from exp2(y * log2(x)), implying it can be implemented that way." is good information!
but part of filing this bug was not having to track down this detail, but to have it spelled out where the pow function is defined.
i would think the HLSL spec at https://learn.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-pow to be "gold standard" here.
when i go to https://www.w3.org/TR/WGSL/#pow-builtin: i get: "Returns e1 raised to the power e2. Component-wise when T is a vector.".

[jimblandy]

This looks like a duplicate of #2765.

[kdashg]

WGSL 2024-04-16 Minutes

• (untriaged)
• KG: 2765 is previous iteration, it's editorial and assigned to KG.
• DN: pow keeps coming up, did shallow dive. Brandon made PR with a rule. Matches GLSL, more strict then MSL, HLSL doesn't say anything. Go with Brandons PR and put that rule into spec. IEEE has 3 power functions this is aligned with inherited accuracy rule. In sense of POW we have an answer. Still editorial of going through list of exception cases in IEEE and writing what it means
• DS: One note, HLSL docs linked from bug has more then version we saw. May want to validate that table with our plan.
• KG: Previous consensus was various things. Would say we do what JS does except when we need to be faster. Later comments say based of IEEE. Assign to dneto?
• DN: Yes.