WebGPU
The modern low-level graphics-and-compute API for the browser — the successor to WebGL. Exposes contemporary GPU features (compute shaders, explicit memory management, bindless resources) to JavaScript/WebAssembly, with its own shading language WGSL (Rust-like, vs WebGL's GLSL). By 2026 it sits around ~82–87% global support (Chrome/Edge/Opera/Samsung since v113, Safari 26.0+; Firefox the notable holdout). The rendering-backend node the spoke's web engines reference but never paged.
The API model
Per mdn-webgpu (MDN, mirroring the W3C spec): an app reaches the GPU through navigator.gpu → a
GPUAdapter (a physical GPU + driver) → a GPUDevice (a logical, isolated device per app), with the
browser implementation riding on the native API beneath — Direct3D 12, Metal, or Vulkan. Work runs as
either a render pipeline (@vertex/@fragment stages) or a compute pipeline, and MDN is explicit
that GPGPU is first-class, not bolted on — the clean break from graphics-only WebGL. It requires a
secure context (HTTPS), and an optional compatibility mode maps a subset onto older backends
(OpenGL ES 3.1 / D3D11). MDN still flags it as not Baseline (absent from some widely-used browsers),
matching the Firefox-holdout note above.
Why it matters to the spoke — the rendering-backend dimension
Every web-graphics tool here names its backend, so WebGPU vs WebGL is a real axis that separates modern from legacy web rendering: Three.js, PixiJS, Babylon.js, and PlayCanvas all render on WebGL and WebGPU, with WebGPU the path to console-quality performance in the browser. So the web-graphics matrix has, beneath its library/engine split, a shared backend layer: the engines compete partly on how well they exploit WebGPU.
The layer between the API and the engines (2026-08-28)
The matrix above jumps straight from navigator.gpu to a scene graph. vgpu is the first source
here on the rung in between: a TypeScript library that wraps WebGPU with typed WGSL module imports and
an explicit frame API, and refuses implicit scene-graph state on purpose. So the stack now reads
WebGPU → thin typed wrapper → engine, and the middle rung has one instance.
And a fourth position, from outside the browser (2026-08-31). bgfx treats WebGPU as one of nine rendering backends — beside Direct3D 11/12, Metal, Vulkan, OpenGL and WebGL 2.0 — and supports it only through Dawn Native, Chrome's implementation compiled as a native library. So WebGPU appears here twice over: as the browser's API, and as a portable native API that an engine-agnostic renderer can target off the web entirely. The web-graphics matrix's backend layer is not web-only.
It also shows a use of WebGPU the engines do not need: because the API is a spec rather than a browser feature, the same code runs against Dawn in headless Node and against a deterministic software mock in a test suite. That is WebGPU as a portable target, not as a browser capability, and it is the practical answer to the Firefox-holdout problem above for anything that does not have to run in a browser.
Cross-spoke seam (a bridge out of the island)
WebGPU is not only graphics — its compute shaders make it a general-purpose in-browser GPU compute API, used for client-side AI inference (running models in the browser). That is a live seam to llm-inference-wiki (browser-side model serving) and a rare concrete bridge between game-engines and the LLM stack: the same API the web engines render with also runs neural nets client-side. A candidate cross-spoke thread if browser-inference sources arrive.
Related
three-js · pixijs · babylonjs · playcanvas · mdn-webgpu · synthesis