Apple and Microsoft investigated the possibility of specifying WebHLSL tightly. The main concern was that it's a ton of work in terms of semantics.
At the same time, SPIR-V semantics is fairly well specified, so we as a group figured that the familiar syntax of HLSL is not as important as the proper GPU behavior and our time specifying it. We've yet to see if it was the right decision - we might as well get stuck with discussing the syntax :)
From a technical standpoint a subset of SPIR-V that is safe to use in web browsers is exactly what is needed. However, there are IP problems that prevent direct usage of SPIR-V. [0] In short W3C needs full ownership of the spec so that it can be completely independent from Khronos. A textual representation of SPIR-V basically sidesteps these problems while still maintaining the ability to have a trivial SPIRV -> WSGL and WSGL -> SPIRV compiler.
Why should Apple dictate their approach to everyone else then? If they are so resolved to remain outsiders technology wise because they are crazy bent on NIH, let them be outsiders.
I'd say everyone else should take a hard stance on this and show Apple to the door, instead of dancing under their tune.
It's called a "standards process" for a reason. Even if you personally have a different opinion the point of a standard is to get everyone implementing it on-board with that standard.
Releasing a standard that a major member opposes and won't implement is a pointless exercise.
Except it wasn't designed to be an "optimal target for SPIR-V" -- it was designed by Apple according to Metal's semantics, to promote Metal over Vulkan, and had to be rejiggered. It's worse, by your standard, than existing, battle-proven GLSL/HLSL toolchains.
It absolutely is driven by Apple. I've been following this for a while. I actually like having a text based shader format since I do a lot of dynamic shader generation and compilation at runtime, but I don't quite understand why it has to be something entirely different to existing shader languages.
Apple refused to support SPIRV, which Chrome (and Firefox?) already implemented, and lobbied for a text based language. Please read the minutes, I'm not going to look it up for you.
Apple clearly says it's not an option because of a legal dispute. If everyone else is at the negotiating table, but Apple says absolutely NO, how is that decision not driven by Apple?
Apple vetoes SPIR-V binary as an option. Google develops a language based on SPIR-V semantics that we agree on. It's clear that at least today, Google is mainly driving WGSL. They also see the value in WGSL outside of WebGPU context. Claiming the Apple primary role in this is ridiculous.
> Claiming the Apple primary role in this is ridiculous.
It's apple that didn't want SPIRV and insisted on something else, preferably text based. Doesn't matter who is doing that something else now, it's done because of Apple...
Which I'm not entirely a fan of because I don't think apple's history in WebGL, OpenGL and graphics makes them deserve the leverage they're getting.
So how is it supposed to work in practice? Pages will ship SPIR-V and will be converted to WGSL just for Apple on the fly, or pages will ship WGSL, and it will be converted to SPIR-V on the fly for everyone else?
I surely hope not the later, let Apple pay performance price for being the root of the problem.
Many Web applications will just ship WGSL. This includes everything going through Three.js, Babylon.js, and hand-written web apps.
It's not even clear if Chrome or Firefox will accept SPIR-V binary as an extension at this point.
Anyway, conversion to and from SPIR-V is supposed to be straightforward and light. Our (speaking for gfx-rs community) Rust-based shader infrastructure will handle that , and the converter should be easily compilable to wasm (when it's ready).
Anyway x2, most of the time in the whole picture of creating pipelines will be spent in the driver, so whatever parsing performance difference WGSL brings to the table, be it 5% or 10%, doesn't matter, you aren't going to see that in benchmarks because of that other stuff that's going on when you are creating a pipeline.
It would still be good for Firefox and Chrome to accept SPIR-V bytecode (in addition to WGSL). This way you can write some client side library, that converts SPIR-V on the fly to WGSL for crippled browsers (Apple) and use SPIR-V directly for everyone else.
I hope Mozilla and Google won't cave that way to this Apple's idiotic behavior.
Yes, but if you follow the discussions, the clear consensus was to use SPIR-V. Except Apple, who came up with all kinds of technical reasons not to use it, before eventually admitting they have a legal dispute with Khronos group. Now we get this weird language that is SPIR-V in text form but not by Khronos, and suddenly there is consensus.
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
Vulkan itself supports both GLSL and HLSL (and any other shading language that can compile to SPIR-V), so you'd still usually end up writing GLSL anyway.
