Porting WebGL Shaders to WebGPU | Hacker News Reader

Porting WebGL Shaders to WebGPU

construct.net

88 pointsAshleysBrain63 comments

I took a very different approach for porting my WebGPU shaders over: I have far too many shaders to port (sometimes pretty massive ones! [0]), so I used Naga [1] at to runtime-translate my GLSL shaders to WGSL. I had to get involved a bit upstream to fix quite a few different bugs in the implementation, but once I got it working I was really happy with the result. It's quite fast, it compiles to a pretty light-weight WebAssembly module, and it works surprisingly well.

[0] https://github.com/magcius/noclip.website/blob/e15f8045cf262... [1] https://github.com/gfx-rs/naga/

Cool project, there is also someone working on making wgsl and glsl together: https://github.com/scoopr/naga-include-poc

Why do you do this translation at runtime--causing every user to have to re-execute it--instead of at compile-time? Is there some kind of per-user optimization this makes possible?

Not GP, but shader translation depends heavily on device capabilities and the current pipeline state. In principle I think it's possible to cache a lot of this on the client, so that it only has to be run once per install (or per device fingerprint change) rather than once per execution, but I don't think that's implemented yet.

Our team is working to build out support for Unreal Engine 4 and Unreal Engine 5 to support WebGPU, so game developers and real-time 3D developers can export their creations to the web at near native performance and access features like computer shaders.

Long term goal is to disrupt Steam and the App Stores.

We're also working on WebXR support to enable UE VR apps on the web. If anyone is interested and wants to learn more, you can join our Discord here: https://discord.gg/zUSZ3T8

