Track U

WebGPU, under the hood

The modern GPU API for the web: why it replaces WebGL, the device and queue, explicit buffers, baked render pipelines, WGSL, bind groups, command encoders, and compute shaders.

1. Why WebGPU exists: what was wrong with WebGL

   WebGPU is not WebGL 2.0 with nicer syntax — it is a fundamentally different shape built on a different generation of native GPU APIs. This lesson explains the three concrete problems with WebGL's design (a hidden global state machine, per-draw validation cost, and no compute), and how WebGPU's explicit pipelines, command buffers, and single queue answer each one — the mental model the rest of the module fills in.

   12 min
2. The device, the adapter, and the queue

   Every later WebGPU lesson assumes you already hold a device and a queue, so this lesson walks the handshake that produces them — feature-detecting navigator.gpu, requesting an adapter that represents one specific physical GPU, requesting a logical device from it, and arriving at the single queue through which all GPU work is submitted.

   12 min
3. Buffers and the explicit memory model

   WebGPU makes you allocate GPU memory explicitly and declare up front what a buffer is for — vertex data, a uniform, storage, a copy source — and that declared-once-and-immutable usage is what lets the driver place and validate the buffer optimally instead of guessing at every operation, the same "settle it in advance" philosophy the flagship lesson introduced for pipelines.

   13 min
4. Render pipelines: baking all the state up front

   A GPURenderPipeline bundles every piece of fixed draw state — both shaders, the vertex layout, primitive topology, depth/stencil, and blend — into one immutable object that WebGPU validates and translates to native code exactly once, at creation, which is the direct answer to WebGL's per-draw validation cost.

   13 min
5. WGSL: the shading language WebGPU speaks

   WebGPU rejects GLSL entirely and accepts only WGSL, a brand-new, strictly-typed shading language designed to be validated once by the browser and translated identically into Metal, Vulkan (SPIR-V), or D3D12 (HLSL) on whatever backend the machine actually runs.

   12 min
6. Bind groups: how resources reach the shader

   A render pipeline bakes in shaders and fixed state but not the actual data those shaders run against, so WebGPU groups the buffers, textures, and samplers a shader needs into bind groups validated once against a fixed bind group layout, letting an entire set of resources bind in a single call instead of WebGL's one-uniform-at-a-time approach.

   12 min
7. Command encoders and the queue: recording work, then submitting

   WebGPU never executes a draw the instant you call it — instead you record a whole batch of commands into a command encoder, finish it into an immutable command buffer, and submit that buffer to the queue in one call, which is the concrete mechanism behind the module's opening claim that WebGPU makes the CPU-to-GPU handoff cheap.

   13 min
8. Compute shaders: the GPU beyond graphics

   A compute shader is a general parallel program the GPU runs with no triangles and no pixels involved at all, reading and writing arbitrary storage buffers through the same bind groups and the same record-then-submit machinery the rest of this module built, which is why WebGPU's real reason to exist is compute rather than faster rendering.

   14 min