WSL tells you very little about how the language is actually executed. I do not see any explanation of, say, waves and quads, which will need to be spelled out explicitly when these things are added. It's a requirement for proper LOD selection for texturing, along with ddx/ddy.

Simple branching in shaders is notoriously under-defined as well because of complications related to divergence/convergence and the SIMT model.

re: dominator analysis, it was brought up by an Apple WebGPU developer (Myles C. Maxfield) as a complexity of parsing SPIR-V. David Neto had to explain it to Myles. https://docs.google.com/document/d/1wG9BRLUSw4FbpnvqieK--jTW...

> WSL tells you very little about how the language is actually executed. I do not see any explanation of, say, waves and quads, which will need to be spelled out explicitly when these things are added. It's a requirement for proper LOD selection for texturing, along with ddx/ddy.

The spec has a semantics that describes that the language does when executed in great detail.

It seems that your complaint is that there is some thing that you think that SPIR-V describes better than WSL - waves and quads in this case.

I was there when we brought up dominators. You are right that we brought it up as a complexity of SPIR-V, but not because we didn't know what dominators are. We do know what they are, and because we do know, we know that it's complex. We're not saying "it's so complex that we don't understand it". We are saying "we understand it and we know it's complex". In particular, an early argument against text-based languages is that you have to specify and then validate variable scoping. Dominator analysis is a variable scoping rule, just a very complicated one for a wire format to have.

> The spec has a semantics that describes that the language does when executed in great detail.

Here's what the WSL specification says about loading a texture, one of the simplest possible features of a shading language, but one that introduces a lot of complexity (again, to load a texture requires calculating an LOD, which requires talking about derivatives and scheduling pixels and shader execution in terms of quads):

> Todo: fill this section Sample, Load, Gather, etc..

That's it.

Now, your Babylon.JS demo clearly samples textures. So you have some semantics implemented, but what semantics are they? Note that these things are baked pretty heavily in hardware, so if you get the semantics wrong, you can't really fix the hardware. Your semantics have to model reality as it exists. Your automated tests can say that the spec is correct, but might break on a real GPU after translation to SPIR-V/Metal/HLSL.

The WebGPU working group does not currently have any participation from AMD or NVIDIA. Khronos and the SPIR-V working group do. I trust them to get these details right.

Fun fact: The current modelling of "discard" of as OpKill instead of OpDemoteToHelperInvocation is incorrect for Metal's "discard", which I presume is one of your backends right now.

> The WebGPU working group does not currently have any participation from AMD or NVIDIA. Khronos and the SPIR-V working group do. I trust them to get these details right.

On the other hand, the SPIR-V working group has no participation from Apple or Microsoft (vendors of relevant platform APIs, relevant shading languages, and in Apple's case, of relevant GPUs).

You might argue that Apple should join the SPIR-V group but you could likewise argue that AMD and Nvidia should join the WebGPU group. After all, their voices would be valuable as to the API and not just the shader language. The barrier to entry to a W3C Community Group is also much lower.

I doubt those vendors really want to retrace their steps to go through the multi-year pain and many committee discussions that brought us SPIR-V, again. Look at all those names on the SPIR-V specification. Do you want to waste all those people's time, again, for that many years?

Nobody inside the WG but Apple wants WSL.

I was there for one of the times that Phil (from Apple) explained dominator analysis and why it's an added complexity of a binary language. Phil is the architect of our JS VM and one of the main designers of WSL so I think he knows!

Your claim that the WSL spec tells you very little seems off to me. The spec includes formal semantics for everything. If some things aren't in the spec yet they can be added. There is also a pretty extensive test suite. To me the level of specification rigor is considerably higher than SPIR-V, which has an informal spec with separate documents for adding web safety.

What I don't understand about this logic is why you don't opt to augment SPIR-V with the aspects required as opposed to branching off on an entirely different standard. I'm sure there are politics I'm not privy to, but here I am watching 48 processors pegged on compiling shaders and I really don't care to deal with another instruction set.

Google has a well-defined SPIR-V execution environment they have been championing: https://github.com/gpuweb/spirv-execution-env/blob/master/ex...

Is there a test suite?

I don't see why it should be relevant at this point, although there are several large test suites (including fuzzers) for common libraries in the SPIR-V ecosystem. Shader language tests should be added to the WebGPU conformance test suite regardless of the language.

But no tests for the web safety layer afaik.

There's the start of some in spirv-val. https://github.com/KhronosGroup/SPIRV-Tools/blob/master/test...

I think we should focus more on the advantages and disadvantages of WSL and SPIR-V, and their relevance to existing or future ecosystems -- not debate over which language had the first web tests.

When someone says one option is a nonstarter because it's new and immature, I think its fair to look at different signs of maturity to evaluate that statement.

(I personally don't think any option is a "nonstarter" but it's hard to even get agreement on the relevant evaluation criteria.)

It's not "new and immature." It has a formal specification and is used in production on devices/pcs everywhere. The comment itself was sort of vacuous and nitpicking a single aspect which is something that could be remedied through collaboration.

The set of web safety changes for SPIR-V is kind of new and immature in my opinion. I agree that it's building on a core that is widely deployed in other contexts.

By that standard, everything with respect to a shader ISA for the web is "new and immature." The point is finding a suitable common ground for all vendors to agree on working on. Not everyone going every which way to work on uncoordinated efforts.