Important Note If you were using webgpu.cmake
prior to November 5, 2023 please update it to prevent breaking changes. Each revision of this file now points to a specific version of the distribution submodules to make sure your project still builds even when the distributions gets updated.
The standard WebGPU graphics API has multiple implementations, mostly wgpu-native (Firefox) and Dawn (Chrome).
This repository provides distributions of these implementations that are:
-
Easy to integrate. These are standard CMake projects, that can be included either with a simple
add_subdirectory
(potentially using git submodules) or using FetchContent. No esoteric build tool is needed. -
Interchangeable. Switching from one backend to another one does not require any change to the build system. Just replace your
webgpu
directory by a different distribution. A preprocessor variableWEBGPU_BACKEND_WGPU
orWEBGPU_BACKEND_DAWN
is defined to handle discrepancies in the source code. -
emscripten-ready When calling
emcmake
, these distributions switch to emscripten's WebGPU header (which is mapped to JavaScript WebGPU API).
As a bonus, they include a WebGPU-C++ header consistent with the backend capabilities to ease C++ development of WebGPU-based applications.
Different options for using this repository are detailed bellow. The only difference is the <branch_name>
to use when getting a distribution, either by downloading the source from:
https://github.com/eliemichel/WebGPU-distribution/archive/refs/heads/<branch_name>.zip
and including it with add_subdirectory(webgpu)
, or by using fetch content:
FetchContent_Declare(
webgpu
GIT_REPOSITORY https://github.com/eliemichel/WebGPU-distribution
GIT_TAG <branch_name>
)
FetchContent_MakeAvailable(webgpu)
This creates a webgpu
CMake target that you can link against.
NB In order to ensure that dynamically linked backend are copied next to the generated application, call target_copy_webgpu_binaries(TargetName)
at the end of your CMakeLists for each target TargetName
that links against webgpu
.
Branch: main
(recommended)
The main branch enables one to chose any backend when configuring the project by setting the WEBGPU_BACKEND
CMake cache variable. It is even possible to maintain multiple builds that use different backends:
# Build using wgpu-native backend
cmake -B build-wgpu -DWEBGPU_BACKEND=WGPU
cmake --build build-wgpu
# Build using Dawn backend
cmake -B build-dawn -DWEBGPU_BACKEND=DAWN
cmake --build build-dawn
# Build using emscripten
emcmake cmake -B build-emscripten
cmake --build build-emscripten
Other branches enable only one of these solutions. Use them only if you want to target a specific backend.
An alternate way to include this option is to copy the webgpu.cmake
file in your project and call include(webgpu.cmake)
. You may then adapt the GIT_TAG
to freeze the version of each backend (by specifying an exact commit hash).
Branch: wgpu
This backend is provided as pre-compiled binaries. You need to trust these binaries, but if you do it is the fastest solution.
This is also the solution to use for fully offline builds as it does not fetch any other content.
Branch: dawn
Extra dependency: Python
The Dawn-based branch compiles a WebGPU backend entirely from source, including a code generation step that requires Python. This is safer but takes some time to build the first time.
Dawn provides much more details about errors than wgpu-native. And since it is a C++ project, it provides stack trace information that integrates nicely in IDEs.
Branch: emscripten
One of the strengths of WebGPU is to be possibly built as web pages. This branch is very lightweight, since when targeting only the web, no backend is needed (the web browser provides is at runtime).
Why is this distribution repository needed?
In theory we could use WebGPU backends as packaged by their developers. However in their current state, they suffer from some limitations:
-
wgpu-native does not provide any CMake integration.
-
wgpu-native auto-built binaries have some issues: binaries for Windows and macOS were incorrectly named (defeating linking), Windows release build is sometimes missing.
-
Dawn build instructions require the installation of depot_tools, which is overkill: our distribution replaces it with a simple Python script, Python being needed anyways for code generation purposes.
-
Dawn provides a C++ interface similar in some ways to WebGPU-C++ but that cannot be used with wgpu-native because it directly communicates with the Dawn backend instead of using only the standard
webgpu.h
header.
Important. When using this repository as a submodule, you should advise your users to add --shallow-submodules
to their git clone
command so that they only download the branch you picked.
I am not very happy with this, as it is likely that people forget it. I'm thinking of splitting this repository into multiple ones, namely one per option, but it is not ideal. In the meantime, a safe option is to just copy the content of this main
branch into your repo.
Single-platform precompiled library. I initially cared about providing a standalone folder that can be dropped in any project or shared with students and works on any desktop platform without the need for an Internet connection or anything (what the wgpu
branch does).
While I intend to maintain this possibility, since the Flexibility option already uses a FetchContent mechanism it could be used to download only the binaries needed for the current platform.
Static linking. wgpu-native now also auto-builds static libraries, they are included as an alternative in the wgpu-static
branch but this is highly untested (and I'm pretty sure it does not work for MSVC).
Precompiled Dawn binaries. Is it worth it? Initial compilation takes time, but then it is okay. Could use Zig for this.