Implementing WebGPU in Gecko | Hacker News Reader

Implementing WebGPU in Gecko

kvark.github.io

116 pointsfanf245 comments

Years ago when I was trying to clone Firefox’s and Chrome’s code bases WebIDL capabilities in order to simplify native bindings in Titanium SDK, I would have killed for such an article. Very interesting!

I've been looking around, and it seems WebGPU is doing the same things we've been using WebGL for. Is it a more generic interface that also allows for arbitary computation? (a la GPGPU)

More capable (compute) and modern: command buffers, passes, pipeline states, bind groups, multi-threading.

Superb toolkit for ads mining cryptocurrency :-/

Or even whole sites! Maybe it's the long-sought revenue model for journalism ;-)

WebGPU to WebGL is like Metal/Vulkan to OpenGL.

> it seems WebGPU is doing the same things we've been using WebGL for.

Not really the same though, the purpose of WebGPU is exposing a sandboxed GPU hardware directly to the web, not exposing just a graphical API like WebGL exposes OpenGL variants.

It currently is looking at being SPIR-V compatible. As both Vulkan and OpenCL supports SPIR-V we might use WebGPU for GPGPU in the future.

Good thing SPIR-V approach prevailed, despite Apple trying to derail it.

There is no resolution for this question yet, too early to celebrate anything.

Ah, I see, thanks for clarifying. I misread the post then, since it mentioned SPIR-V.

Too bad Apple not only refuse to support Vulkan, but try to prevent using SPIR-V as well.

They just want to make sure we aren't depending on Khronos too much. It's a reasonable thing to want for the group.

As for Firefox, the WebGPU implementation uses the infrastructure we have for Vulkan Portability, and so consuming SPIRV is natural.

What I care about is having a modern shading language not stuck being a C dialect, and good GPGPU debugging.

If whatever Apple does forces Khronos to be more innovative, moreso the better.

Without CUDA's winning strategy regarding multi-language support, SPIR-V and SYSCL would never had happened.

Metal Shading Language is a C++ dialect. HLSL is as much of a C dialect as GLSL is. And I would argue that C++ provides no benefits over C for shading languages.

I prefer GLSL to Metal Shading Language.

Thankfully all proprietary shading languages have moved on from GLSL.

Indeed, I really appreciate MSL being a C++ dialect.

Moved but remained proprietary. So the problem is not solved. Language shouldn't be proprietary to begin with. It's an obsolete and invalid practice from the last century.

Apparently not, given the monthly occurrence of FOSS projects that decide to go dual license, or even back to proprietary, because this century practice doesn't cover their existence and life responsibilities.

For languages? That's a dead end really. That's why whatever Apple will produce will also be dead, as long it's proprietary. Apple is stuck in that mentality and has hard time getting out of it.

> a modern shading language not stuck being a C dialect

SPIR-V allows you to compile from whatever you want, and avoids the hideously complex beast that is C++ needing to be part of the browser's API.

The track record of industry GPU language development is very poor (arguably even disastrous).

I worry that we now just count on nice languages / compilers magically appearing deus ex machina, and we end up not having any. Big multiplatform frameworks like Unity will just put a SPIR-V backend on their existing tooling.

The rest of us will be stuck with POC-quality GLSL transpiler tools, without the browser devtools and other tooling support that we slowly got over the ~10 years of WebGL history.

