Thus, I'm curious to see how Rust will tackle it. Will it try to enforce the portability and safety guarantees with a type system, or will it specifically lower the guarantees compared to native code (thus keeping the syntax of Rust but not the philosophy).
Anyhow, amazing work by Embark, and a stellar example how to collaborate in open source!
Everyone was yelling this at you since the beginning. Ever since Apple proposed "safe HLSL", and then it morphed into WHLSL and then WLSL and then the competing Tint proposal which is now WGSL, everyone (Adobe, Valve, Epic, Unity, NVIDIA) was saying "none of this will do what you think it does, we've all been here before and it's very very hard, at the very least, get some IHVs or at least a team that does port work / emulation tech on board".
The committee chose not to listen, instead forcing WebGPU down this hell that nobody really wants or appreciates. The whole WebGPU is three years late and still has no users, despite being one of the most complicated specs to land in years. And yeah, I'm still a bit bitter about it.
I am also skeptical of rust-gpu's approach, because I don't think it's possible to take a CPU-inspired language design and blindly adapt it to GPUs without some difficult questions to answer (they still don't have flow control, but I'm told that's coming).
But at the very least, I think repi and Embark know what they're doing and know about the tough problems, rather than feigning being blindsighted.
Sure, it might be more of an Apple legal team problem vs programmer problem. None-the-less they are the ones that decided to derail the standard.
Fortunately, we landed on a good compromise with a textual language that maps closely onto SPIR-V semantics. A lot of the hard work remaining is to achieve the level of safety and interoperability required for the web. Even in an approach of using SPIR-V as the syntax, a similar level of effort would have been required on safety and interop aspects.
Safety, maybe not 100%, but this could be fixed with extensions, and transformations. The same transformations that WGSL compilers will apply. I'm unsure of what you mean by "interoperability".
> or the advantages of text formats that the web has benefitted from.
??? Nobody has ever enumerated these to me. Or told me why if these advantages are so great, why Apple has not advocated for a text-based formats for <audio> and <video>. Binary formats are widely becoming more standard on the web for all sorts of reasons (images, fonts, video, audio, even code in the form of WebAssembly, and Bloomberg/Facebook's JS AST proposal improved performance by removing parsing cost. MapBox ships its vectors in binary format. glTF is a binary format.), and even in the graphics space, the release of the new SPIR-V format over having to ingest GLSL is seen as one of the greatest advantages of Vulkan over OpenGL.
If you want a text format, take the text serialization of SPIR-V. It's there, it's standard, it exists.
But you won't bother answering me, because every time you bring this up, we ask the same questions, repeat the same evidence, and you ignore us, preferring just to reply "text is more webby".
Not to mention that you're currently pressuring the WG to add new APIs to avoid the heavy front-end cost of Apple's own MSL shader compiler.
TBF, having to include a binary shader blob in a small WebGL-style demo (e.g. some interactive math visualization embedded in a blog post) would suck compared to just adding a few lines of text.
It would be possible to load a WASM module with a text-to-SPIRV compiler, but that would most likely be a few megabytes.
IMHO one shouldn't discard those small shadertoy-style demos, this is what made WebGL popular, not the "AAA games on the web" pipe dream.
My understanding is that this was discussed, and the answer is: glslang is much smaller than this. (Glslang now has a bunch of #ifndef WEB to facilitate precisely this.)
I’m not sure why you think the people involved in this effort are clueless about shader languages. That does not seem supported by the evidence.
Let's face it, Metal is nicer than Vulkan. And I bet there are more Metal programmers out there by now than there are Vulkan programmers.
What I’m telling you is that defining these checks and transformations is the hard part, not the syntax. If your claim is that WebGPU is taking longer because of WGSL, I don’t think that holds up.
> I'm unsure of what you mean by "interoperability".
Consistent behavior across browsers and platforms. Some thing in SPIR-V are not specified with as much precision as modern web standards like HTML or ECMAScript.
>> or the advantages of text formats that the web has benefitted from. > ??? Nobody has ever enumerated these to me.
These have been discussed to death in the WebGPU WG. I’m not sure why you think someone owes you personally a direct explanation. But here are some. Ease of debugging. Learning via “view source” ability to develop and publish with no compile step if desired.
> why Apple has not advocated for a text-based formats for <audio> and <video>
There is no textual source format for a media file. Media files also need bespoke compression to transmit efficiently. Gripping a text format would not work. Gzip transfer-encoded WGSL is more compact than gzip transfer-encoded SPIR-V, so the transfer size advantage cuts the other way (but not clear this really matters for shader programs)
> Binary formats are widely becoming more standard on the web ... even code in the form of WebAssembly
WebAssembly is intended for a very specific use case, porting native apps to the web. Even so, many in the WebAssembly WG think it was a mistake to make it a binary format instead of text, in retrospect.
> Bloomberg/Facebook's JS AST proposal improved performance by removing parsing cost
> If you want a text format, take the text serialization of SPIR-V. It's there, it's standard, it exists.
There is no standard text serialization format of SPIR-V. There’s an unofficial format supported by spirv-cross, but it’s not a standard. WGSL was created by starting with that serialization format, and progressively adding concessions to human-authorability while preserving a mapping to SPIR-V semantics. We (WebGPU CG) hope to make it a standard and perhaps even make that standard usable beyond the domain of WebGPU.
> But you won't bother answering me, because every time you bring this up, we ask the same questions, repeat the same evidence, and you ignore us, preferring just to reply "text is more webby".
I just answered you comprehensively. I feel like 0% of what I said is new information beyond what has been stated many times before in many venues. So I think the problem here may be on the reader side, not the writer side.
> Not to mention that you're currently pressuring the WG to add new APIs to avoid the heavy front-end cost of Apple's own MSL shader compiler.
This has nothing to do with share language choice per se. That said, the WebGPU CG charter includes the goal of working naturally and efficiently on top of Metal, along with Vulkan and DirectX. This proposal, based on perf measurements, is a way of removing overhead for Metal that won’t affect the other two WebGPU target underlying APIs. Do you feel that WebGPU should not work efficiently on top of Metal? You may not care about this personally, but the CG charter disagrees. Is it bad faith “pressuring” to share perf info about how WebGPU maps to Metal, or just the normal way the standards process is supposed to work? To me it looks like the latter.
We need to stop trying to make software mitigations and start putting pressure on hardware designers.
That is to say, WebGPU is working with IHVs indirectly via Khronos, Microsoft, etc, and is putting pressure to introduce the safety features at the driver/hardware level. We've been arguing for more defined UB in Vulkan specs, initialization of workgroup memory, device memory ownership, and other things.