web3d-runtime — the scene runs, on every GPU it meets, and you can prove how fast

three.js on WebGPU moves quickly: r186 throws where r180 warned, renamed the post-processing entry point, deprecated Clock, and still ships a WebGL2 backend underneath the same API. Most bugs here are silent — the scene renders, just wrongly. So this skill leads with the failures, then the patterns.

First action — inspect, then report

1. Versions. three, @react-three/fiber, @react-three/drei from package.json. Facts here are pinned to r186; on another release, check references/renderer-and-loop.md → Version notes before trusting a name.
2. Renderer. WebGPURenderer from three/webgpu, or the classic WebGLRenderer? Custom ShaderMaterial, RawShaderMaterial or onBeforeCompile anywhere? Those do not run on WebGPU (gotchas).
3. Loop. Who owns the frame: setAnimationLoop, R3F's useFrame, or several requestAnimationFrames (a bug — one clock per scene).
4. Evidence of speed. Is there any measurement (Inspector, timestamps, fps under load on the weakest target), or only a feeling?