Hi Surma. Thanks a lot for this writeup. I have been trying to get into WebGPU but good introductory material was sorely lacking some time ago.
I have one question: I have had trouble finding a combination of browser/OS/GPU that would allow WebGPU access at the time, what setup did you use and do you have any recommendations? Particularly looking for options on Linux. (Sorry for hijacking this thread)
The WebGPU Shading Language spec is edited by Google and Apple, Mozilla were the ones proposing straight SPIRV and are not among the editors in this case.
Still doesn't make any sense but it has nothing to do with who the editors are.
The author list and W3C document are pretty much irrelevant, the actual working group is what counts.
After thinking about it some more, I've come to the conclusion that I've actually not been strong enough in my initial accusation, and that Apple is trying to smother any threat that WebGPU poses to its native App supremacy.
The story is essentially:
Apple wants SPIRV dead.
Mozilla wants SPIRV alive.
Google wants SPIRV alive.
Google developed a human readable text version for SPIRV, which is isomorphic to the binary version, akin to WASM <-> WAT.
Mozilla wants SPIRV, which Apple fully rejects (because of some legal dispute with Chronos, where Apple probably tries to get a patent for something that Chronos has as prior art or something), but they are open to googles proposal of a textural intermediary, which is isomorphic.
Mozilla and Google agree, because they'll all compile down to SPIRV anyways, except for Apple which will target Metal.
This decision is captured in the W3C proposal which to this day contains the Isomorphism property.
That's the Embrace, WGSL is born.
Apple convinces Mozilla and Google that WGSL should be even more human readable, since user readable formats are the backbone of the open web. But for more convenience WGSL will need more features. Extend.
Apple convinces Mozilla and Google that now that the language has grown anyways they should make it much more compatible with other shading languages in general, SPIRV will not be the only target, so while it should be compilable to SPIRV, that's by no means a primary goal. Isomorphism is abandoned. Google tries a last ditch effort to keep the isomorphism with a proposal literally called: "Preserving developer trust via careful conversion between SPIR-V and WGSL".
The proposal is rejected, the working group decides that the isomorphism property will no longer hold (I can only assume malevolence that they haven't removed it from the spec yet, probably to keep dev support.). Extinguished.
Why is that isomorphism so important? Because it's near impossible to develop truly high performance shaders with a load of compiler optimisations between your hardware and your tooling. Apple is successfully giving us GLSL in new clothes, and developers are cheering them on, because they just read the W3C spec and ignore the realities of the standard.
---
Apple: "Having an isolated focus on SPIR-V is not a good perspective, we have MSL etc. to consider too"
...
Apple: "Extreme A is no interaction with SPIRV?, extreme B is very tightly coupled to SPIRV, we should find a middle point"
...
Google: "We take all targets into consideration. We can allow developers do runtime probing and maybe branch according to that. Optimization occurs in existence of uncertainty. Dealing with fuzziness is a fact of life and we should give the tools to developers to determine in runtime."
This is a very inaccurate summary of what happened. And I say this as someone who does not particularly like WGSL. Mozilla, Google and Apple are all working to help design WGSL.
Minor nitpick: this translation happens in separate libraries/tools which just make use of the SPIRVTools library for some SPIRV processing tasks, but not the actual translation to WGSL.
What kind of explanation would you like to see? We link to the repo and the Privacy explainer at the bottom of the page. Why is it important to you to know that it’s made by Googlers?
The goal of Squoosh is more to teach out about all the options and levers codecs have. JPEG is not “suggested”, it’s just literally the first codec we ported to Wasm so that’s the auto-selected one :D
The Squoosh CLI has an auto-optimizer that will make an image as small as possible while staying under a given Butteraugli threshold, but you still have to decide on the format yourself.
Do you express the resulting file size or the amount saved? “30%” could mean you “30% of the original file size” or “you shaved off 30% of the original file size”. You could denote the difference with a sign, like “-30%” but that still confuses people. We ran both options by a lot of our colleagues.
“x% of the original file size” is the least ambiguous, but who has the space to put that entire phrase in their app :-/
> This doesn't seem to be a problem whenever a shop runs a sale.
Maybe because they don't mind people misinterpreting the sale as larger? I've never seen 30% off mean "30% of the original price", so if people misinterpret it will always be too small.
