⏱️ Lectura: 10 min
The Learn WebGPU for C++ guide now spans five languages and covers, with chapters marked green as production-ready, how to set up a native 3D graphics application on Windows, macOS, and Linux without depending on a browser. The project is maintained by French developer Elie Michel and documents, chapter by chapter, how to use native WebGPU outside the context it was born in: JavaScript inside the browser.
📑 En este artículo
Its value isn’t just educational. By using the same backend, wgpu-native or Dawn, that runs inside Firefox and Chrome, the guide’s C++ code works the same on desktop as when compiled to WebAssembly for the web, with minimal changes.
TL;DR
- Learn WebGPU for C++ is open source documentation for programming native 3D graphics in C++, without going through the browser.
- Covers Windows, macOS, and Linux with CMake and two interchangeable backends: wgpu-native (Mozilla, Rust) and Dawn (Google, C++).
- The project’s reference stable version is webgpu-distribution v0.2.0, marked with the green icon in each finished chapter.
- The
-DWEBGPU_BACKEND=WGPUor-DWEBGPU_BACKEND=DAWNflag in CMake selects which native backend to compile. - Each chapter uses a four-color traffic light system to indicate how up to date it is against the WebGPU spec.
- The same C++ code compiles natively or to WebAssembly via Emscripten thanks to the “Building for the Web” appendix.
- The documentation is translated into English, French, Russian, Chinese, and Ukrainian.
- Advanced chapters like raytracing, shadows, and scene graph are still marked TODO, with no public delivery date.
Introduction
WebGPU emerged as the successor to WebGL to provide modern GPU access from JavaScript, but its internal design, a thin layer over Vulkan, Metal, and Direct3D 12, makes it just as useful outside the browser. Learn WebGPU for C++ teaches exactly that: using native WebGPU, with the same concepts of adapter, device, and command queue, to write graphics applications in pure C++.
The project is designed as a progressive course: it starts at “Project setup” and, once complete, will end with advanced techniques like raytracing and dynamic shadows.
What happened
The documentation organizes its chapters with a color-coded traffic light: green means the chapter uses the latest stable version of webgpu-distribution, currently at v0.2.0; yellow indicates valid content but with an older version of the API; orange marks chapters in progress, readable but incomplete; and red are sections that barely have a skeleton.
The fundamental building blocks (instance, adapter, device, command queue, window with GLFW, first color on screen, C++ wrapper) are already green. So is the entire input geometry section: buffers, vertex attributes, index buffer, and mesh loading from file. The compute shaders, image processing (mipmap generation, convolution filters), and RAII sections remain yellow or orange, a sign that the project is still active but incomplete in its more advanced chapters.
⚠️ Heads up: a chapter marked yellow may compile against an old version of wgpu-native and fail with the latest release. Before mixing code from different chapters, check which version of webgpu-distribution each one requires.
Context and history
WebGPU is the result of the work of the W3C GPU for the Web Community Group, which sought to replace WebGL, based on OpenGL ES and over a decade old, with something aligned with modern GPUs. The specification lives in the gpuweb/gpuweb repository, and its reference document is published by the W3C.
Behind every browser there’s a native WebGPU implementation written in C++ or Rust: Chrome uses Dawn, Google’s project written in C++; Firefox uses wgpu, written in Rust by Mozilla and exposed to C through bindings called wgpu-native. Learn WebGPU for C++ lets you choose which of the two to use as the native backend, something no browser exposes directly to developers.
The author himself documents this decision in the appendix “Teaching native graphics in 2023”: the goal isn’t to teach WebGPU as an end in itself, but to use it as a simplified vehicle for teaching GPU concepts (pipelines, buffers, shaders) that previously required dealing with Vulkan’s verbosity or DirectX’s closed ecosystem. That editorial decision explains why the guide devotes entire chapters to topics a browser tutorial takes for granted, like manually creating the drawing surface with GLFW.
Technical details: how native WebGPU works in C++
The startup flow for any program built with the guide is always the same: create a WebGPU instance, request an adapter (the available physical or virtual GPU), request a logical device from that adapter, and, with the device, obtain a command queue to send work to the GPU.
flowchart TD
A["WebGPU Instance"] --> B["Adapter (GPU)"]
B --> C["Logical Device"]
C --> D["Command Queue"]
D --> E[("Swap chain / surface")]The raw C API (webgpu.h) forces you to handle structs and pointers by hand. That’s why the guide introduces webgpu.hpp, a header-only wrapper that adds constructors, automatic destructors, and type overloading with RAII at no extra runtime cost.
// vanilla webgpu.h
WGPUInstanceDescriptor desc = {};
desc.nextInChain = nullptr;
WGPUInstance instance = wgpuCreateInstance(&desc);
if (!instance) {
std::cerr << "Could not create WebGPU instance" << std::endl;
return 1;
}// with the webgpu.hpp wrapper
#include <webgpu/webgpu.hpp>
wgpu::InstanceDescriptor desc = {};
wgpu::Instance instance = wgpu::createInstance(desc);
if (!instance) {
std::cerr << "Could not create WebGPU instance" << std::endl;
return 1;
}The second block does exactly the same thing as the first, but wgpu::Instance automatically releases its resources when going out of scope, without needing an explicit wgpuInstanceRelease.
| Backend | When to use it | Advantage | Limitation |
|---|---|---|---|
| wgpu-native (Rust, Mozilla) | Projects that prioritize portability and the same engine Firefox uses | Distributed as a precompiled library per release, lighter build | Some of Dawn’s advanced diagnostic tools aren’t available |
| Dawn (C++, Google) | Projects that already integrate Chromium or need strict validation | More detailed error messages during development | Heavier build, requires Google’s toolchain to compile from source |
Getting started
The project is built with CMake and uses GLFW as a cross-platform windowing layer. The steps are nearly identical across all three platforms, only how system dependencies are installed changes.
# Windows (with Visual Studio and CMake installed)
git clone --recurse-submodules https://github.com/eliemichel/LearnWebGPU-Code.git
cd LearnWebGPU-Code
cmake -B build -DWEBGPU_BACKEND=WGPU
cmake --build build --config Release
# macOS (with Homebrew)
brew install cmake ninja
git clone --recurse-submodules https://github.com/eliemichel/LearnWebGPU-Code.git
cd LearnWebGPU-Code
cmake -B build -G Ninja -DWEBGPU_BACKEND=WGPU
cmake --build build
# Linux (Debian/Ubuntu)
sudo apt install cmake ninja-build libglfw3-dev libxinerama-dev libxcursor-dev libxi-dev
git clone --recurse-submodules https://github.com/eliemichel/LearnWebGPU-Code.git
cd LearnWebGPU-Code
cmake -B build -G Ninja -DWEBGPU_BACKEND=WGPU
cmake --build buildChanging WGPU to DAWN in the -DWEBGPU_BACKEND flag recompiles the same code against Google’s implementation instead of Mozilla’s, without touching a single line of the program.
To confirm which backend ended up linked in the binary, request the adapter’s properties as soon as you get it:
WGPUAdapterProperties props = {};
wgpuAdapterGetProperties(adapter, &props);
std::cout << "Backend: " << props.backendType << std::endl;
std::cout << "GPU: " << props.name << std::endl;💡 Tip: if you’re planning to compile for the web later, start directly with the webgpu.hpp wrapper. The code ends up nearly identical to what Emscripten requires, and you’ll save yourself from rewriting the entire initialization.
Impact and analysis
For a developer in Latin America who wants to write their own graphics engine, native WebGPU solves a concrete problem: learning Vulkan from scratch involves hundreds of lines of configuration before drawing a single triangle. WebGPU, designed to be simpler than Vulkan but just as modern, reduces that friction without sacrificing access to compute shaders or programmable pipelines.
The guide also serves as a bridge to other uses: the same knowledge (adapter, device, buffers, bind groups) applies directly to engines like Bevy, written in Rust, or to integrations within scientific visualization applications, where it doesn’t always make sense to drag along a full game engine like Unity or Unreal just to render data.
The availability of the content in five languages (English, French, Russian, Chinese, and Ukrainian) also says something about where interest in native WebGPU is growing: outside the traditional circle of English-language engine development. For small teams in the region, this lowers the barrier to entry compared to documentation scattered across forums and loose GitHub examples.
What’s next
The chapters marked red still have no public delivery date: instanced drawing, shadow maps, tessellation, raytracing, scene graph, and deferred shading remain pending. The compute shaders section, key for simulations and GPU image processing, is orange and already covers mipmap generation and convolution filters.
The author actively requests feedback on each chapter marked as work in progress, and the repository accepts issues and pull requests directly on GitHub.
📖 Summary on Telegram: View summary
Try it yourself: clone LearnWebGPU-Code, run cmake -B build -DWEBGPU_BACKEND=WGPU && cmake --build build, and you’ll have a triangle on screen in under five minutes.
Frequently Asked Questions
Do I need to know Vulkan or Metal to use native WebGPU?
No. WebGPU abstracts those low-level APIs; the guide’s explicit goal is to teach GPU concepts without Vulkan’s verbosity.
Does the guide’s code run the same on Windows, macOS, and Linux?
Yes, it uses CMake and GLFW as a cross-platform windowing layer; only the system dependencies that need to be installed before compiling change.
Can I use the same code to compile to WebAssembly?
Yes, with Emscripten. The “Building for the Web” appendix documents the adjustments needed so the same native code also compiles for the browser.
What’s the difference between wgpu-native and Dawn?
They’re two independent implementations of the same WebGPU specification: wgpu-native is written in Rust by Mozilla, Dawn in C++ by Google. The guide lets you choose which to use with a CMake flag.
Is the guide finished?
No. Several advanced chapters (raytracing, shadows, scene graph) are still marked as TODO, though the core (window, geometry, uniforms, textures, basic lighting) is already complete.
What languages is it available in?
English, French, Russian, Chinese, and Ukrainian, in addition to the original version.
References
- Learn WebGPU for C++: the project’s official documentation, with all chapters and their progress status.
- eliemichel/LearnWebGPU on GitHub: source code for the documentation and channel for reporting issues.
- gfx-rs/wgpu-native: C bindings for Mozilla’s wgpu backend, one of the two backends supported by the guide.
- Dawn: WebGPU implementation in C++ maintained by Google, the other supported backend.
- W3C WebGPU specification: the reference standard that both backends implement.
- WebGPU API on MDN: documentation of the API as exposed in the browser.
📱 Do you like this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day.
Imagen destacada: Foto de Thomas Foster en Unsplash
0 Comments