WebGPU Shading Language | Hacker News Reader

WebGPU Shading Language

gpuweb.github.io

105 pointspjmlp115 comments

Some context: browser vendors are working on a successor to WebGL, and there's been a debate over what shading language to use.

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.

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

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.

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

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

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.

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.

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.

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

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.

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.

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.

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.

Is there really such a great need to make the lowest level shader API more accessible to beginners? You can always build things on top that make a low-level API more friendly, but you can never build something below the lowest available level (short of inventing a new standard). What kind of beginners are these that want to do low-level shader programming, but without any tooling? Don't web programmers already accept the use of heavyweight build tools even for their plan old ordinary Javascript?

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.

I think the goal here is for the semantics to basically be SPIR-V, and for people using SPIR-V toolchains to be able to expect WebGPU platforms with a Vulkan backend to execute basically the same SPIR-V after the conversions to/from text.

Knowing Vulkan, WebGL, and OpenGL and working a bit with some of those technologies while hobbying the others, WebGPU will take about a decade to be fully adopted, and even then, only by a fraction of companies that are willing to spend manpower resources into developing something interfacing low level graphics directly.

WebGPU is important for game engines, currently it is missing a lot of features so you can't write the shaders you want.

That's because there is no rational reason. The reason this is at it all an issue is because Apple put their foot down and flat out refused to implement SPIR-V.

They also refused to implement WebP support. If they can't get their act together I'll still get my revenge by using a polyfill that decodes WebP images with Javascript (goodbye battery life!).

The willingness of the various web consortiums to bend over backwards for individual corporations has got to end. It's making the web worse, not better.

I dont want an Google Image format so I am glad they dont support WebP. I much rather they support JPEG XL.

I agree. Originally SPIR (without a V) was just a 1:1 copy of LLVM IR with no commitment to backwards compatibility. Every time LLVM IR changed SPIR had to change as well. This lead to two major versions of SPIR. Clearly this is not a sustainable solution. Implementing several versions of the same IR is a huge support burden for almost no benefit. Now we have the successor SPIR-V which is no longer tied to LLVM IR. Anyone can implement SPIR-V support without LLVM. There is no excuse to not use it. It's basically the same story with WebAssembly. LLVM IR wasn't good enough so someone had to actually do it properly this time.

> browser vendors are working on a successor to WebGL

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

WebGPU

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.

> Some context: browser vendors are working on a successor to WebGL

What's wrong with WebGL?

It has an outdated programming model, no multi-threading, no compute (portably supported everywhere), limited access to the hardware, etc

It is stuck in a OpenGL ES 3.0 subset.

So this is in a weird place. It's trying to be a floor wax and a desert topping, that is, both a compile target and a human writable language, and the committee is having trouble deciding the vision and goals for the language.

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.

Based on the current version of the "Goals" text it's more of a SPIR-V surface syntax: "Trivially convertable to SPIR-V"

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

Apple is pushing back on that wording. https://github.com/gpuweb/gpuweb/issues/582

That's true, but also a reflection of the whole WebGPU standardization process. It tries to be low-level enough to be performant yet still human writable. I agree it's tricky, but just because it's hard to formulate the concrete goals doesn't mean that there is nothing to discover.

The funniest (and saddest) thing about WGSL is that we realized there is a lot of confusion and tried to make a FAQ quickly to address that, but it got split and stuck in reviews:

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

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

We need optional SPIR-V shaders in Chrome's and Firefox's webgpu implementations, so that websites that use it wouldn't work on retrograde NIH text-based Apple platforms, forcing them to implement SPIR-V eventually.

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

There are no technical issues with us having an extension that allows SPIR-V binaries to come in. It's a political issue, however, since it weakens WGSL positions. We'll be talking about this more with Google.

So it's a new language for generating SPIR-V? Is this driven by shortcomings of GLSL and HLSL?

It's driven by Apple hating Khronos, so we all have to come up with a new, non-Khronos thing if it's to be used in browsers made by Apple.

That seems a bit harsh. Isn't WebGPU to WebGL what Vulkan is OpenGL? It's the next generation of more efficient 3D rendering pipeline.

