The wire size comparison is also weird. Are they comparing serving WSL directly (depending on a WSL compiler they went ahead and built into the Safari preview) vs GLSL plus a compiler to convert to SPIR-V because that's not built into any browser (yet)? Why would that be an interesting comparison?
But presumably if that was the eventually standardized format the compiler could ship with browsers, though, right? It just seems weird to compare against another format that hasn't been agreed to either but they shipped the compiler with the browser preview so people can test it.
It should either be comparing sources or comparing (source + compiler to get it working in a shipping stable browser), not mixing the two.
The proposal from SPIR-V advocates is to not ship any high level language compiler with the browser. That could change, but currently no one is excited about accepting both a binary language and a text-based language.
Why would you expect people to ship a compiler though? Like: when I want to do runtime code generation on .NET, I don't concatenate strings containing C# and run them through a C# compiler... that would be madness!!... instead I use the APIs provided to do IL generation, which have been extremely amazing essentially since day one and provide unbounded flexibility over working with any specific textual language. If I really really wanted a compiler at runtime, maybe I want a different one, and I can then use differently models like F# or a Lisp variant... things that are much harder if someone insists I translate everything into some silly specific language :/.
Shipping support for both a text format and a binary format directly in the browser is in some ways the worst of both worlds. If both are implemented natively, you get double the attack surface at the ingestion layer. If the text format is supported by compiling to the binary format (or vice versa) using WASM that happens to ship with the browser, it will probably be slow (whereas ingesting a text format directly seems pretty fast).
It seems like there would be alternate ways to do online shader generation than concatenating strings and compiling if there were a well-formed binary standard. Maybe it is the easiest conceptually, but I don't see that as being a performance target in that case.
Edit: Also seems like they are leaning pretty heavily into Babylon.js. I don't think a standard should be developed that closely with any one specific application or framework.
Our collaboration with Babylon.js happened after most of the spec proposal work. It was inspired by Google’s similar collaboration with Babylon.js prompting Google’s own SPIR-V based implementation of WebGL. This makes the comparison more apples-to-apples.
WebGPU itself is guided by input from many framework and engine developers.
Sure. I would just consider that the working group keep a broad perspective on the issue. There are developers who use graphics frameworks bare-metal, and there are also a number of frameworks that haven't been mentioned and don't seem to be cooperating, for instance, Pixi.js and Three.js. I think the WG has a responsibility to represent their interests as well, whether or not they are actively participating. I also don't think that the technology has to match the existing architecture of engines. Instead, we should be looking at find the best technology for a long-term solution.
Many developers already know that they will have to make significant overhauls to upgrade to WebGPU. "If WebGPU turns out to be as powerful as we all hope it to be libraries like Three.js will likely have to be rewritten from scratch in order to take full advantage of it." [0]
We (Apple) have privately reached out to quite a few JS frameworks and web game engines. We’re trying to take all their input into account and to share it with the WG.
