I'll start off by sharing why I'm excited about SPIR-V:
There's much more incentive for people to write SPIR-V backends and compilers for existing languages than yet another hacky transpiler to an arbitrary, opinionated high level graphics shader language that may or may not be around long and only works in the web browser.
SPIR-V could very soon make it possible to more or less directly use libraries from existing language ecosystems. When I'm doing a project that needs GPU acceleration, I definitely want to tap into existing libraries! Especially existing math/science libraries. I don't want Apple to tell me what high level language constructs I should need to get stuff done. I would much prefer instead to start with a high level language that has good application specific libraries already written, documented, tested and refined.
A personal example: I dream of GPU accelerated sparse Clifford Algebra computations. Clifford Algebra is amazing, but writing an efficient Clifford Algebra library is hard work. I don't want to wait around for some slow, mediocre Clifford Algebra library written in WSL or HLSL. I also don't really want to write one myself. I want to use one that's already written in e.g. C++, Python, Rust, Haskell or Julia. As a bonus, I could use it in combination with other libraries in that language's ecosystem. SPIR-V could make this real.
As for Apple, I use the word "sabotage" because I've seen those PR blog posts Apple put out as well as some pretty cringy w3 gpuweb meeting notes. To be clear, I'm not trying to point fingers at individual developers or Apple users. I just don't like how Apple as a corporation has engaged the w3 process so far. That blog post would make it sound like Apple is leading the working group and presenting sensible decisions, when really there isn't consensus that people want a high level shader language that Apple designed and conveniently already has tooling for. What they didn't acknowledge until later is that because of a private IP dispute they're mostly just reluctant to work with Khronos directly, and appear to have some high level Apple legal aversion to Vulkan/SPIR-V. Rather than being up front about that, they went and made a whole new language that they claim everyone will love, and effectively launched a minor PR campaign against SPIR-V.
From my point of view, many of the arguments in the blog post you shared are just not convincing. A few seem downright disingenuous.
Take this quote for example:
> "However, that turned out not to be true; Asm.js, which is JavaScript source, is still faster than WebAssembly for many use cases".
But in the link they share to back that up, we basically see that Safari's WebAssembly implementation is slow. So that means bytecode might not be more performant than asm.js/high level language in certain cases? No, Safari is just slow.
I think that the most honest argument against SPIR-V in that post is the one in favor of using a high level, more human friendly language so that people can see what a shader does. I definitely understand why people buy that one and think it's a fair point. I used to feel the same way about WebAssembly, until I realized that WebAssembly would allow people to leverage existing language ecosystems in writing stuff for the web. From where I stand, that's way more human friendly.
As far as security goes: it's also completely possible to write obfuscated or misleading code in a high level language like WSL. Similarly, with the right tooling and a little practice, it's very possible to understand what IR bytecode does.
> "The language needs to be well-specified."
SPIR-V is extremely well specified, and well specified on a hardware level. It's like the most well specified. I just don't understand that argument. It's tricksy. Later on they're talking about how there isn't a web execution environment yet for SPIR-V. Well yeah, if Apple would just get onboard, that's what the working group would sit down and figure out. They'd have to do that anyway with their high level shading language _and_ duplicate the effort of SPIR-V in specifically coming up with a list of low level features that work for vulkan/metal/directx.
There's plenty of evidence that on a strategic level, Apple just isn't a big fan of cross platform tooling (or cross-platform anything for that matter). Vulkan has potential to be a real and useful cross platform GPU/TPU/accelerator API, and might pull loyal developers away from Apple's proprietary APIs. Apple is and has been all about vendor and platform lock-in for the longest time. I would know. At one point in time, I had subscription to Mac Addict magazine. In quitting the Mac, I battled through the all the annoying ways that Apple kept me locked into the platform. They do the same thing with developers.
> MS (Apple): Apple is not comfortable working under Khronos IP framework, because of dispute between Apple Legal & Khronos which is private. Can’t talk about the substance of this dispute. Can’t make any statement for Apple to agree to Khronos IP framework. So we’re discussing, what if we don’t fork? We can’t say whether we’re (Apple) happy with that.
> NT (Khronos): nobody is forced to come into Khronos’ IP framework.
Apple shares feedback from developer outreach they did:
There's much more incentive for people to write SPIR-V backends and compilers for existing languages than yet another hacky transpiler to an arbitrary, opinionated high level graphics shader language that may or may not be around long and only works in the web browser.
SPIR-V could very soon make it possible to more or less directly use libraries from existing language ecosystems. When I'm doing a project that needs GPU acceleration, I definitely want to tap into existing libraries! Especially existing math/science libraries. I don't want Apple to tell me what high level language constructs I should need to get stuff done. I would much prefer instead to start with a high level language that has good application specific libraries already written, documented, tested and refined.
A personal example: I dream of GPU accelerated sparse Clifford Algebra computations. Clifford Algebra is amazing, but writing an efficient Clifford Algebra library is hard work. I don't want to wait around for some slow, mediocre Clifford Algebra library written in WSL or HLSL. I also don't really want to write one myself. I want to use one that's already written in e.g. C++, Python, Rust, Haskell or Julia. As a bonus, I could use it in combination with other libraries in that language's ecosystem. SPIR-V could make this real.
As for Apple, I use the word "sabotage" because I've seen those PR blog posts Apple put out as well as some pretty cringy w3 gpuweb meeting notes. To be clear, I'm not trying to point fingers at individual developers or Apple users. I just don't like how Apple as a corporation has engaged the w3 process so far. That blog post would make it sound like Apple is leading the working group and presenting sensible decisions, when really there isn't consensus that people want a high level shader language that Apple designed and conveniently already has tooling for. What they didn't acknowledge until later is that because of a private IP dispute they're mostly just reluctant to work with Khronos directly, and appear to have some high level Apple legal aversion to Vulkan/SPIR-V. Rather than being up front about that, they went and made a whole new language that they claim everyone will love, and effectively launched a minor PR campaign against SPIR-V.
From my point of view, many of the arguments in the blog post you shared are just not convincing. A few seem downright disingenuous.
Take this quote for example:
> "However, that turned out not to be true; Asm.js, which is JavaScript source, is still faster than WebAssembly for many use cases".
But in the link they share to back that up, we basically see that Safari's WebAssembly implementation is slow. So that means bytecode might not be more performant than asm.js/high level language in certain cases? No, Safari is just slow.
I think that the most honest argument against SPIR-V in that post is the one in favor of using a high level, more human friendly language so that people can see what a shader does. I definitely understand why people buy that one and think it's a fair point. I used to feel the same way about WebAssembly, until I realized that WebAssembly would allow people to leverage existing language ecosystems in writing stuff for the web. From where I stand, that's way more human friendly.
As far as security goes: it's also completely possible to write obfuscated or misleading code in a high level language like WSL. Similarly, with the right tooling and a little practice, it's very possible to understand what IR bytecode does.
> "The language needs to be well-specified."
SPIR-V is extremely well specified, and well specified on a hardware level. It's like the most well specified. I just don't understand that argument. It's tricksy. Later on they're talking about how there isn't a web execution environment yet for SPIR-V. Well yeah, if Apple would just get onboard, that's what the working group would sit down and figure out. They'd have to do that anyway with their high level shading language _and_ duplicate the effort of SPIR-V in specifically coming up with a list of low level features that work for vulkan/metal/directx.
There's plenty of evidence that on a strategic level, Apple just isn't a big fan of cross platform tooling (or cross-platform anything for that matter). Vulkan has potential to be a real and useful cross platform GPU/TPU/accelerator API, and might pull loyal developers away from Apple's proprietary APIs. Apple is and has been all about vendor and platform lock-in for the longest time. I would know. At one point in time, I had subscription to Mac Addict magazine. In quitting the Mac, I battled through the all the annoying ways that Apple kept me locked into the platform. They do the same thing with developers.
---
Some relevant GPU Web meeting notes
Someone named Tom discovers WSL:
https://docs.google.com/document/d/1BOvJKklz-4PZN2StCU56nN4m...
Apple people make their case for WSL:
https://docs.google.com/document/d/1CmKo59tjZwmePVrFpHpIG0W5...
https://docs.google.com/document/d/1opv8MIK94DNIKU5qbgeqlkkT...
The GPU Web group prepares for a meeting with the Khronos laison:
https://docs.google.com/document/d/1RI5hgOFuOH0-v9MPxuoV6w2L...
The GPU Web group meets with the Khronos laison:
https://docs.google.com/document/d/1F6ns6I3zs-2JL_dT9hOkX_25...
An interesting detail here:
> MS (Apple): Apple is not comfortable working under Khronos IP framework, because of dispute between Apple Legal & Khronos which is private. Can’t talk about the substance of this dispute. Can’t make any statement for Apple to agree to Khronos IP framework. So we’re discussing, what if we don’t fork? We can’t say whether we’re (Apple) happy with that.
> NT (Khronos): nobody is forced to come into Khronos’ IP framework.
Apple shares feedback from developer outreach they did:
https://docs.google.com/document/d/14XlLIyNjcxRr2WQCIdwufxy9...