> The spec has a semantics that describes that the language does when executed in great detail.
Here's what the WSL specification says about loading a texture, one of the simplest possible features of a shading language, but one that introduces a lot of complexity (again, to load a texture requires calculating an LOD, which requires talking about derivatives and scheduling pixels and shader execution in terms of quads):
> Todo: fill this section Sample, Load, Gather, etc..
That's it.
Now, your Babylon.JS demo clearly samples textures. So you have some semantics implemented, but what semantics are they? Note that these things are baked pretty heavily in hardware, so if you get the semantics wrong, you can't really fix the hardware. Your semantics have to model reality as it exists. Your automated tests can say that the spec is correct, but might break on a real GPU after translation to SPIR-V/Metal/HLSL.
The WebGPU working group does not currently have any participation from AMD or NVIDIA. Khronos and the SPIR-V working group do. I trust them to get these details right.
Fun fact: The current modelling of "discard" of as OpKill instead of OpDemoteToHelperInvocation is incorrect for Metal's "discard", which I presume is one of your backends right now.
> The WebGPU working group does not currently have any participation from AMD or NVIDIA. Khronos and the SPIR-V working group do. I trust them to get these details right.
On the other hand, the SPIR-V working group has no participation from Apple or Microsoft (vendors of relevant platform APIs, relevant shading languages, and in Apple's case, of relevant GPUs).
You might argue that Apple should join the SPIR-V group but you could likewise argue that AMD and Nvidia should join the WebGPU group. After all, their voices would be valuable as to the API and not just the shader language. The barrier to entry to a W3C Community Group is also much lower.
I doubt those vendors really want to retrace their steps to go through the multi-year pain and many committee discussions that brought us SPIR-V, again. Look at all those names on the SPIR-V specification. Do you want to waste all those people's time, again, for that many years?
Here's what the WSL specification says about loading a texture, one of the simplest possible features of a shading language, but one that introduces a lot of complexity (again, to load a texture requires calculating an LOD, which requires talking about derivatives and scheduling pixels and shader execution in terms of quads):
> Todo: fill this section Sample, Load, Gather, etc..
That's it.
Now, your Babylon.JS demo clearly samples textures. So you have some semantics implemented, but what semantics are they? Note that these things are baked pretty heavily in hardware, so if you get the semantics wrong, you can't really fix the hardware. Your semantics have to model reality as it exists. Your automated tests can say that the spec is correct, but might break on a real GPU after translation to SPIR-V/Metal/HLSL.
The WebGPU working group does not currently have any participation from AMD or NVIDIA. Khronos and the SPIR-V working group do. I trust them to get these details right.
Fun fact: The current modelling of "discard" of as OpKill instead of OpDemoteToHelperInvocation is incorrect for Metal's "discard", which I presume is one of your backends right now.