The discussion of shader language had been very contentious. As of very recently there is a proposal for a textual language that is semantically equivalent to SPIR-V, and there seems to be agreement that this is the path forward. The submitted link is a presentation with the proposal.
It’s best understood in the context of the Minutes for GPU Web meeting 2020-02-12 Redmond F2F, which also has some discussion about design choices - how much syntax sugar, whether types should be explicit, inferred, or optional, etc.
The previous proposals were some profile of SPIR-V, a binary format, and Apple’s Web High Level Shading Language proposal, which evolved into Web Shading Language. Both of these had disadvantages that made them unacceptable to various people. It’s not possible to use SPIR-V directly, largely because it has undefined behavior and other unsafe stuff. The Google and Mozilla implementations addressed this by doing a rewrite pass. Conversely, Apple’s proposal met with considerable resistance because it didn’t deal with the diversity of GPU hardware in the field. There’s a lot of ecosystem work centered around Vulkan and SPIR-V, and leveraging that will help WebGPU considerably.
(The above is somewhat adapted from my recent blog post with GPU compute resources, but the new shader language is definitely the interesting news).
And here I thought the real objection to SPIR-V was entirely nontechnical. From the 2019-12-09 meeting minutes:
I’m not a lawyer, but given the fact that the Khronos IP framework amounts to “you agree not to sue/press copyright against people who implement this spec, and gain the same benefit”, and given that Apple is apparently fine with the standard being owned by W3C which has basically the same IP provisions… I can only conclude that this whole damn pile of BS is happening because Apple is already in the process of suing/threatening to sue Khronos over something in or related to SPIR-V.
Ohhhhh- that explains a lot. I was wondering what the value of a language strictly isomorphic to spir-v was, over just spir-v. Sucks that it has to go that way, but it’s probably the best option then.
Can you outline these?
This doesn’t look like a proposal so much as not-WHLSL. I really like the webkit doc as it outlines motivations and explains the context. edit, More info on the WHLSL issues so much drama, controlling the GPU is the bulkhead of platform dominance. It looks like we are on the tipping point of the OS being largely irrelevant. All the pieces are already in place. One pattern I have seen is that security is an afterthought, semantics were added that someone wanted (C++ users and pointers) and now that spec cannot be used a new context. If things are secure be default, they can be used everywhere. Secure is a subset of correct, we should strive for correctness, esp in specs. Correctness does not mean working as intended.
Ok, the proposal was just an item to start the discussion, the important parts are in the transcript.
So it is 1:1 to this subset, but this conflicts with what I think DS was trying to say (and/or other comments in the transcript, too tired to cite) that SPIR-V is translatable to Tint.
So only a subset of valid SPIR-V programs will translate to Tint?
This is all very exciting, I hope the WebGPU folks follow the design clarity that the WebAssembly folks have demonstrated.
The Intel GPU docs are fascinating.
You’ve already quoted the Google objection to WSL - it is a near impossible task pinning down and testing the semantics of a GPU shading language across the ecosystem unless it is based on SPIR-V. Apple doesn’t have to deal with this because they ship two or three orders of magnitude fewer SKUs than the rest of the ecosystem, and the design of WSL reflects this (it’s more based on Metal than SPIR-V).
The Apple objection to SPIR-V is largely non-technical. They prefer a textual format, prefer a single unified document rather than incorporating SPIR-V by reference, and then they’re unwilling/unable to work with Khronos for legal reasons I don’t understand but have been referenced publicly in multiple contexts. There’s this related issue that raw SPIR-V is unsuitable because it allows lots of undefined behavior, and a web execution context must be safe. Because Tint is bijective with SPIR-V, the work to tame that must still happen, either by having a validation profile (unsafe Tint is rejected) or by doing transformation to add safety checks. This is done as a SPIR-V to SPIR-V transform by both Dawn and wgpu, as I understand. Since you have to do a pass over the shader anyway, it shouldn’t be more expensive to do this as part of a text to binary translation than binary to binary.
You bring up pointers, and that’s something I still don’t fully understand. OpenCL, CUDA, Metal, and Vulkan 1.2 have them, while the others lack them, DX11/DX12 being among the most important. Since SPIR-V can express pointers (but essentially as an extension), Tint can express them, but it’s not at all clear to me yet what WebGPU implementations are expected to do with them. Choices include: (a) disabling them in WebGPU, (b) allowing them as an optional extension when running on a pointer-capable GPU, (c) translating them into array accesses. Since WSL included pointers, it seems like they were going for (c).
By “gate” what I understand is that all SPIR-V is syntactically translatable to Tint (and vice versa), but not all of it will be accepted in a WebGPU execution environment. One conceptual way to think about this is that “unsafe” is an optional extension, which would be available to programs running as native code, but not available in a Web execution context. But SPIR-V/Vulkan was not designed with safety in mind, so it’s not designed this way, and I think a fair amount of work is needed here.
Thank you for the context and the detailed response.
I hope that Apple working on WebGPU and its unwillingness to work with Kronos for “reasons” isn’t too much of a poison pill for the overall relationship with Kronos. So much good has come out of what they do.
I view pointers as an expedient hack, much like leaking database keys into the presentation layer. And most of the time they have ambient authority. WebGPU and the security properties it needs I think will need IHV involvement in the long term to provide GPU protection domains and virtualization. Again, I think there is a lot to learned and gained from the philosophy of WebAssembly.
But the overall direction and attitude of the WebGPU team is excellent.