b2KIT

WebGPU Compute Playground

Write and run WebGPU compute shaders in WGSL with buffer visualization and timing output.

Tested tool guide Tested browser tools Checked August 16, 2026

What WebGPU Compute Playground does, with a checked example

You paste a WGSL compute shader and define one or more storage buffers as input, and the tool compiles and dispatches it against your browser's actual WebGPU adapter, then reads the result buffer back into a viewable grid alongside a measured execution time. The most common surprise is that nothing runs until a GPU device is granted by the browser itself - on a browser or machine without WebGPU enabled, the page reports that no adapter was found rather than silently falling back to a CPU simulation of your shader.

Worked example

A concrete input and expected output from the current implementation.

Input

Buffer: [1.0, 2.0, 3.0, 4.0] (f32)
Shader:
@group(0) @binding(0) var<storage, read_write> data: array<f32>;
@compute @workgroup_size(4)
fn main(@builtin(global_invocation_id) id: vec3<u32>) {
  data[id.x] = data[id.x] * 2.0;
}
Dispatch: (1, 1, 1)

Expected output

[2.0, 4.0, 6.0, 8.0]

workgroup_size(4) with a dispatch of 1 workgroup launches exactly 4 invocations, one per buffer element, each doubling data[id.x].

How the result is produced

1

Shader compilation and dispatch

Your WGSL source is compiled with device.createShaderModule and bound to the storage buffers you define, each becoming a @binding entry in a bind group. workgroup_size is set inside the shader while dispatch counts are set separately in the UI; a mismatch between the two is a frequent cause of buffer entries that silently stay unprocessed, not a compile-time error.

2

Readback and timing

Storage buffers can't be mapped for reading directly, so after the compute pass the tool copies results into a MAP_READ buffer and awaits mapAsync before rendering them as a typed-array grid (f32/u32/i32). The reported time normally spans submission through readback; it only isolates actual kernel execution if the browser exposes GPU timestamp queries, which isn't guaranteed.

Good uses

  • Prototyping a single compute kernel, like a reduction, blur, or matrix multiply, before wiring it into a larger WebGPU application
  • Checking that a chosen workgroup_size and dispatch count combination actually covers every element of a buffer, by reading the output grid
  • Comparing the rough execution time of two kernel variants on your own GPU without scaffolding a full WebGPU project

Limits and checks

  • WebGPU availability depends on browser and OS; where it isn't enabled the tool reports no adapter found rather than emulating a result, so an empty output can mean 'unsupported here', not 'shader is broken'
  • The displayed timing usually includes CPU-side submission and buffer-readback overhead alongside kernel execution unless timestamp-query support is present, so it isn't a pure GPU-time measurement by default
  • WGSL struct layout rules (for example 16-byte alignment on vec3 fields) can make a buffer look correctly filled in the visualization while still being misaligned relative to what the shader code actually reads

Common questions

Will this run on my phone or an older laptop?

Only if the browser exposes navigator.gpu and can obtain a GPU adapter. WebGPU support differs by browser, OS, and device, and it is still rolling out unevenly; on unsupported combinations the tool reports no adapter found instead of falling back to a CPU-based simulation.

Can I load a texture instead of a plain buffer?

The tool is built around storage buffers for compute input and output, and its visualization and timing display are designed around buffer contents, not sampled textures. An image-processing kernel needs to read and write buffers rather than texture bindings to work here.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools