A text based language would be easier for beginners (since they wouldn't need to install a separate shader compiler) and would avoid sites that need dynamic shaders having to download and run a shader compiler in the browser.

Using SPIR-V bytecode would benefit from a large amount of work put into an existing standard and an open source compiler ecosystem that many companies are already using.

It looks like a decision has been made to accept a text based language, but one that is defined based on SPIR-V semantics and is easily convertible back and forth from SPIR-V. This seems like a great trade off since if it works out it should have the main advantages of both approaches.

That is more or less the official rationale, but it's pretty clear that the real reason is that Apple is organizationally opposed to SPIR-V (and Khronos generally). This is a tough needle to thread, so I'm glad forward progress is being made.

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?

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.

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.

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

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-...

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.

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

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.

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

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).

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?

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

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.

My enthusiasm for seeing yet another GPU language is very restricted. I simply cannot see the rational arguments in favour of this design. We were so close to having a standard IR for this stuff.

Interesting, what's the successor? I haven't heard of this.

https://webkit.org/blog/9528/webgpu-and-wsl-in-safari/

https://developers.google.com/web/updates/2019/08/get-starte...

https://doc.babylonjs.com/extensions/webgpu

Basically, the Web version of Metal, DirectX12, Vulkan, LibGNM, NVN.

What's wrong with WebGL?

You can see some of that contention here, https://github.com/gpuweb/gpuweb/issues/586 , along with other issues filed.

This is going to be a bumpy ride. I hope it turns out okay.

Sounds like a good thing at first blush, if shaders can be then decompiled to this in debuggers etc.

https://github.com/gpuweb/gpuweb/pull/562

https://github.com/gpuweb/gpuweb/pull/576

Such standards politicking, creation of unneeded entities/standards is basically a "tech sin". They are sinners!

But to generate SPIR-V you still need a high level language. So is this useful for it?

At the same time, SPIR-V semantics is fairly well specified, so we as a group figured that the familiar syntax of HLSL is not as important as the proper GPU behavior and our time specifying it. We've yet to see if it was the right decision - we might as well get stuck with discussing the syntax :)

[0] https://news.ycombinator.com/item?id=22539633

If the motivation is to replace SPIR-V itself, then it's not valid.

I'd say everyone else should take a hard stance on this and show Apple to the door, instead of dancing under their tune.

Releasing a standard that a major member opposes and won't implement is a pointless exercise.

They might use the same medicine.

It's apple that didn't want SPIRV and insisted on something else, preferably text based. Doesn't matter who is doing that something else now, it's done because of Apple... Which I'm not entirely a fan of because I don't think apple's history in WebGL, OpenGL and graphics makes them deserve the leverage they're getting.

I surely hope not the later, let Apple pay performance price for being the root of the problem.

It's not even clear if Chrome or Firefox will accept SPIR-V binary as an extension at this point.

Anyway, conversion to and from SPIR-V is supposed to be straightforward and light. Our (speaking for gfx-rs community) Rust-based shader infrastructure will handle that , and the converter should be easily compilable to wasm (when it's ready).

Anyway x2, most of the time in the whole picture of creating pipelines will be spent in the driver, so whatever parsing performance difference WGSL brings to the table, be it 5% or 10%, doesn't matter, you aren't going to see that in benchmarks because of that other stuff that's going on when you are creating a pipeline.

I hope Mozilla and Google won't cave that way to this Apple's idiotic behavior.

Interesting, that's the first time I hear about it. Do you have some links on the topic? What is the essence of the dispute?

MS: Apple is not comfortable working under Khronos IP framework, because of dispute between Apple Legal & Khronos which is private. Can’t talk about the substance of this dispute. Can’t make any statement for Apple to agree to Khronos IP framework. So

1. https://docs.google.com/document/d/1F6ns6I3zs-2JL_dT9hOkX_25...

Besides, if JS interop were the driving concern, 64-bit doubles would be the default, since that's what JS numbers are.

[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

BigInt is now available on Firefox and Chrome (with JSC/Safari support in the works). That gives arbitrarily-large integers (with the JIT deciding the best size.

None of the mobile GPU vendors (Apple, ARM Mali, Qualcomm, PVR, BroadCom) support it. You can see that here, where the only vendors supporting shaderFloat64 in Vulkan are desktop GPUs. http://vulkan.gpuinfo.org/listdevicescoverage.php?feature=sh...

Unfortunately it is not exposed in Firefox or Chrome, even if the underlying hardware supports it. I think this is creating a chicken and egg problem - if WebGL were to actually support the capabilities of the underlying hardware, maybe there would be more interest in deploying 64-bit extensions on other platforms like mobile. Even emulated support would be a win, compared to having every developer emulate fp64/i64 themselves in GLSL.

So I am also disappointed in this proposal's failure to mention 64-bit support, even as an extension. At least they're reserving the keywords, I guess.

[1]: https://www.khronos.org/opengl/wiki/Data_Type_(GLSL)#Scalars

[2]: https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_g...

The data types are prefixed with "d", so you have vec4 for float[4], and dvec4 for double[4].

Add that fact that mobile GPUs and some Intel GPUs don't support it in hardware at all, it makes a lot of sense to leave fp64 out of WebGPU.

Edit: and most of the rest are Intel.

It would be interesting to see a graphics API designed to cover a range of 100 000x in performance.

Looks like Nvidia TNT had 2 GB/s of memory bandwidth in 1998 and the high end current ones have ~300-600 GB/s. That's just two orders of magnitude difference. Current fast mobile GPUs seem to get 40 GB/s so that plops to about the middle of the historical PC dGPU range, and is just 1 order of magnitude less than dGPUs.

WebGL mostly serves people with Intel/mobile GPUs, so will probably WebGPU if it is to survive, even though it aims to do better on the high end GPUs as well.

https://webkit.org/blog/8482/web-high-level-shading-language...