Looking to the future: WebGPU Renderer Backend for Godot

[BryanHaley]

* To start, a big caveat: while WebGPU will be standardized in the near future, the WebGPU API is not standardized yet, so it wouldn't be appropriate to start working on this now. This might be something to consider for Godot 5, or at least as an optional additional backend alongside Godot 4's current Vulkan backend a year or two or more from now.

This is a discussion about the potential of a WebGPU Renderer backend for Godot, either as the primary renderer backend or an optional alternative to other backends like the Vulkan renderer.

What is WebGPU?

In short, WebGPU is to WebGL what Vulkan is to OpenGL. From the W3C working draft:
WebGPU exposes an API for performing operations, such as rendering and computation, on a Graphics Processing Unit.
As the name implies it is intended to be used primarily on the web as a replacement or alternative to WebGL, but its capabilities go beyond that (more on that later).

Unlike WebGL, the WebGPU API is not based on its closest native cousin (a la WebGL with OpenGL ES). It is a completely new API built from scratch and is quite nice to use as far as low-level graphics APIs go. In terms of API semantics, its closest analog would likely be Metal rather than Vulkan or DX12. Like Vulkan, DX12, and Metal, WebGPU offers high-performance low-overhead GPU access for rendering and GPU computation. It also comes with its own shading language, WGSL, which can also be translated to SPIR-V.

