webgpu-native-examples is a set of single file C examples that run the same code on Linux and in a browser

One file per example, two targets from the same source

The project is a collection of open-source C99 examples for WebGPU using Dawn, Google's cross-platform WebGPU implementation. Two properties define the whole design.

The first is that each example is a single self-contained C source file. There is no shared framework, no helper library to learn and no project template. You open one file and you can read the entire program, which for an API with as much ceremony as WebGPU is the difference between understanding it and being lost in it.

The second is that the same source targets both native desktop on Linux and WebAssembly through WAjic. That is an unusual and valuable property, because it means the example is not a toy that only works in one environment. The native build gives you a real GPU on your machine and a debugger, and the WebAssembly build gives you a live demo anyone can open in a browser.

There is a live WebAssembly demo published to GitHub Pages, and the pages workflow badge in the README header shows the build and deploy is automated.

The browser requirement is stated plainly: the WebAssembly examples require a browser with WebGPU support, Chrome 113+ or Edge 113+, and Firefox and most mobile browsers are not yet supported.

The primary language is C, the licence is Apache-2.0, and the last push was on 2026-10-19 with no GitHub releases published.

What the architecture diagram actually shows

The README carries a large mermaid diagram that maps the WebGPU object model, and it is the most compact explanation of the API available here.

The first section is surface and driver initialisation. An HTMLCanvasElement context connects to a GPUDevice, which connects to a GPUAdapter, which in turn reaches native drivers for D3D12, Metal and Vulkan. The adapter is the step that picks a backend, which is the abstraction WebGPU is built on.

The second section is resource and pipeline setup. A WGSL shader source becomes a GPUShaderModule, a GPUBindGroupLayout produces a GPUBindGroupLayout and a GPUBindGroup, and a GPUPipelineLayout produces both a GPURenderPipeline and a GPUComputePipeline. The render state configuration sits alongside as vertex, fragment, primitive and depth/stencil states.

The third section is command recording, and the diagram has a correction note in it: pass encoders must explicitly call end to transfer control back to the GPUCommandEncoder. That is the sort of detail that is easy to miss in the specification and impossible to debug without understanding it.

The fourth section is execution. A GPUCommandEncoder finishes into a GPUCommandBuffer, which is submitted to a GPUQueue.

Reading the diagram is worth a few minutes before reading any code, because the naming in WebGPU is dense and the diagram shows which objects contain which.

The example catalogue, by category

The README's table of contents lists the examples by group, and the grouping is a good map of what the API can be pushed to do.

The Basics group covers the fundamentals, glTF covers loading a scene format, and Advanced covers the harder cases. Performance is its own group, which is a good sign for a project that treats the API as a production surface rather than a demo. Physically Based Rendering and Deferred each have a group, since both are large enough to need their own shading and lighting setup.

Compute Shader is a separate group, covering the compute side of WebGPU rather than the graphics side. User Interface covers rendering UI elements, Effects covers post-processing style work, and Misc catches the remainder.

The repository layout matches. There is a src/ directory for the examples, wasm/ for the WebAssembly side, assets/ for the resources the examples load such as glTF models, screenshots/ for the images in the README, doc/ for documentation and images, external/ for the external dependencies, and docker/ for the containerised build. The root holds CMakeLists.txt, CMakePresets.json, a build.sh, a .clang-format for consistent formatting, and a CLAUDE.md.

The presence of a CLAUDE.md at the root and the .github/ directory indicate a repository with an active contribution process rather than a personal scratchpad, and the CMakePresets.json suggests the build is meant to be configured rather than hand-tuned.

Getting the sources and building against Dawn

The repository contains submodules for the external dependencies, so a fresh clone has to be recursive.

$ git clone --recursive https://github.com/samdauwe/webgpu-native-examples.git

Existing checkouts are updated with the submodule command instead.

$ git submodule update --init

The native build uses Dawn, Google's open-source WebGPU implementation, and the prerequisites depend on the distribution. For Fedora the README lists the packages.

sudo dnf install cmake ninja-build clang lld \
  libXi-devel libXcursor-devel libXinerama-devel libXrand

The shape of that list is a fair summary of what a native WebGPU build needs on Linux: CMake and Ninja for the build, Clang and lld for the compiler and linker, and the X11 development headers for the windowing and input that a native example needs to present a surface.

The README table of contents also lists sections for building for WebAssembly with WAjic and for building with Docker, and the repository has a docker/ directory for the latter. There is a separate chapter on running the examples and one on the project layout.

The supported platform list in the README is short and specific: GNU/Linux. That is the only entry, and it is worth knowing before you plan around these examples.

Where webgpu-native-examples is the wrong choice

Four cases argue against it.

The first is a platform other than Linux. The supported platforms section lists GNU/Linux and nothing else. Dawn itself is cross-platform and the examples are plain C, but the build recipe, the windowing and the input handling shown here are for a Linux workstation, and porting is your work.

The second is if you want a WebGPU framework rather than examples. Each file is self-contained by design, which means there is no shared abstraction to build on. If your goal is a reusable rendering layer, this repository gives you patterns to copy and nothing to import.

The third is a browser support matrix that includes Safari or Firefox. The README states the WebAssembly examples need Chrome 113+ or Edge 113+ and that Firefox and most mobile browsers are not yet supported, so the published demo does not reach everyone on your team.

The alternative in the same direction is the WebGPU specification samples themselves, or the browser's own API documentation and demos. The difference in approach is that those show the API in the environment it was designed for, a browser, while this repository shows the same API driven from C on a native GPU with a real window, which is the more useful shape if you are building a native application and want the rendering code to be shared with a web build. WAjic is what makes that sharing possible here, and it is the specific idea that would otherwise be missing from the comparison.

Editorial conclusion

webgpu-native-examples fits a programmer who wants to see a complete WebGPU setup in one readable file, whether they are learning the API or checking how Dawn wires things together on Linux. It does not fit a team on Windows or macOS, since the supported platform list names GNU/Linux only, and it does not fit anyone who wants a WebGPU library to depend on, since these are examples rather than a framework. Clone with `git clone --recursive`, build against Dawn with the documented Fedora packages, and read `src/` for the examples themselves, grouped in the README table of contents under Basics, glTF, Advanced, Performance, Physically Based Rendering, Deferred, Compute Shader, User Interface, Effects and Misc.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. samdauwe/webgpu-native-examples on GitHub