smoothstep: is it an error when `low == high` and/or `low > high` (when constant/pipline-evaluated)
amaiorano opened this issue · comments
See smoothstep where we define how the result is computed:
For scalar T, the result is t * t * (3.0 - 2.0 * t), where t = clamp((x - low) / (high - low), 0.0, 1.0).
If low == high, this results in a divide by 0. Should this be an error at constant/pipeline-evaluation time?
If low > high, there is no DBZ, but perhaps we should consider erroring for that case as well? Does it make sense to use smoothstep with low > high?
The GLSL extended instruction SmoothStep returns an undefined (indeterminate in WGSL) value if edge0 >= edge1 (i.e. low >= high in WGSL). Metal has the same caveat (also if any input is NaN). HLSL doesn't seem to say.
From that, I'd be inclined to make it an error in early evaluation.
WGSL 2024-04-30 Minutes
- KG: In underlying APIs this is UB. We promise portable runtime behavior, the question here is how constant evaluation should proceed: polyfill, or report an error, or a warning
- AB: evaluation errors would be consistent with other builtins. This seems like a spec bugfix.
- DN: GLSL goes out of its way to say you shouldn’t do this
- RESOLVED: MODULE-CREATION-TIME ERROR