Here are some WebGPU demos:
https://gnikoloff.github.io/webgpu-compute-metaballs/
https://webkit.org/demos/webgpu/babylon/oneHelmetWebGPU.html
https://austin-eng.com/webgpu-samples/samples/deferredRendering
(View with Chrome Canary with WebGPU enabled via chrome://flags - again, the API isn't stable quite yet, and Google is the main driving force of implementing WebGPU currently).

What does it have to do with Godot?

The obvious answer is an alternative to the WebGL backend for higher performance in games and apps on the web built with Godot. Like WebGL, you can use WebGPU with Emscripten to render graphics on the web with a C++ codebase.

The less obvious answer, and potentially the one with greater potential for Godot, is that unlike WebGL, WebGPU can be used as a rendering backend for native apps as well.

Google Dawn

Google Dawn is, in essence, a native implementation of the WebGPU API. It is what powers WebGPU rendering in the Chromium and Chrome browsers. What makes Dawn relevant to Godot is two-fold:

• It provides native C++ bindings.
• It effectively acts as a platform-independent wrapper around DX12 (Windows), Vulkan (Windows/Linux/Android/ChromeOS), and Metal (Mac/iOS/tvOS). It also has limited support for wrapping OpenGL for legacy systems that don't provide DX12, Vulkan, or Metal.

Google Dawn is what one would link against to use WebGPU with Emscripten (example), meaning it would require little to no code changes to use WebGPU on the web and Google Dawn for native builds. If you want to use WebGPU with Emscripten, you get the native builds too essentially for free.

From the Google Dawn homepage:

Dawn is an open-source and cross-platform implementation of the work-in-progress WebGPU standard. More precisely it implements webgpu.h that is a one-to-one mapping with the WebGPU IDL. Dawn is meant to be integrated as part of a larger system and is the underlying implementation of WebGPU in Chromium.

Dawn provides several WebGPU building blocks:

WebGPU C/C++ headers that applications and other building blocks use.
    The webgpu.h version that Dawn implements.
    A C++ wrapper for the webgpu.h.
A “native” implementation of WebGPU using platforms' GPU APIs:
    D3D12 on Windows 10
    Metal on macOS and iOS
    Vulkan on Windows, Linux, ChromeOS, Android and Fuchsia
    OpenGL as best effort where available
A client-server implementation of WebGPU for applications that are in a sandbox without access to native drivers
Tint is a compiler for the WebGPU Shader Language (WGSL).

The Google Dawn team provides some C++ examples in their repository. See the building instructions here.

What does this mean?

• This effectively allows you to write and maintain a single high-performance renderer that works the same on virtually every relevant platform including the web. That's less work than maintaining a Vulkan renderer, a GLES/WebGL renderer, and a MoltenVK wrapper around the Vulkan renderer.
• Since Google Dawn powers Chrome's implementation of WebGPU, the WebGPU renderer should work the same across Chrome, Windows, Mac, Linux, Android, iOS, and more with very little caveats - likely even more seamlessly than MoltenVK for providing Metal support. Firefox, Safari, and other browsers will implement WebGPU as well, and those may have additional caveats to deal with, but likely no more so than WebGL implementations do across browsers.
• Additionally, since Google Dawn is part of Chromium, it's likely to get long-term support and updates from Google.
• Godot developers can use a single shading language (WGSL) that works everywhere.

WebGPU has the potential to reduce labor requirements for maintaining renderer backends for Godot in the long-term, streamline game/app development for Godot developers, and improve consistency of rendering behavior across virtually all platforms.

Once WebGPU is standardized and the Dawn implementation is stable, I think it would be very worthwhile to give it strong consideration to use for Godot's primary rendering backend.

[spindlebink]

I've been using WebGPU to learn graphics programming by writing a game framework, and the API is a delight to use.

Another implementation to consider would be WGPU-native. It's written in Rust with an officially-supported C FFI and it works very well. WGPU is the backend for Bevy, an up-and-coming open source game engine in Rust, and the very active Bevy community of developers have committed to supporting it along with the original maintainers.

Since Dawn and WGPU are implementations of the same spec, the API is the same, except that in WGPU you occasionally need to use a drop function to accommodate for Rust's semantics. I'd personally prefer to support the smaller FOSS community and avoid Google, but that might just be me.

[Calinou]

Another implementation to consider would be WGPU-native. It's written in Rust with an officially-supported C FFI and it works very well. WGPU is the backend for Bevy, an up-and-coming open source game engine in Rust, and the very active Bevy community of developers have committed to supporting it along with the original maintainers.

Requiring Rust to compile Godot would complexify the buildsystem a lot, and I don't think it's worth it. One of Godot's strengths is that you can compile it in a few minutes, without spending too much time scouring for dependencies (especially on Windows).

[BryanHaley]

Whether Dream or WGPU-native the end result would be pretty much the same, so I'd personally be happy with either really. I agree it's nice to support FOSS where possible.

Some potential considerations for Dream vs WGPU-native off the top of my head:

• Can you use WebGPU with Emscripten by linking against WGPU-native? If not, that would require Godot to link against Dream for web builds and WGPU-native for native builds, which might be more redundant than it's worth.
• Using Chrome's own WebGPU layer essentially guarantees identical rendering behavior across native apps and the host OS's respective Chrome build (i.e., for a given host, rendering will behave the same in Chrome running on that host and in a native build running on that host). By using a different WebGPU implementation, that adds the potential to run into implementation differences between Chrome and the native builds (i.e., rendering behavior might differ slightly in a native build for the host and a web build running in Chrome on the host). Implementation quirks are inevitable (Firefox and Safari will surely need some special considerations, in addition to Dream likely differing between each OS slightly), but it might be nice to eliminate a few where possible by using Dream.

On the flip side, WGPU-native seems to be based on WGPU-core, which powers Firefox's WGPU implementation, so that should probably guarantee parity with web builds running in Firefox (albeit Chrome is far more popular than Firefox so that benefit is arguably less significant in that case). It also seems to have best-effort GLES backend support which is probably more useful than a best-effort OpenGL backend like Dream. Mozilla definitely seems to lag a bit in implementing the latest WebGPU API updates, though; not sure how long after standardization it'll take them to be compliant. Dream should be ready ASAP after standardization.

[spindlebink]

I'm not an authority on it, but I did find in 2019 the emscripten people mentioned a WebGPU header for both Dawn and WGPU, so I assume yes?

On the other point, is there a reason Chrome is particularly important? If two implementations fill out the same spec I imagine differences in rendering would be minimal and beyond the scope or responsibility of those writing the Godot renderer. Two people's desktops are already going to render things differently depending on specs and settings and platform and all that--passing a pixel-perfect rendering check doesn't seem all that important to me, even irrespective of there being a reason to standardize Chrome's rendition over another.

At any rate one over the other is largely a FOSS/software ethics question and probably worth talking about later, if/when this proposal is officially considered.

[BryanHaley]

I think from a indie dev standpoint, it's nice to guarantee your native build and your web build are going to run the same with no code changes (and just statistically you and your players are most likely to be using Chrome or a Chromium-based browser). It's a very annoying experience to have something work in one build but break in another, and having to go digging through forum posts and docs just to find out some shader function is implemented in a weird way in one rendering backend implementation and not another. Less so concerned with running pixel perfect across both and moreso concerned with the potential for obscure and difficult to diagnose implementation quirks.

Of course, this is likely to be a rare issue, but it's annoying when it happens (just look at how annoying it can already be to get Vulkan shaders working the same across Windows and Linux and across Nvidia and AMD cards, or WebGL anything to run the same across Chrome, Firefox, and Safari) and worth considering to some extent I think. It eliminates a point where implementation quirks can pop up in a technology space already fraught with implementation quirks.

[spindlebink]

Ah, that makes sense. I expect quirks are a bigger issue with the concept of wrapping other APIs in the first place (i.e. implementation diffs pop up running on the Vulkan rather than Metal backend, for instance, the way the 3.4 ES/core renderers in Godot have varying features, although in my experience WebGPU is pretty uniform so far) rather than which implementation of a spec, but I also don't know for sure. I don't have strong feelings about which implementation would be theoretically used except for FOSS motivations as mentioned, and that's not up to me in the end. Godot's generally good about hiding platform details anyway, and this'd be renderer-side rather than user-side.

[Calinou]

Godot has its own RenderingDevice abstraction, which makes it easy to plug additional graphics backends (and doesn't require engine developers to actually care about the underlying API in use). It currently supports only Vulkan, but Metal, Direct3D 12 and WebGPU support can be added to it in the future. The OpenGL ES/WebGL renderer doesn't use the RenderingDevice abstraction, as RenderingDevice is only designed to be used with modern graphics APIs.

This effectively allows you to write and maintain a single high-performance renderer that works the same on virtually every relevant platform including the web. That's less work than maintaining a Vulkan renderer, a GLES/WebGL renderer, and a MoltenVK wrapper around the Vulkan renderer.

I would be wary of going this route. It would mean that we'd have to bundle, compile and rely on a large Google-developed¹ library on all platforms, even when it's not strictly necessary. There's also likely some performance overhead and compatibility issues involved, similar to what ANGLE is doing when used on Godot right now.

In general, Godot aims to keep its dependency count low to avoid relying on third-party development decisions. We've been bitten by this in the past 🙂

Footnotes

1. Google is known to drop projects with little notice when they don't work for their needs. I wouldn't assume that being part of Chromium guarantees that Dawn will be maintained in the long term. ↩

[BryanHaley]

Those are valid concerns - and with RenderingDevice abstraction I see providing WebGPU as an optional backend rather than the primary is definitely the route to take. I assume it probably wouldn't be too difficult to transpile Godot shaders to WGSL (-- I had assumed Godot used GLSL; still a Godot noob lol).

It's also worth noting that overhead is likely to be much closer to what we see with MoltenVK than what we see with Angle; maybe even lower since WebGPU was explicitly designed to wrap Vulkan/Metal/DX12 unlike Vulkan -> Metal. As a developer on Apple platforms if the overhead is lower than MoltenVK I'd gladly use the WebGPU backend instead even for native builds, for example.

Side note - regarding WGPU-native, would it not be possible to provide prebuilt blobs to statically link against?

[Calinou]

(-- I had assumed Godot used GLSL; still a Godot noob lol).

Indeed, Godot uses GLSL.

Side note - regarding WGPU-native, would it not be possible to provide prebuilt blobs to statically link against?

Committing precompiled libraries is usually frowned upon in the open source community, as you're effectively trusting the developers that compiled the library and committed it to the repository. While this is fine from an user perspective, Linux distribution packagers often require building everything from source when creating their packages, so it'd add unnecessary friction there.

[clayjohn]

For the record, a WebGPU backend is already planned. It will definitely be implemented as a RenderingDevice like Vulkan. The modern renderers (clustered/mobile) will target WebGPU when exporting to web.

For more information see the renderer naming and organization proposal here #4261