WebGPURenderer WebGL2 fallback and async init leave backend parity unresolved

WebGPURenderer exposes the same scene-graph API as WebGLRenderer and transparently falls back to a WebGL2 backend when navigator.gpu is unavailable, but the project has not settled on WebGPU as the default production path. A project that needs compute shaders and storage buffers on the WebGPU path, yet also depends on the classic EffectComposer/Pass post-processing chain tied to WebGL render targets, faces an unresolved backend decision.

The uncertainty is compounded by initialization and configuration differences. renderer.init() is asynchronous on the WebGPU path and must be awaited before the first render, whereas the WebGLRenderer constructor is synchronous. The WebGPURenderer constructor also accepts an option to force the WebGL2 backend even when WebGPU is available, but the exact option naming is version-sensitive and the WebGPU API surface has changed across releases.

Because browser WebGPU availability varies by platform and flags, a silent fallback can hide missing features during testing, and the two backends can produce different output for the same scene. Which documented migration notes or runtime checks should be consulted to confirm current backend selection behavior and option naming for a pinned three version? How should post-processing parity and node-material coverage be verified when the same scene must run on both backends without assuming pixel-identical results?