Vulkan itself supports both GLSL and HLSL (and any other shading language that can compile to SPIR-V), so you'd still usually end up writing GLSL anyway.

Yes, but if you follow the discussions, the clear consensus was to use SPIR-V. Except Apple, who came up with all kinds of technical reasons not to use it, before eventually admitting they have a legal dispute with Khronos group. Now we get this weird language that is SPIR-V in text form but not by Khronos, and suddenly there is consensus.

> before eventually admitting they have a legal dispute with Khronos group.

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?

From the meeting notes [1]:

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

Weird, but at least it explains why they are causing a problem.

Apparently it goes back to how Apple wanted to evolve OpenCL after releasing it to Khronos.

Apple should stop messing things up and should support SPIR-V, sure.

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

Lots of languages _already_ compile to SPIR-V - GLSL and HLSL for a start. Why add _another_ syntax?

I suppose current options aren't optimal. Or at least that could be a valid motivation to create one.

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

Except it wasn't designed to be an "optimal target for SPIR-V" -- it was designed by Apple according to Metal's semantics, to promote Metal over Vulkan, and had to be rejiggered. It's worse, by your standard, than existing, battle-proven GLSL/HLSL toolchains.

This is not correct. The WGSL is renamed from Tint, which is a Google's proposal for a shading language, in agreement with all parties.

They're on record that their motive is disputes with Khronos, it's in some past meeting notes.

Then this should be rejected.

reject it and there will be no WebGPU for 1.5 billion iOS devices just like there is no WebGL2 for 1.5 billion iOS devices.

Why should Apple dictate their approach to everyone else then? If they are so resolved to remain outsiders technology wise because they are crazy bent on NIH, let them be outsiders.

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

It's called a "standards process" for a reason. Even if you personally have a different opinion the point of a standard is to get everyone implementing it on-board with that standard.

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

So if there won't be any consensus, then what? I see no reason to oblige Apple in this case then.

When Apple adopts some technology, they don't care whether others can do the same, or what problems that will cause to others.

They might use the same medicine.

The motivation is to salvage SPIR-V in a way that makes Apple happy.

Apple and Microsoft investigated the possibility of specifying WebHLSL tightly. The main concern was that it's a ton of work in terms of semantics.

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

From a technical standpoint a subset of SPIR-V that is safe to use in web browsers is exactly what is needed. However, there are IP problems that prevent direct usage of SPIR-V. [0] In short W3C needs full ownership of the spec so that it can be completely independent from Khronos. A textual representation of SPIR-V basically sidesteps these problems while still maintaining the ability to have a trivial SPIRV -> WSGL and WSGL -> SPIRV compiler.

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

They refused to explain what IP problems there are, and given it's Apple, I doubt they are valid.

It's not driven by Apple, please double check your sources.

It absolutely is driven by Apple. I've been following this for a while. I actually like having a text based shader format since I do a lot of dynamic shader generation and compilation at runtime, but I don't quite understand why it has to be something entirely different to existing shader languages.

Err, WGSL is essentially renamed from Tint, which was developed and proposed by Google. Where do you see Apple the driver?

Apple refused to support SPIRV, which Chrome (and Firefox?) already implemented, and lobbied for a text based language. Please read the minutes, I'm not going to look it up for you.

I was in the minutes. Just because it's text doesn't mean it's driven by Apple.

Apple clearly says it's not an option because of a legal dispute. If everyone else is at the negotiating table, but Apple says absolutely NO, how is that decision not driven by Apple?

Apple vetoes SPIR-V binary as an option. Google develops a language based on SPIR-V semantics that we agree on. It's clear that at least today, Google is mainly driving WGSL. They also see the value in WGSL outside of WebGPU context. Claiming the Apple primary role in this is ridiculous.

So how is it supposed to work in practice? Pages will ship SPIR-V and will be converted to WGSL just for Apple on the fly, or pages will ship WGSL, and it will be converted to SPIR-V on the fly for everyone else?

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

