While that is true, it also true that Apple had a major influence on the current design and is e.g. the reason why we got WGSL [0] as a source language instead of a bytecode (a GPU WASM equivalent if you will).
By all accounts, Apple's /only/ stance was that if WebGPU used SPIR-V it would be a non-starter for them, due to ongoing legal issues between Apple and Khronos.
Apple actually proposed WebHLSL in collaboration with Microsoft, to have HLSL be the standard.
Mozilla employee's stance[0] was that SPIRV was too low level, did not fit with the goals of WebGPU portability and security, and expressed concern that Khronos may add functionality to SPIRV they cannot support in WebGPU like raytracing instructions .. 'So we'd always be on the verge of forking SPIR-V in some way.'
It was also noted by many people that even if a bytecode format was used, it would still have to be translated to the target (HLSL/DXIL, MSL, etc.) in almost the same way a text format would.
Nobody proposed a 'GPU WASM equivalent' or an alternative bytecode format, only SPIRV was ever considered AFAIK.
The hard truth is that shader compilation is a fucking nightmare, people do not realize how bad it is across the different native APIs. SPIR-V is good, but it doesn't solve that - and presents other challenges if you are a web browser API. Vulkan and SPIRV are not the golden goose many make them out to be.
[0] https://github.com/gpuweb/gpuweb/issues/847#issuecomment-642...
And exactly, Apple did not want SPIR-V (a bytecode) and proposed WebHLSL (a textual source language) instead. So, I think my statement that Apple preferred a textual format over a bytecode is correct. They could have proposed another bytecode format, but as you noted, nobody did.
It does not really matter anyway, because the GPU hardware and software paradigms are still undergoing rapid change. And there are a whole lot of under-specified things like memory models, scheduling order, control flow uniformity etc. which I expect will take another iteration of standards to be established.
> By all accounts, Apple's /only/ stance was that if WebGPU used SPIR-V it would be a non-starter for them
This is false. Apple's other stance, very strongly stated, was that no binary IR of any kind was acceptable, full stop. Lichtso's original comment is right. Apple explicitly rejected "GPU WASM equivalent or an alternative bytecode format", not just SPIR-V. They would only accept a textual programming language.
Now Apple didn't mandate WGSL, but clearly they wouldn't have accepted GLSL either for their unfortunate legal reasons so that pretty much leaves WHLSL or "new language" as the only options. I don't know why WHLSL ultimately lost. I remember hearing arguments that HLSL as a language was essentially implementation defined rather than rigorously standardized, making it hard to realize any benefit of code portability or reuse from existing codebases.
> I had a chance to work with SPIR-V rather intimately, and I’m becoming convinced that most of the defenders of this format (who like to criticize WGSL in turn) have little experience actually doing anything with it [...] I was one of them. SPIR-V is probably a good format for what it was made for: driver compilers. It’s not as good for the intermediate portable representations of your shaders.
[0] http://kvark.github.io/spirv/2021/05/01/spirv-horrors.html
> Apple's other stance, very strongly stated, was that no binary IR of any kind was acceptable, full stop.
Very strongly stated /where/?
I linked my source, in which kvark clearly stated two things (not as part of his 'devils advocate' position) that directly contradict your claim:
> There is much more to it than just "Apple cannot do X" that often shows up.
> the group agreed to [...] take the semantics of SPIR-V where it makes sense
If there really is a source for it, I'd love to see it (genuinely).
OK, I found what I believe are the most relevant meeting notes [1]. Unfortunately the meeting notes are not a straight transcript and not everything that was said is in there verbatim. There were also side discussions not captured at all. The meeting notes say "Apple would strongly prefer a text-based language to a binary one". This is really an understatement of their position on the matter, and the notes don't capture the most contentious arguments well. But you can at least see in the notes that Apple was arguing strenuously against binary formats generically, even more so than SPIR-V itself in this meeting, going as far as arguing that a hypothetical SPIR-V assembly in text format would be better than SPIR-V in binary form.
[1] https://docs.google.com/document/d/1CmKo59tjZwmePVrFpHpIG0W5...