home/ modules/ building-a-webgpu-render-pipeline

Building a WebGPU render pipeline from scratch

  • learner can initialize a WebGPU adapter, device, and configured canvas context
  • learner can record and submit command buffers with render passes, pipelines, and bind groups
  • learner can lay out vertex buffers and issue draw calls inside a render loop

Build a from-scratch WebGPU app that initializes the device, configures the canvas, and drives a render loop clearing and drawing triangles via a render pipeline, vertex buffer layout, bind group, and draw call.

Every browser-based visual rig for a live set — audio-reactive geometry, generative backdrops, projection material — ultimately stands on one skeleton: a WebGPU app that owns a device, feeds a pipeline, and pushes frames. This module builds that skeleton with no framework between you and the GPU, so that when a library abstracts it away later, you still know exactly what a dropped frame or a black canvas means mid-performance.

The arc starts fully supported: get pixels on screen with nothing but a cleared canvas. The two-step adapter-then-device handshake and canvas context configuration get you a device; the render pass with loadOp ‘clear’ proves the whole record-then-submit chain works before any geometry exists. That’s the first exercise — a solid colour, driven by a command encoder you built yourself. From there, scaffolding drops away in layers: declare triangle vertices in a Float32Array, describe their byte layout with a vertex buffer layout, upload them via a GPUBuffer, and wire it all into a render pipeline whose fragment targets match the canvas format. Clip space keeps you honest about where those vertices actually land. The capstone removes all support: a from-scratch app whose render loop re-records and re-submits a fresh command buffer every frame, drawing triangles through pipeline, bind group, and draw call.

Every required atom is load-bearing for that capstone — skip the format-matching rule or the bind-group mechanics and the app validates but renders nothing, or fails validation outright. The supporting atoms open the doors you’ll walk through next: uniforms turn this static skeleton into a time- and audio-driven instrument, instancing scales one triangle into a thousand, and the rasterizer’s vertex-to-fragment handoff explains why interpolated colour gradients appear for free.

Runnable examples

Generated from the context/ instrument corpus by concept (redistributable idioms only). Do not edit — regenerate with gen-module-examples.mjs.

solid-fill

[0.1, 0.1, 0.2] >> rgb

punctual-0017 · CC0-1.0

solid(0.1, 0.1, 0.2).out()

hydra-0171 · MIT

Atoms in this module

Required — these gate the capstone

WebGPU has three shader stages: vertex computes positions, fragment computes colors, compute runs a function N times
Concept L1 Foundations GK
WebGPU initialization requires requesting an adapter then a device in two async steps
Procedure L2 First instrument G
A WebGPU canvas context must be configured with a device and the device's preferred texture format before drawing
Procedure L2 First instrument G
WebGPU draws or computes via a pipeline that chains shaders to GPU resources through bind groups
Concept L2 First instrument GK
WebGPU commands are recorded into a command buffer and submitted to a queue — the GPU does nothing until submit() is called
Concept L2 First instrument G
A WebGPU render pass with loadOp 'clear' and a clearValue fills the attached texture with a solid RGBA color
Procedure L2 First instrument G
A GPURenderPipeline bundles shader modules, vertex buffer layout, and render targets into a fixed, reusable draw configuration
Concept L2 First instrument G
A render pipeline's fragment targets array must match the texture format of the color attachments used in the render pass
Concept L2 First instrument G
A GPUVertexBufferLayout declares the byte stride and attribute format of each vertex, linking buffer data to shader @location slots
Concept L2 First instrument G
Vertex data passed to WebGPU must live in a JavaScript TypedArray matching the expected GPU numeric format
Concept L2 First instrument G
GPU-side data is stored in GPUBuffers created with size and usage flags, then populated via device.queue.writeBuffer
Procedure L2 First instrument G
A WebGPU draw call requires setPipeline, setVertexBuffer, and draw called in sequence on a render pass encoder
Procedure L2 First instrument G
A WebGPU render loop re-records and re-submits a command buffer each frame; requestAnimationFrame or setInterval drives the cadence
Procedure L2 First instrument G
A bind group links GPU resources to shader binding points and must be created from a layout and set before each draw or dispatch call
Concept L2 First instrument G
WebGPU clip space maps the canvas to a fixed [-1, +1] range on both axes regardless of canvas pixel dimensions
Concept L2 First instrument G

Supporting — enrichment, not gating

The vertex shader transforms each vertex to clip space; the rasterizer then runs the fragment shader once per covered pixel
Concept L2 First instrument G
A WebGPU uniform is a shader global held constant for every invocation of one draw call
Concept L2 First instrument GK
A uniform buffer holds per-draw-call constants visible to all shader invocations, unlike per-vertex attributes or writable storage buffers
Concept L2 First instrument G
GPU instancing draws multiple copies of the same geometry in one draw call, using @builtin(instance_index) to differentiate each copy
Concept L2 First instrument G