It seems like you aren't associated with Epic? What's the long term outcome here? Have Epic take your PRs? Get hired\acquihired (it's unclear if you are a company or a group of hobbyists)? It seems like when WebGPU is production ready Epic will support it as well as WebXR...

Epic's goal is very obviously to disrupt Steam and app stores as well... Ignore all of this if you actually are an Epic employee of course :)

Just to clarify, we're a funded startup and we've already had calls with them showcasing our platform. The goal is to get our SDK and tools in the hand of every UE developer out there.

As a gamer though, why would I want to play any of these developers' games through the browser instead of Steam?

To try it out? Also to play or check in on a friend's computer or a public computer.

The ease of visiting a game like a website is sometimes preferred, depends on the game.

There's a game where the web client is mainly used to view streams of other players (instead of streaming video they mirrored the same packets they received/sent to your web client)

It's a bigger deal for developers, as they don't have to give up 30% to Steam, and they can directly distribute to their end users on their own site by embedding.

Not to mention instant cross-platform availability across PC/Mac/Android and iOS. Even Xbox supports WebGL2 via the new Chromium Edge they shipped on there recently.

To detriment of players experience, because neither Web 3D APIs are a match to native hardware capabilities.

No downloads and the ability to easily and quickly jump into the action, especially useful for multiplayer or social games.

You're maybe not saving the game to disk, but you still have to download it. At least the assets you're going to interact with. And if you want to play again, then you keep the game/assets in a browser cache somewhere and there's not much difference with downloading and installing the game, in terms of bandwidth/diskspace

Of course, but from the user’s perspective this is all transparent. Parent comment is talking from the UX perspective.

A single player title? Yeah, no thanks.

However, think of the convenience of joining your friends on a web-based Minecraft-like game. And then hyperlinking to another server with some in-game mechanic.

This is something I'm really interested in doing open source, once WebUDP is more mature.

Yep. I don't see this game-in-the-browser thing taking off anytime soon for anything serious. Player retention, and immersion, are terrible. Casual 'adware' games, maybe.

Aside from what others have mentioned, the browser's sandboxing makes it a lot more appealing to try out small indie/hobbyist casual games on a whim. Like the Flash game aggregators of old, or maybe itch.io today.

As a non-web-developer, I'm kinda excited about WebGPU. Specifically WebGPU native, that has potential to be a portable modern 3D graphics API without the difficulty of using Vulkan or DX12.

What game engine do you use? UE4 or Unity?

I'm not a game developer, so neither.

Agree, it gives you pretty low-level access if you need it, but you can still draw a triangle in under 100 lines, e.g. https://github.com/morzel85/webgpu-wgsl-hello-triangle

It can only expose a subset of their capabilities.

Don't expect using mesh shaders on WebGPU for example.

I'll say I am definitely biased in favor of WebGPU up front[2].

WebGPU is focused on landing 1.0 currently, so yes, more features are not on the immediate roadmap.

But they've been considering/investigating adding support for this before mesh shaders in DX12 were even finalized[0] so it's not like there is some "we cannot / will not expose that functionality" mandate going on here. Despite its name, WebGPU is actually pretty much a 1:1 mapping of what is commonly available across APIs.

Separately, AMD doesn't support mesh shaders in Vulkan either, in fact Vulkan doesn't at all outside of a Nvidia extension from what I understand - and it sounds like there are some concerns from Khronos about whether they even map to all GPU architectures in a reasonable way at all.[1]

If you want to argue "but by dropping to the level of DX12, Vulkan, Metal, etc. I can use some very specific new features" that's totally true, but you can do that with WebGPU native too: after all, Dawn and other WebGPU implementations are just abstractions over those 3 APIs. One can just as easily hop into their code and add your own extension to make use of Mesh shaders in DX12, I can say that at least Dawn's codebase is set up to allow for such extensions from what I've seen.

[0] https://github.com/gpuweb/gpuweb/issues/445

[1] https://github.com/KhronosGroup/Vulkan-Docs/issues/1423#issu...

[2] https://devlog.hexops.com/2021/mach-engine-the-future-of-gra...

When WebGPU runs on the browser you cannot definitely do it, after all that is the whole point being discussed about working around stores.

Given the distance between WebGL 2.0 and GL ES 3.2, with the 10 years that took to made it available everywhere, good luck waiting for WebGPU to become mature for adoption.

Mesh shaders was the easiest example to refer to, there are plenty of 2021 native features that won't make it into version 1.0.

Then to top that, we get a shading language that seems like C++, Rust and HLSL had a child.

> Given the distance between WebGL 2.0 and GL ES 3.2, with the 10 years that took to made it available everywhere, good luck waiting for WebGPU to become mature for adoption.

WebGL2 took 4 and a half year to complete (with OpenGL ES 3.0: published in August 2012, and implementations of WebGL2 final version shipped in browsers in early 2017). Why did Apple refused to implement it for four more years? I don't know, but at least it isn't happening with WebGPU.

> Then to top that, we get a shading language that seems like C++, Rust and HLSL had a child.

Is that supposed to be a bad thing?

What guarantees do you have it won't happen again?

Even if Apple had done it on time, it was a 2012 hardware API for 2017 hardware, and never exposed a complete ES 3.0 API surface, nor anything beyond it up to ES 3.2.

Intel had two failed attempts to bring compute into the browser.

Yes it is a very bad thing, when Vulkan can keep using GLSL and HLSL, while DX12 happily will use any HLSL from the API history, and Metal can use proper C++14 shaders.

WGSL is web politics as usual.

> What guarantees do you have it won't happen again?

Apple was pretty clear about their intent not to ship WebGL2, and they did the opposite for WebGPU so it's not gonna be the same story. Of course, I can't be 100% sure that Apple won't change their mind (like they eventually did for WebGL2) or anything, but there is no reason to believe they'll do so.

> Even if Apple had done it on time, it was a 2012 hardware API for 2017 hardware

Most games released in 2017 had to support hardware from 2012 anyway. Even AAA games released this year support GPU released in 2012[0]! For non AAA games, targeting a 5-years old API is probably the newest you can afford. We're not talking about bringing the bleeding edge GPU tech to the web (it won't, it's never standardised anyway, like Mesh shaders you talked about). The goal is to provide modern standardized tech to developers, and it does it in a portable way, which makes it even more affordable.

> Intel had two failed attempts to bring compute into the browser.

So what ?

> Yes it is a very bad thing, when Vulkan can keep using GLSL and HLSL, while DX12 happily will use any HLSL from the API history, and Metal can use proper C++14 shaders.

Vulkan uses SPIR-V, not HSL or GLSL. Translation tooling exist, but it also exists for WGSL -> SPIR-V[1]

Each platform has its own shading language, will this one be better than the other, I don't know but I don't think it's gonna be worse either.

> WGSL is web politics as usual.

Not really. See this summary[2] from a Mozilla gfx engineer:

[0]: https://support.activision.com/black-ops-cold-war/articles/m...

[1]: https://github.com/gfx-rs/naga

[2]: https://kvark.github.io/webgpu-debate/SPIR-V.component.html

If you're writing a game engine for an AAA game, surely you have the budget and manpower to use those lower level API's and push the GPU to its limit.

If the rest of the world can get 90% of the way with an easier to use and more portable API, that would be very nice.

With WebGL 2.0 we have an API designed for 2011 hardware finally fully available in 2021, without any game relevant to compete with something like Infinity Blade, released for GL ES 3.0 on the iPhone.

That is hardly 90% of the way.

WebGPU won't be any different.

Good article, I was looking for a resource like this when I was experimenting with WGSL. I ended up writing a short cheat sheet that might be useful to others here: https://github.com/paulgb/wgsl-cheat-sheet

My main worry with WebGPU is the dependence with Javascript. If I understand it correctly, you can't use web APIs nor stuff like WebGPU directly through web assembly anyway, so there's always a javascript glue layer involved.

Now, I know some languages like Rust have decent bindings that hide all that, but I wonder about the performance cost of that glue. Has someone measured it, or estimated how better we could go without it? Or am I completely wrong about this? Or are there clear plans to make this better/disappear? (Though in my brief research I didn't find anything like it).

https://github.com/WebAssembly/WASI/issues/53

WebGPU is a less chatty API than WebGL. You can kick off a huge amount of GPU computation with just a couple of function calls. The overhead of the function calls themselves is usually not a big issue. That said, I know there has been work in Chrome to make these calls more efficient for WebGL and I think the overhead is actually small.

The same WebGPU API can be used as a cross platform layer to do graphics, no js needed. For example rust's wgpu can just be used without a browser.

The confusion with `let` and `var` does seem confusing from a JS perspective, but it seems to be so that you can have the same mental model between WGSL and SPIR-V:

https://github.com/gpuweb/gpuweb/issues/2207

It seems to be a syntax mismash between Rust, which uses `let` and `let mut`, and JavaScript, which uses `const` and `var`, giving WGSL's `let` and `var`, probably chosen because they are the shortest.

Javascript also has `let`. It's basically like var, but doesn't get hoisted. And can't be unassigned once assigned.

As someone who's never used this API: is there some kind of permission prompt for this before websites start trying to use my GPU for crypto mining? Most CPU crypto miners were basically worthless, but GPU power is a whole lot more powerful.

No permission prompt, just as there is no permission prompt for WebGL (which already enables crypto mining on your GPU).

https://arxiv.org/pdf/1904.13071&ved=2ahUKEwipqPGblenzAhWDbs...

I see. That is somewhat worrying. However, the authors of the paper do state that there are significant drawbacks to the WebGL API that I believe WebGPU would solve, notably by its direct access to compute resources.

I suppose I'll just be disabling these APIs until I can find a personal use for them, then.

Is there any advantage at this point in time to port a game to WebGPU? Is it going to run faster, or have broader browser support in the future?

It's like a web version of Vulkan / Metal / DX12, in that it's designed to more directly represent how modern GPUs work. If you are happy with your WebGL performance, by all means, continue using it. However, it can sometimes be a bit hard to understand what is going wrong (performance-wise) in an OpenGL or WebGL application... the underlying implementation will sometimes paper over its limitations. You can accidentally stray from the high-performance paths.

There are some feature differences, like how WebGPU has compute shaders.

At this time I would recommend WebGL 2. WebGL 2 is finally supported in all major browsers now that Safari 15 shipped. WebGL 2 has some of the benefits mentioned in the article for WebGPU, such as a reasonable minimum texture size (2048 vs 64 in WebGL 1) and the built-in ability to get the size of a texture in a shader.

WebGPU will not ship in all browsers for some time, and when it does it will not have have wider hardware support than WebGL 2. It has the potential to be faster in some cases, but the difference is unlikely to matter for most. The big draw of WebGPU should be compute shader support, though it is definitely possible to do compute work in WebGL 2 either with transform feedback or just regular shaders.

It is currently shipping behind a flag in desktop versions of Chrome (and all its derivatives), Safari, and Firefox. It is also shipping behind a flag in Firefox for Android. I don't think it's too far out from finally shipping.

The biggest boon would be for mobile devs to help avoid the 30% store tax, but this is also the reason why mobile Chrome and mobile Safari (especially Safari) tend to lag behind in major ways.

What Safari is shipping behind a flag is not anything like the current version of WebGPU. I don't think it supports WGSL, for example. It's going to be a long time before all three browsers have shipped implementations that are interoperable and not behind flags.

I don't think WebGPU is the biggest thing that's going to let mobile game devs start shipping on the web. WebGL 2 can do graphics well enough today. Other things hold the web back.

Monetization is the big thing that people always talk about. The lucrative interstitial app install ads that mobile games have aren't on web, and in-app purchases have a lot more friction. Handling large binary assets is also a place where the web is lacking and WebGPU won't fix that. Finally, there's a lot of ecosystem and tools stuff that needs to happen too. The engines need to add web platform support which goes more than skin deep. Shipping a game as one giant binary is not good enough for web, you need to split your code into dynamically loadable modules and stream your assets. You need Basis Universal compressed textures. Etc.

Fix all of the above and then web games can shine, with or without WebGPU. Realistically, fix monetization and the rest will follow. Big caveat though: I think many see the monetization techniques currently used by mobile games as exploitative. It's not clear that you could do web game monetization competitively without the same level of exploitation.

I play a lot of web games without any of that stuff now

There's definitely a niche market out there, I think https://poki.com exemplifies it. Which ones do you play?

BGA and basketball gm

Web 3D APIs are castrated, they will never be able to match native APIs.

Going for GL ES 3.0 subset, when devices do GL ES 3.2?

Going for a MVP 1.0 with minimum overlap across Metal, Vulkan and DX12 instead of using their full blown capabilities?

In both cases, having to use native GPU debugging tools anyway.

Rather give the 30%.

assuming you are comparing it to webgl. WebGPU has better compute support. in practice this means you can more effectively use shaders to perform things like physics, math heavy computation, or algorithms that benefit from massive concurrency. this puts the advantages way beyond just games.

Not at all, it took 10 years for WebGL 2.0 to be generally available, and WebGPU is with luck reaching MVP 1.0 in 2022 on Chrome, let alone anywhere else.

No to first question, unless you count learning, as it's mot enabled in browsers yet. Maybe to second (depending on your game).

> GLSL supports the ternary ?: operator. WGSL does not support this, but provides the built-in function select(falseValue, trueValue, condition) which does much the same thing (although mind that parameter order!).

I'd really like to hear a justification for that parameter order. To me it seems like the 4th best option out of 6.

It could be because it matches the order of glsl's `mix()`. Not sure why glsl chose that order, though perhaps you might find it less unintuitive for an interpolation than a select. (Mix acts as a select rather than interpolation when the third argument is a boolean)

That makes much sense, thanks! But then why didn't they call it mix() or lerp() or interpolate()? I would have immediately spotted the logic behind it.

EDIT: I think I get it, there also a mix() with a different type signature but same parameter order.

lerp(zero, one, t) -> select(falseValue, trueValue, condition ? 1.0 : 0.0)

Semi-related: does anyone have WebGPU running on an M1 Mac? Pretty sure it "can be done" but the appropriate experimental options are not even there on either Safari or Chrome...

WebGPU is enabled by default in Chrome on Mac as part of the WebGPU Origin Trial (https://web.dev/gpu). We didn't really test on M1 Macs but several people reported it just works.

I got it going by passing "--enable-unsafe-webgpu" actually on the command line. Thanks.

Sorry about the formatting at the top. An unexpected problem with the blog system on our website! The rest of it looks OK though.

As someone new to the WebGL scene, can someone shed light on what are the motivations in porting WebGL to WebGPU?

Check out another comment: https://news.ycombinator.com/item?id=29002748

Really glad you made this article. Do you guys use rust for webGPU?

Reply on news.ycombinator.com