(I'm not saying GLSL is that excellent, just that could be heading backwards from current almost-good-enough GLSL implementation quality in WebGL.)

You already see this with Vulkan, where many studios opt for middleware engines instead of having to deal with all boilerplate themselves.

You see this on Android and Switch, where most Vulkan related stuff, is based on Unreal and Unity tutorials.

During Metal Shading Language's development, there were multiple opportunities to engage for Apple to open up their shading language toolchain, and make MSL a standard that would be respected by multiple people. They ignored that advice, and now lots of people grumble about writing MSL. It is, in many people's eyes, a quite decent shading language, but it's "different enough" and for a niche enough platform (in the games world) that it pays the price heavily. Tooling is pretty abysmal, and GPU debugging in Xcode is not the greatest experience.

Now, with that said, Apple did not propose MSL to the WebGPU working group either. Apple originally proposed a hilariously underspecified fork of HLSL called WHLSL which had three goals: 1. Be a safe shading language for the web, 2. Be compatible with existing HLSL content, 3. Add pointers.

Nobody ever justified the existence of that last one to me or the rest of the group, other than making the Metal implementation slightly easier for Safari, since Metal's binding model is based on pointers, and coincidentally, the Safari pre-release only supported binding pointers, and not the standard HLSL way of doing things. But still, the WHLSL proposal was interesting to a lot of people because HLSL seemed like a good language to start from.

After a lot of debate, Apple secretly went back to the drawing board, and released a revised version of the language, WSL, which dropped the goal of HLSL compatibility but still has pointers for some reason. Nobody has ever explained why it has pointers, despite everyone continuing to ask. The goals are still there if you want to read them [0].

https://github.com/gpuweb/wsl#goals

Thanks for providing an overview.

Thanks for the summary. It highlights how "collaboration" from Apple's perspective works. Throwing something over the fence, and then going back to discuss things in secret.

Given the quality of Khronos SDKs and stubborness to C bindings, that might not be a bad thing.

As they have learned the hard way with OpenCL, most devs like to be pampered with modern toiling.

Heck, it is thanks to Microsoft that we have glTF 2.0, and NVidia for any kind of usable C++ Vulkan bindings.

Using C bindings you can plug in any language you want, C ABI is simple. Try that with C++ or anything of the sort, and you'll be in trouble.

If you want to improve quality - anyone can contribute and improve, instead of like Apple trying to sabotage and derail.

It's not so easy to contribute to Khronos.

Surely easier than collaborating with Apple who are extreme lock-in proponents.

See for example projects like dxvk, which affected Vulkan spec:

* https://www.youtube.com/watch?v=1fU4w2ZGxH4&t=12m21s

* http://jason-blog.jlekstrand.net/2018/10/transform-feedback-...

Good luck for such thing happening with anything Apple related.

Spec development? No.

But for bug reports, debugging and fixing bugs in the shader compiler, validation layers, etc they are pretty responsive to issue reports and pull requests.

Yeah, around 500 boilerplate lines of code to draw a triangle on Vulkan, plus having to going hunting for features that every graphics application requires and all other APIs provide on their SDKs.

With Khronos APIs, every newbie graphics developer learns to build their engine from day one.

> Given the quality of Khronos SDKs and stubborness to C bindings, that might not be a bad thing.

None of which has anything to do with SPIR-V? It's a standardised intermediate language, not an API, and it has no dependency on Khronos tooling.

It kind of has, if Khronos never provides anything better, as it has been proven before, hardly anyone will step up to improve it, until the standard starts being put aside in preference to proprietary middleware or competing APIs.

There is nothing wrong per se with SPIR-V to provide anything much better. What you said has indeed nothing to do with the intermediate language itself.

It's relevant to what you choose to use as the standard. A language can be fine on its own terms, but also you should only install it with a layer on top and not by itself.

SPIR-V is fine as a standard. What you put on top and transpile into it should be completely flexible. I.e. no need to mandate higher level languages.

And if anyone wants to make a better higher level language and compiler for it to generate SPIR-V, they are always welcome.

Did SPIR-V actually "prevail", or is Apple going to continue implementing WSL regardless of where the standard goes?

Not sure really. Apparently it's not yet resolved, which means Apple are still trying to derail things.

I'm not entirely convinced spriv is good for webdev. imagine the only way to code in a browser was to use an offline compiler to emit byte code. some people might like that but I'd argue there have been many indirect benefits to having the text version of JavaScript be the default on the web.

sure there will be workarounds like building your own DSL to spriv compiler and including it on your page but I'd argue a standard high level text format leads to more collaboration / standardization / interop / knowledge sharing

I'm sure others would prefer the web had just started as sandboxed assembly

SPIR-V already has a lot of collaboration, and will provide natural synergy with non Web use cases, since it's the standard bytecode format for shaders there already. So collaboration argument goes for SPIR-V here.

Human readability of the shader shipped from the page is a different argument, and it can have some merit, but the same could be argued against using WebAssembly for instance which is not very human readable in comparison with JavaScript. I don't think it's a strong argument against using it.

I've had enough experience with deploying GLSL on many Android devices and also WebGL to be disillusioned with it. There's no great modern textual shading language out there, GLSL is missing a lot of modern niceities, HLSL isn't really an "independent language" (could talk more about that), and Apple's WHLSL/WSL proposal is drastically underspec'd to the point of hilarity.

I think if you want to compile shaders from source, you are free to include your favorite transpiler as WebAssembly, like glslang. That's currently what I'm doing for my WebGPU prototype project.

As someone who's only used GLSL of all the shader languages, what are some of the modern features it's missing?

Generic types are probably one of the biggest ones. GLSL has generic builtins, but you can't define your own. But besides that, HLSL's support and management of buffers and bindings is a great deal saner than GLSL's. Especially the new syntax for loading structures from a ByteAddressBuffer. Beats the craziness that is SSBOs and image load/store.

GLSL's upbringing with integrated texture/samplers is a bit ridiculous in a separable texture/sampler world, like in Vulkan. You need to create an integrated texture/sampler with the sampler2D constructor, and then immediately use it. The GLSL spec specifically says you can't pass it to your own user-created functions, I'm guessing because they didn't trust platform vendors to write working compilers?

But glslang checks for it too, despite being the only GLSL compiler in the toolchain: https://github.com/KhronosGroup/glslang/blob/bd97b6f9f2132fa...

You also can't put any binding object like texture2D in a struct, even though you can pass it between functions? The whole enterprise really feels like it was limitations in baby's-first-compiler that added a bunch of weird restrictions.

HLSL is a C++-esque derivative that supports quite a bit more functionality than you probably imagine, and a lot less of the goofy limitations, given that it has a single compiler stack made by a company with competent compiler engineers.

SPIR-V “assembly” can be disassembled, the disassembly is fairly easy to read, and it's not that hard to write by hand, though rather verbose.

An advantage of SPIR-V is that unlike both text-based programming languages and traditional machine code, SPIR-V is very very easy for machines to read and write — even for JS code — and it has a structure designed to be (mostly) cleanly extensible.

As someone who has written in every shader dialect and also dealt with bytecode for all the major consoles, I think SPIR-V is really awesome tbh...

The thing is, a text format is the worst format for interoperability between consoles, desktop and web. Having something like SPIR-V is more akin to LLVM for programming languages. LLVM doesn't preclude the existence of C, C++, etc, but it strictly benefits the ecosystem (which now includes Rust, Haskell, etc). In the same way, I see SPIR-V having the same potential as the interchange format for all the major IHVs.

Vulkan and OpenCL use two drastically different profiles of SPIR-V. You cannot just take OpenCL kernels and run them as compute shaders, huge portions of the execution model are different.

Some googlers are working on OpenCL source to Vulkan-profile-SPIR-V though: https://github.com/google/clspv

No absolutely not (although compute shaders will be a thing).

WebGL1 : DirectX9 :: WebGPU : DirectX12

WebGL1 : OpenGLES1 :: WebGPU : Vulkan

Reply on news.ycombinator.com