The author list and W3C document are pretty much irrelevant, the actual working group is what counts.
After thinking about it some more, I've come to the conclusion that I've actually not been strong enough in my initial accusation, and that Apple is trying to smother any threat that WebGPU poses to its native App supremacy.
The story is essentially:
Apple wants SPIRV dead.
Mozilla wants SPIRV alive.
Google wants SPIRV alive.
Google developed a human readable text version for SPIRV, which is isomorphic to the binary version, akin to WASM <-> WAT.
Mozilla wants SPIRV, which Apple fully rejects (because of some legal dispute with Chronos, where Apple probably tries to get a patent for something that Chronos has as prior art or something), but they are open to googles proposal of a textural intermediary, which is isomorphic.
Mozilla and Google agree, because they'll all compile down to SPIRV anyways, except for Apple which will target Metal.
This decision is captured in the W3C proposal which to this day contains the Isomorphism property.
That's the Embrace, WGSL is born.
Apple convinces Mozilla and Google that WGSL should be even more human readable, since user readable formats are the backbone of the open web. But for more convenience WGSL will need more features. Extend.
Apple convinces Mozilla and Google that now that the language has grown anyways they should make it much more compatible with other shading languages in general, SPIRV will not be the only target, so while it should be compilable to SPIRV, that's by no means a primary goal. Isomorphism is abandoned. Google tries a last ditch effort to keep the isomorphism with a proposal literally called: "Preserving developer trust via careful conversion between SPIR-V and WGSL".
The proposal is rejected, the working group decides that the isomorphism property will no longer hold (I can only assume malevolence that they haven't removed it from the spec yet, probably to keep dev support.). Extinguished.
Why is that isomorphism so important? Because it's near impossible to develop truly high performance shaders with a load of compiler optimisations between your hardware and your tooling. Apple is successfully giving us GLSL in new clothes, and developers are cheering them on, because they just read the W3C spec and ignore the realities of the standard.
---
Apple: "Having an isolated focus on SPIR-V is not a good perspective, we have MSL etc. to consider too"
...
Apple: "Extreme A is no interaction with SPIRV?, extreme B is very tightly coupled to SPIRV, we should find a middle point"
...
Google: "We take all targets into consideration. We can allow developers do runtime probing and maybe branch according to that. Optimization occurs in existence of uncertainty. Dealing with fuzziness is a fact of life and we should give the tools to developers to determine in runtime."
This is a very inaccurate summary of what happened. And I say this as someone who does not particularly like WGSL. Mozilla, Google and Apple are all working to help design WGSL.
After thinking about it some more, I've come to the conclusion that I've actually not been strong enough in my initial accusation, and that Apple is trying to smother any threat that WebGPU poses to its native App supremacy.
The story is essentially:
Apple wants SPIRV dead. Mozilla wants SPIRV alive. Google wants SPIRV alive.
Google developed a human readable text version for SPIRV, which is isomorphic to the binary version, akin to WASM <-> WAT.
Mozilla wants SPIRV, which Apple fully rejects (because of some legal dispute with Chronos, where Apple probably tries to get a patent for something that Chronos has as prior art or something), but they are open to googles proposal of a textural intermediary, which is isomorphic.
Mozilla and Google agree, because they'll all compile down to SPIRV anyways, except for Apple which will target Metal.
This decision is captured in the W3C proposal which to this day contains the Isomorphism property.
That's the Embrace, WGSL is born.
Apple convinces Mozilla and Google that WGSL should be even more human readable, since user readable formats are the backbone of the open web. But for more convenience WGSL will need more features. Extend.
Apple convinces Mozilla and Google that now that the language has grown anyways they should make it much more compatible with other shading languages in general, SPIRV will not be the only target, so while it should be compilable to SPIRV, that's by no means a primary goal. Isomorphism is abandoned. Google tries a last ditch effort to keep the isomorphism with a proposal literally called: "Preserving developer trust via careful conversion between SPIR-V and WGSL".
The proposal is rejected, the working group decides that the isomorphism property will no longer hold (I can only assume malevolence that they haven't removed it from the spec yet, probably to keep dev support.). Extinguished.
https://docs.google.com/presentation/d/1ybmnmmzsZZTA0Y9awTDU...
Why is that isomorphism so important? Because it's near impossible to develop truly high performance shaders with a load of compiler optimisations between your hardware and your tooling. Apple is successfully giving us GLSL in new clothes, and developers are cheering them on, because they just read the W3C spec and ignore the realities of the standard.
---
Apple: "Having an isolated focus on SPIR-V is not a good perspective, we have MSL etc. to consider too"
...
Apple: "Extreme A is no interaction with SPIRV?, extreme B is very tightly coupled to SPIRV, we should find a middle point"
...
Google: "We take all targets into consideration. We can allow developers do runtime probing and maybe branch according to that. Optimization occurs in existence of uncertainty. Dealing with fuzziness is a fact of life and we should give the tools to developers to determine in runtime."
From https://docs.google.com/document/d/15Pi1fYzr5F-aP92mosOLtRL4...
See also:
https://github.com/gpuweb/gpuweb/pull/599
https://github.com/gpuweb/gpuweb/issues/582
https://github.com/gpuweb/gpuweb/issues/566
http://kvark.github.io/spirv/2021/05/01/spirv-horrors.html
https://github.com/gpuweb/gpuweb/issues/847#issuecomment-642...
https://news.ycombinator.com/item?id=24858172