I strongly favor sticking to DRM-free text-based formats for the web. I remember learning a lot just from looking at the HTML and JS sources from web pages. It's been a great boon for the web up until now. Besides lots of apps already ship shaders as text. They get dynamically compiled and cached, just like JS does. Being text-based hasn't stopped JS from greatly improving performance.

Khronos sat on their hands for years and only moved after Apple shipped Metal and AMD dumped Mantle in their laps (I'll note that Metal came first). SPIR-V is not the be-all end-all of shader programming. Personally I don't believe we should accept some lowest-common-denominator that puts the future of GPU development in the hands of an organization with the track record Khronos has wrt managing OpenGL. That goes double for the future of WebGPU. However I recognize those are just personal opinions and reasonable people may disagree.

To those offering opinions here: If you've never written a renderer or shader can I suggest you write a toy project using both then see if you still have the same opinion?

The problem with the view-source argument is that source is often minified these days, so you need a decompiler of some sort to go from the bits on the wire to something human-readable no matter what. A pretty-printer can sometimes be simpler than an IR decompiler, but often not really.

I purposefully don't minify the source on my personal website, so people can still learn from inspecting it, if they'd like to.

Regardless of Apple’s motivations those still are real benefits, I think at least one major WebGL framework uses dynamic shader generation and was looking at going the bundled-shader-compiler route. Hopefully this approach cuts back on the projects that find it necessary to do that and encourages faster adoption from WebGL.

If you're willing to do dynamic shader generation as text, you can generate shader bytecode. The real question is which of the two options produces more performant shaders and faster compile times, since naively-generated shader bytecode isn't being optimized like your text is. If you care about compile times text-based can be a lot worse (this matters for the Dolphin emulator, for example)

That is correct, in theory, but there is a large gap between theory and practice. How practical would it be for, say Three.JS to generate shader bytecode? Would it need to depend on a sophisticated WASM module that allows to build such bytecode? Who is going to build that?

Google has spent a lot of effort trying to answer these questions, and they got close, but in the end the text-based solution prevailed. In part, because it was easy to agree on for all parties.

Do you not expect GLSL -> WGSL compilers in actual practice? I don't think anybody using Three.JS today would switch to writing WGSL unless they could also ingest it on WebGL.

In one of the futures, our shader translation infrastructure will support GLSL input and produce WGSL output :)

That’s true, even if the semantics are the same (and parsing time isn’t a big factor) the assumptions for what optimizations have been applied to bytecode might be different. I remember seeing in one of the meeting notes that they didn’t expect browsers to end up making assumptions about the optimization level of the SPIR-V they ingest anyway but I don’t remember the specific rationale for that.

There’s of course also the time for the SPIR-V -> gpu native step. It would be nice if they could just cache that and skip the whole process most of the time.

Indeed. A text-based language makes no sense in 2020. WASM already took the approach of going binary-first.

If you want live-tweakable or generated webgpu shaders, which will be useful in many applications text based is much better as no complex tooling is required.

You could still build something like Shadertoy if the WebGPU shaders internally used a binary format. You would just need to have a JS or WASM library that compiles text shaders into the binary format. It's not that difficult to do, and it can absolutely run in the browser.

There's a SPIR-V text representation that maps directly to the binary representation. Even if it was given a binary, the browser could display the equivalent text representation.

Useful to what applications ? Even writing modern JS requires a compiler stack, adding a shading language would be a matter of writing a webpack loader.

As an example, ShaderToy (and ShaderGif which I built) compile shaders directly in the browser.

As they have already told you, shaders being in binary or text form is orthogonal to making a tool like ShaderToy.

However, binary form is way more compact for transmission, storage and performance. Almost nobody will use the text form except developers.

> However, binary form is way more compact

That’s what I might expect too, so I was surprised to find out that SPIR-V is usually substantially larger than text based shaders. It also doesn’t seem to compress optimally using standard algorithms. [1]

[1] https://aras-p.info/blog/2016/09/13/Shader-Compression-Some-...

The transmission/storage size of shaders isn't important. Textures and 3D models dominate in any non trivial project. Kind of like dieting by trimming your toenails.

That’s maybe true for current 3D graphics heavy projects, but is not necessarily true for any arbitrary future use of GPU compute.

GPUs are machines for crunching data, be it graphics or NNs. I can't think of many use case where that isn't true.

Also if you anticipate the GPU being used as an accelerator, that is all the more reason to use a text based format because it allows for easy code generation.

You are wrong. Many projects use GPUs without big datasets. See ShaderToy, for instance: a lot of computation, almost no input data. Many other games, too: they may use the GPU for rendering fast yet have say 50 MiB of textures and assets only.

If you think of AAA games, ML and whatnot, of course. But I doubt anybody will use WebGPU for those, to be honest.

50MB of textures is a lot compared to shader source code size, which will be in the kilobytes for such a small project.

The same with shadertoy, the storage or transmission of a shadertoy shader is never going to be significant compared to all the assets on the page.

The contention was that a binary representation is necessary to save space for storage or transmission. It just isn't.

I'm sure there will be JS libraries that can compile them in the browser - a minor inconvenience for those apps.

Why does it require a compiler stack?

If you want to use React with JSX then you must add babel to your project.

I think the counter-argument to "but WASM?!" is that on the Web you still can use text to describe the behavior. WASM is optional. At the same time, if WebGPU picked SPIR-V binary, it wouldn't have a built-in way of programming without dependencies inside a browser.

I'm not quite sure what you're saying. WASM is optional in the same way that WebGPU is optional. They both allow you to invoke code written in another language.

There's not really a good way of writing WASM without dependencies inside a browser.

What I wanted to say is that we as a group want people to be able to use the browser and nothing else to develop WebGPU if they want.

WASM by itself doesn't provide new APIs, it's still just a different way to expose the Web platform. So WASM being optional doesn't limit anybody in what they can do. Having WebGPU optional does limit what you can do on the web. We want WebGPU to be available in a wide sense (accessibility, dependencies, portability, everthing).

Being able to develop with the browser has nothing to do with WebGPU being binary or text.

It seems you speak with "we", as if you were part of the committee? If that is a yes: how can we become part of that committee to amend this mistake? Who has voting rights?

How are you suggesting to write shaders in the browser if they are expected to be in a binary form?

WebGPU community group is open to anyone interested: https://www.w3.org/community/gpu/

We can compile and run c++ code in a browser with WASM versions of clang, why would it be any issue to compile glsl / any other language to spir-v ? That's already what almost everyone is doing with spirv-cross / shaderconductor on the desktop

WebGPU doesn’t provide new APIs in the same sense that WASM doesn’t provide new APIs, they just provide alternative APIs to accomplish the same tasks, but faster.

Anything you can do with WebGPU you could do in JavaScript, in the same sense that anything you can do with WASM you can do in JavaScript. The only difference is performance.