How Do I Verify the Native WebGPU Backend?

Verify the initialized renderer

The official WebGPURenderer manual states that the renderer can select WebGPU or fall back to a WebGL 2 backend. navigator.gpu shows that the browser exposes WebGPU, but it does not show which backend a particular renderer instance selected. renderer.isWebGPURenderer identifies the renderer class, not the active backend.

For the supported r185 target, initialize before inspecting the backend:

import * as THREE from 'three/webgpu';

const renderer = new THREE.WebGPURenderer({ antialias: false });
await renderer.init();

const backendManifest = {
  revision: THREE.REVISION,
  isWebGPUBackend: renderer.backend.isWebGPUBackend === true,
  compatibilityMode: renderer.backend.compatibilityMode,
  outputBufferType: renderer.getOutputBufferType(),
  samples: renderer.samples,
  deviceLimits: renderer.backend.device?.limits ?? null,
  rendererInfo: renderer.info
};

if (!backendManifest.isWebGPUBackend) {
  throw new Error('This route requires the native WebGPU backend.');
}

Record the result with the browser, device, installed package version, output format, and required features. A boolean without its environment is weak evidence because it cannot explain later capability or device-specific failures.

Proof

The official WebGPURenderer manual documents automatic WebGL 2 fallback and asynchronous initialization.
Upstream issue #31381 documents the community confusion created by a renderer class that can target different backends.
The repository's validation harness evidence records native backend identity with its capture artifacts.
scripts/capture-via-cdp.mjs rejects a capture session that lacks native WebGPU backend proof.

What the flag does not prove

It does not prove that every feature required by the scene is available.
It does not prove correct pixels, lifecycle stability, GPU timing, or performance on another device.
Compatibility mode must be classified separately when its limits affect the workload.
Backend access and field names are revision-sensitive. This answer is reviewed for Three.js 0.185.1.

If the flag is false, follow the WebGPURenderer migration guide and report the fallback or blocker accurately. Then confirm the supported revision and use the readback troubleshooting answer only after backend identity is known.

Question provenance

This operational question is derived from upstream issue #31381, which documents confusion about WebGPURenderer's multi-backend behavior but does not ask for this exact verification procedure. Issue #28898 is technical background only. This is upstream engineering evidence, not customer evidence. Source first observed 2025-07-07; last checked and answer reviewed 2026-07-16.