v150 · WebGPU

Performance Comparison

The same animated scene rendered in two panels. Left: per-frame GPUBuffer.writeBuffer(). Right: setImmediateData(). Frame time and API call counts are tracked separately to show where immediates win.

Feature detection: checking…

Buffer write (traditional)

writeBuffer() + bind group per frame

Avg frame—
writeBuffer calls0
Bind groups created0

Immediate data (Chrome 150)

setImmediateData() — no buffer, no bind group

Avg frame—
writeBuffer calls0
Bind groups created0

Why immediates are faster for small, frequent data

Buffer write path: allocate/reuse a GPUBuffer, call writeBuffer() to map and copy data into it, create or cache a bind group that references that buffer, then set the bind group on the pass. The overhead compounds when data changes every draw call.

Immediates path: call setImmediateData() with a typed array. The driver sends the bytes directly in the command stream alongside the draw call — the same path GPU hardware uses for push constants in Vulkan / Metal / D3D12. No allocation, no bind group.

// ── Traditional: buffer + bind group per frame ──────────────
device.queue.writeBuffer(uniformBuf, 0, data); // allocates staging
renderPass.setBindGroup(0, bindGroup);         // descriptor lookup

// ── Immediates: direct, Chrome 150+ ─────────────────────────
renderPass.setImmediateData(0, data);  // straight into command stream
// No buffer. No bind group. No descriptor overhead.

see also

implementation reference

Need the exact API surface, compatibility boundaries, errors, lifecycle, and source links? Read the matching gendn reference ↗