What about WGSL though, the shader language of WebGPU? WebGPU is kind of Vulkan lite, but unlike with Vulkan, Apple is on board and actually the reason why WGSL exists as yet another shading language.
What about it? Nobody wanted WGSL, it's just an artifact of having to appease Apple during WebGPUs development as you say. I don't see why it would be adopted for anything else.
The old WebGPU meeting notes have some choice quotes from (IIRC) Unity and Adobe engineers literally begging the committee not to invent a new shader language.
>The old WebGPU meeting notes have some choice quotes from (IIRC) Unity and Adobe engineers literally begging the committee not to invent a new shader language.
This was an interesting tidbit, so I tried to find the source for it. While I did not find it, I did find the December 2019 minutes[0] which has a related point:
>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.
I found this link via rust hn[1] which I found after reading this blog post:[2]
>Vulkan used a bytecode, called SPIR-V, so you could target it from any shader language you wanted. WebGPU was going to use SPIR-V, but then Apple said no
The lobsters thread also links to a relevant HN post:[3]
>I know, I was there. I also think that objection to SPIR-V wasn't completely unfounded. SPIR-V is a nice binary representation of shaders, but it has problems in the context of WebGPU adoption: It's so low level [...] It has a lot of instructions [...] Friction in the features we need, vs features Khronos needs. [...] there is no single well specified and tested textual shading language. HLSL doesn't have a spec.
The linked blog post from lobsters was also discussed on HN, which you also commented in.[4]
It would be great if you could find that Unity/Adobe discussion as I would be interested to read it.
Corentin: Web Shading Language — A high-level shading language made by Apple for WebGPU.
<room in general grimaces>
[...]
Jesse B (Unity): We care about HLSL
Eric B (Adobe): Creating a new high level language is a cardinal sin. Don’t. Do. That. Don’t want to rewrite all my shaders AGAIN.
Jesse B: If we can transcode to HLSL to whatever you need, great. If we can’t, we may not support your platform at all.
Eric B: Would really not like even to write another transcoder. If there’s an existing tool to get to an intermediate representation, that’s good. Would suggest SPIRV is an EXCELLENT existing intermediate representation.
Note the WSL language made by Apple which sparked that discussion is unrelated to the WGSL language they ended up shipping, but the sentiment that the ISV representatives just wanted them to use HLSL or SPIR-V stands.
Ah, that explains part of why I couldn't find it. I was searching mainly for WGSL. Something Like 'WEBGPU minutes "Unity" "HLSL" "WGSL"'. There was also WHLSL also from Apple at one point but was later droppped in favor of WSL.[0][1]
>A few months ago we discussed a proposal for a new shading language called Web High-Level Shading Language, and began implementation as a proof of concept. Since then, we’ve shifted our approach to this new language, which I will discuss a little later in this post.
>[...]
>Because of community feedback, our approach toward designing the language has evolved. Previously, we designed the language to be source-compatible with HLSL, but we realized this compatibility was not what the community was asking for. Many wanted the shading language to be as simple and as low-level as possible. That would make it an easier compile target for whichever language their development shop uses.
>[...]
>So, we decided to make the language more simple, low-level, and fast to compile, and renamed the language to Web Shading Language to match this pursuit.2
The "we designed the language to be source-compatible with HLSL, but we realized this compatibility was not what the community was asking for" comment is funny because Unity's "We care about HLSL" comment seems to be directly against this.
In any case, this is really a disappointing move from Apple. Just another example of them ignoring developers – even large developers like Adobe and Unity – over completely petty disputes and severe NIH.
The craziest line in the post is probably "[WSL] would make it an easier compile target for whichever language their development shop uses." It's like they knew people wanted SPIR-V but they wouldn't do it due to some petty legal drama that Apple invented and then chose literally the worst of all worlds by making yet another compile target instead of at least choosing the next best thing which would be something that is compatible with HLSL.
The choice was between using or adapting SPIR-V, which is what basically everyone doing multi-platform development wanted, or using anything else and pissing everyone off by making them support another shader language. Apple stonewalled using SPIR-V or any other Khronos IP on unspecified legal grounds so they effectively forced the decision to roll a new shader langage, post-hoc rationalizations were given (e.g. human readable formats being more in the spirit of the web despite WebAssembly already existing at that point) but the technical merits were irrelevant when one of the biggest stakeholders was never ever going to accept the alternative for non-technical reasons.
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.
I don't understand why people say things that are kind of trivial to disprove, but here's the document with the notes where Apple refuses to use SPIR-V.
> MS: 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.
Reading between the lines, it seems like Apple mainly doesn't want to implement SPIR-V because engaging with the "Khronos IP framework" would prevent them from suing other Khronos members over patent disputes.
Because WebGL, just like WebAssembly (with its hacky thread support and compilation issues) is a giant kludge.
WebGL still has fundamental issues of not even supporting anything resembling a modern OpenGL feature set (with modern meaning 2010s era stuff like compute shaders and multi draw indirect) in theory, and in practice, macOS doesn't support WebGL2, meaning stuff like multiple render targets (which is necessary for deferred rendering), so it's almost impossible to make a modernish game that runs in a browser well.
Imo the problem isn't that WebGPU/Wasm is a decade/X years behind, but that we cannot reliably expect a feature set that existed on typical mid 2000s PCs to reliably work in the browser across all platforms (which is the whole point of the web).
Despite all the bending over backwards to keep the fruit company on board with WebGPU, they still haven't actually shipped their Metal backend in Safari over a year after Chrome managed to ship DirectX, Metal and Vulkan backends simultaneously. Mozilla hasn't shipped WebGPU either but their resources can hardly be compared to Apples.
Honestly Google's probably almost as guilty - Native Client was a great idea and sidestepped basically all the issues we are having now, but they killed it in favour of 'standard' APIs, like Wasm that basically barely work for their intended purposes
Nah, Native Client had a lot of its own problems. Except for pthreads-style multithreading, PNaCl couldn't even compete with asm.js, and Spectre/Meltdown would be just as catastrophic for PNaCl as it was for SharedArrayBuffer.
> Add Mozzilla to the mix, for not wanting to adopt PNaCl.
Mozilla wasn't in any position to command the market, even at the time PNaCl was created. PNaCl failed on its own demerits.
> Firefox is almost irrelevant now
Firefox has been irrelevant because it doesn't have the trillion dollar budget of Apple and Google, nor the vendor lock-in, and with that no reach which would enable it to steer web the way it deems fit. It has nothing to do with asm.js
The argument against NaCL was that it was the browser API, PPAPI, was poorly documented and exposing implementation details of Blink/Chromium and thus very difficult to implement in a non-Chromium browser, so it's no surprise that Mozilla, Apple, and Opera were unenthused.
Mozilla wasn't the only one with problem with PNaCl. They were definitely most opposed to it, but even Opera was strongly against it (granted it was around 2011).
WebGL2 is fully supported in Safari since quite a while now. In fact it's using the same rendering backend as Chrome and Firefox (ANGLE), and AFAIK Google and Apple engineers worked together to create (or at least improve?) the ANGLE Metal backend and integrate ANGLE into Safari.
The native WebGPU libraries accept SPIRV as input, and they offer libraries to convert WGSL to SPIRV and back. E.g. WGSL is only needed when running WebGPU in browsers, but even there it can be code-generated from other shading languages by going through SPIRV (but tbh, I actually like WGSL, it's simple and straightforward).
Except that the conversion to WGSL is a complete waste of compute resources, engineering effort and the time of everyone involved. WebGPU is a _web_ API after all, even if people realized the runtimes could be used outside the browser.
Converting your SPIR-V to WGSL just to convert it back to SPIR-V to feed it into a Vulkan driver, or running an entire language frontend just to emit DXIL or Metal IR. We learned 15 years ago that textual shader languages at the GPU API interface are a mistake but we're forced to relearn the same mistakes because Apple wouldn't play ball. What a joke.
WGSL was a mistake and hopefully they get rid of it, it negatively impacts WebGPU's adoption, at least it did for me, the syntax is one of the worst ever created, just horrible
