3 ms·

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

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). [0]: https://www.w3.org/TR/WGSL/ https://www.w3.org/TR/WGSL/

slimsag 3y ago
People keep spreading this incredibly misleading statement - god knows I do not like Apple's closed-source behavior, but at this point people are basically just spreading lies about the situation 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-642883924 https://github.com/gpuweb/gpuweb/issues/847#issuecomment-642...
- Lichtso 3y ago
  I might have expressed myself in an ambiguous and extravagated way, just to be clear, I was not complaining about WGSL. I actually do like it a little better than GLSL and HLSL, though it still leads to more standards / fragmentation. 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.
- modeless 3y ago
  What you linked was a "devil's advocate" position from kvark, not his balanced personal opinion. At this point the decision against SPIR-V was already made and he was not trying to get anyone to change their minds back. > 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.
  - slimsag 3y ago
    What he wrote was not just a devils advocate position. I encourage everyone to read it in full. Also his 'Horrors of SPIR-V' article a year later[0] which has this conclusion: > 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 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).
    - modeless 3y ago
      Clearly neither of those two things directly contradict my claim that Apple refused binary formats. It's weird that you would even say that. My source is I was in the meetings where Apple refused binary IR. Man, you're going to make me look up the meeting notes, aren't you? 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/1CmKo59tjZwmePVrFpHpIG0W5shKR_GOrnNuMStPCEko/edit https://docs.google.com/document/d/1CmKo59tjZwmePVrFpHpIG0W5...

slimsag 3y ago

People keep spreading this incredibly misleading statement - god knows I do not like Apple's closed-source behavior, but at this point people are basically just spreading lies about the situation 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-642883924 https://github.com/gpuweb/gpuweb/issues/847#issuecomment-642...

Lichtso 3y ago
I might have expressed myself in an ambiguous and extravagated way, just to be clear, I was not complaining about WGSL. I actually do like it a little better than GLSL and HLSL, though it still leads to more standards / fragmentation. 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.
modeless 3y ago
What you linked was a "devil's advocate" position from kvark, not his balanced personal opinion. At this point the decision against SPIR-V was already made and he was not trying to get anyone to change their minds back. > 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.
- slimsag 3y ago
  What he wrote was not just a devils advocate position. I encourage everyone to read it in full. Also his 'Horrors of SPIR-V' article a year later[0] which has this conclusion: > 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 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).
  - modeless 3y ago
    Clearly neither of those two things directly contradict my claim that Apple refused binary formats. It's weird that you would even say that. My source is I was in the meetings where Apple refused binary IR. Man, you're going to make me look up the meeting notes, aren't you? 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/1CmKo59tjZwmePVrFpHpIG0W5shKR_GOrnNuMStPCEko/edit https://docs.google.com/document/d/1CmKo59tjZwmePVrFpHpIG0W5...