Three.js WebGPU: WebGPURenderer, TSL & What Works Today

WebGPURenderer lives in three/webgpu rather than the main three entry point, alongside TSL's exports in three/tsl. The setup is otherwise identical to WebGLRenderer: same setSize, same domElement to append, same render loop.

One important difference: WebGPURenderer's initialization is asynchronous (it negotiates a GPU device), so call await renderer.init() before your first render if you need to guarantee it's ready. In practice most setups just start the render loop and let the first frame or two resolve naturally, but init() matters if you're doing anything (like reading back a render target) that depends on the renderer being fully ready.

TSL (Three.js Shading Language) is a JavaScript node system for authoring materials and compute shaders. Instead of writing a GLSL string, you compose small functions, such as color(), uv(), texture(), mix(), and sin(), into a graph assigned to a node material's properties (colorNode, positionNode, normalNode, etc.).

The graph compiles to WGSL when rendering on WebGPURenderer and to GLSL when the same material falls back to WebGLRenderer: one shader definition, both backends, no manual porting. This is the single biggest practical reason to adopt TSL even before you need WebGPU-specific features like compute shaders: it future-proofs custom shader code against the renderer choice.

Porting an existing GLSL ShaderMaterial to TSL is mechanical but not automatic. There's no reliable one-click converter for arbitrary GLSL, though the site's GLSL to TSL converter tool handles common patterns and is a useful starting point. The general shape of a manual port:

1. Replace uniforms object entries with TSL uniform() calls.
2. Replace vertex shader logic assigned to gl_Position with a positionNode on a node material.
3. Replace fragment shader logic assigned to gl_FragColor with colorNode (and emissiveNode, opacityNode, etc. as needed).
4. Varyings (data passed from vertex to fragment shader in GLSL) become plain TSL expressions shared between the position and color nodes. TSL handles the interpolation automatically.

Simple effects (a color gradient, a scrolling UV, a sine-wave displacement) port in a few lines. Complex multi-pass or heavily branched shaders take longer and are a good candidate to budget real time for, not a quick afternoon task.

The ecosystem is catching up but isn't fully there. Before committing to WebGPURenderer for a specific project, check:

• Third-party post-processing passes written against the older EffectComposer/GLSL pipeline may need a WebGPU-compatible replacement or a TSL rewrite. Check each pass's own documentation.
• Community libraries built directly on WebGLRenderer internals (rather than the public Three.js API) can break on WebGPURenderer, since the internal renderer architecture differs.
• Browser coverage is still catching up. See the WebGPU vs WebGL guide for current support, though WebGPURenderer's automatic WebGL fallback means this is a graceful-degradation concern, not a hard blocker.

The core Three.js API surface (geometries, loaders, built-in materials, controls, the scene graph) all work identically on both renderers.