Many Web applications will just ship WGSL. This includes everything going through Three.js, Babylon.js, and hand-written web apps.

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.

It would still be good for Firefox and Chrome to accept SPIR-V bytecode (in addition to WGSL). This way you can write some client side library, that converts SPIR-V on the fly to WGSL for crippled browsers (Apple) and use SPIR-V directly for everyone else.

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

I don't think there will be a significant performance problem because the generated machine code can be cached.

> Claiming the Apple primary role in this is ridiculous.

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.

Are we missing f64 and other 64-bit integer types because of... JavaScript? Again!?

GPU's rarely have double precision arithmetic.

I'm not sure if you're left over from 2007, but practically all Nvidia GPUs since 2008 have had double precision arithmetic. Integers are still compiled to 32-bit, sometimes, but doubles have been standard for quite a while.

Which GPUs do not have double precision arithmetic? As far as I'm aware, all of AMD's and Nvidia's from the last decade have double precision support. It may not be fast, but it's there.

Right, the desktop GPUs have support for float64, but it's not exposed in HLSL/GLSL to the best of my knowledge. "precision highp float" in GLSL will get you 32-bit on all vendors AFAIK, you have to use OpenCL/CUDA for 64-bit floats, but it's way slower and actually sometimes emulated.

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

GLSL has 64-bit values with "double" and "dvecN" since 4.0 [1] or with ARB_gpu_shader_fp64 [2]. I don't know if anyone actually uses them, though :)

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

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

64 bit support has been around on the desktop for a decade at this point (Through OpenGL4 / GL_ARB_gpu_shader_fp64 / cl_khr_fp64).

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.

Desktop GPUs commonly have support for float64, and it's accessible in GLSL (how else would you use it?) and presumably HLSL.

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

fp64 is exposed in GLSL at least, but on desktop GPUs it's typically 16x (AMD) or 32x (Nvidia) slower than fp32.

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.

Most GPUs are in mobile devices.

Edit: and most of the rest are Intel.

Most animals on earth are ants. Do you propose we optimize for them ?

Not sure what you were aiming for with the analogy, but I'm glad this made me look up the size difference between ants and humans. Humans are O(100 kg) and ants are O(1 mg), 5 orders of magnitude.

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.

I'm saying that just because mobile device is the majority of devices does not mean that we have to care about them. Rule of the majority is never a good rule.

Depends on who "we" are, from POV of browser vendors and makers of web graphics apps, there's certainly a compromise needed in adding features for niche users that contribute to the combinatorial explosion of tested configurations. Consider that even WebGL 2 currently is struggling to have a viable level of browser support.

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.

Number type in JS is fp64 since forever (at least the interface, usually it's optimized to int32 by an engine, but if you use decimals you can be sure you have fp64 under the hood) and BigInt[0] is supported in almost all modern browsers.

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

Small correction, but it's optimized to int31 by all the current engines with the last bit used for tagging.

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.

I'm not involved with the spec discussions, but I suspect it's just because 32-bit floats are heavily preferred on GPUs for performance reasons. If there were a lot of popular demand, I imagine 64-bit doubles could be added, but games overwhelmingly prefer 32-bit; it's mostly the scientific community that wants 64-bit.

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

JS uses doubles by default, so no. There were times when js rendering engines used Float32Arrays for matrix and vector math because they should be faster since that's what the GPU uses, right? Turned out they were SIGNIFICANTLY slower because any math on CPU side now required casting floats to doubles back and forth.

That syntax is freaking ugly. Should've made it more like C and GLSL.

That was my first thought as well. I wonder what the rationale for this divergent syntax is.

I agree with you but I'm sure we'd get used to it pretty quickly too.

I just wish it had support for double and int64. So much great stuff that you can do with 64bit atomic operations that aren't possible with 32 bit atomics.

A webkit blogpost from 2018 claims SPIR-V may not be possible to fully secure in a web context. I'm uncertain of the progress or if the original claim was legitimate, but I believe the current experimental implementations of WebGPU do not protect against raw gpu memory access.

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

Reply on news.ycombinator.com