[webgpu] Let vectorized binary op return an overridable value on NaN #7198
Conversation
This is like 2c95a67 [webgpu] Further tweak vectorized NaN handling in binary ops but for `valueForNaN`.
| const opFnStr = ` | ||
| fn binaryOperation(a : ${dType}, b : ${dType}) -> ${dType} { | ||
| let isNaN = false; | ||
| let valueForNaN = uniforms.NAN; |
There was a problem hiding this comment.
The op returns booleans, even for NaN operands. I think that's by design.
(Well, the doc says nothing about this, it's just explicitly checked in the unit tests. Another mess is that currently this is defined in NOT_EQUAL, but not in EQUAL!)
There was a problem hiding this comment.
So do you think if uniforms.NAN is good enough for a default value? I'm not sure if we have more cases like (NOT_)EQUAL.
There was a problem hiding this comment.
I can't see any reason that we use let valueForNaN = 1.0; for NOT_EQUAL_VEC4. For WebGL, there is no NaN check for NotEqual.
So my opinion is we directly use uniforms.NAN in CHECK_NAN_SNIPPET_VEC4. And don't need to define an additional variable valueForNaN.
There was a problem hiding this comment.
- WGSL implementations may assume that NaNs and infinities are not present at runtime. In such an implementation, when an expression evaluation would produce an infinity or a NaN, an indeterminate value of the target type is produced instead. So, I feel explicit checks are necessary.
- We want
i32(valueForNaN)to evaluate to 1/true later, buti32(uniforms.NAN)is 0/false.
3 participants
This is like
2c95a67 [webgpu] Further tweak vectorized NaN handling in binary ops
but for
valueForNaN.To see the logs from the Cloud Build CI, please join either our discussion or announcement mailing list.
This change is