Open greggman opened 1 month ago
I don't think that we would want to make a change without SPIR-V also making some sort of change, otherwise we would just push the problem from WebGPU into GLSL compilers, at least for Vulkan, so I'll create a SPIR-V issue to discuss this as well.
In general I'd be in favour of finding some way to improve the definedness of these operations if everyone has implemented them the same way to say WebGPU having to work around the existing limits, but there has to be a high bar for adding functionality to things that have been specced in a particular way for years. We can ask vendors to respond about what their implementations do.
I imagine that if implementations have just followed the spec formula here then they will be fine, except perhaps in the case of x == edge0 == edge1
, which is a particular special case.
The current definition of
smoothstep
isI'm curious if there are actually any GPUs that produce different results for
edge1 <= edge0
. AFAICT, no such GPUs exist as code usingegde1 <= edge0
is ubiquitous.All implementations seem to be effectively
This not undefined for edge1 <= edge0.
If no GPUs actually produce different results when edge1 <= edge0 it would be great to update the spec and tests to make that a requirement. Especially given its ubiquitous use.
As it is, given the spec says it's undefined, the WebGPU spec is trying to help developers avoid this undefined behavior. But, developers are pushing back saying they've been using it for years and have never run into any GPU actually having undefined behavior. As one public example they point out tons of examples on shadertoy use edge1 <= edge0.