The performance comes mainly from a different programming model, not primarily from direct access to GPU resources (although the access is more direct than before).
The potentially expensive stuff has basically been moved out of the render loop, and into the initialization phase. For instance, when you create a shader in WebGL, that shader may be patched and recompiled internally when it is used for different situations (for instance different render target pixel formats). And "last minute" changes like this happen all over the place in GL and WebGL, because the GL model has so many flexible "knobs" that can be pressed at any time.
In WebGPU everything is "baked" at creation time. You may need to create more "state objects" upfront for all possible state combinations you need, and this creation may be more expensive than in the GL model, but once those state objects are created they are very efficient to use, and more importantly, they wont be "recompiled" during use.
It's a similar effect like having an unpredictable GC which can kick in at any time and produce frame spikes (like Javascript), versus not having a garbage collector at all (like WASM).
WebGPU also needs a lot fewer calls in the "hot path" compared to WebGL. When in WebGL you may need dozens of calls to change state between draw calls, in WebGPU it's only a handful.
If you are 100% careful, you can get equal performance with a good WebGL implementation, like ANGLE, and good user code. But this is very difficult, and requires very careful programming.
I built a WebGPU-like layer [0] for my 3D web application https://noclip.website , so I get some of the performance benefits today, under ANGLE, but WebGPU has these best-practices baked in, so everyone will see an increase.
Yes, WebGL requires some of the same tricks needed in the D3D9 era (batching and avoiding redundant state changes).
I'm quite confident that WebGPU will still provide a nice performance boost compared to carefully written WebGL, because the API is a better match to the underlying native APIs (D3D12, Vulkan and Metal), while ANGLE is basically a GLES2/3 "emulator" on top of D3D, and D3D11 is quite different from the GL programming model.
I use a limited version of WASM for decompression and texture decoding. Everything else is just being very careful to not create any objects in the hot path.
That sounds more like implimentation details of how opengl is used, rather than something 'different' from webgl. Wouldn't it be possible to just modify the webgl implimentation or flavor it for the performance seen here?
The potentially expensive stuff has basically been moved out of the render loop, and into the initialization phase. For instance, when you create a shader in WebGL, that shader may be patched and recompiled internally when it is used for different situations (for instance different render target pixel formats). And "last minute" changes like this happen all over the place in GL and WebGL, because the GL model has so many flexible "knobs" that can be pressed at any time.
In WebGPU everything is "baked" at creation time. You may need to create more "state objects" upfront for all possible state combinations you need, and this creation may be more expensive than in the GL model, but once those state objects are created they are very efficient to use, and more importantly, they wont be "recompiled" during use.
It's a similar effect like having an unpredictable GC which can kick in at any time and produce frame spikes (like Javascript), versus not having a garbage collector at all (like WASM).
WebGPU also needs a lot fewer calls in the "hot path" compared to WebGL. When in WebGL you may need dozens of calls to change state between draw calls, in WebGPU it's only a handful.