Hacker News Reader

Comment by devwastaken | Hacker News Reader

I'm unsure how they're getting better performance. Webgl is using opengl in a sort of sandboxed manner, does this webgpu approach bypass some checks or find different performant ways to do them? Afaik the biggest problem with gpu access from browsers is that the you instructions are not at all hardware secure. So everything has to be managed.

View on HN

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.

[0] https://github.com/magcius/noclip.website/blob/master/src/gf...

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.

Unbelievable performance. Bravo. You don't happen to be using WASM, do you?

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.

This is incredible.. I spent over an hour going through all the rooms of Banjo-Kazooie; I always loved that game. The performance is great!

Great job you did there..

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?

It seems to be structured more like Metal, DirectX 12 or Vulkan, so it's probably lower-level than WebGL, and reduces CPU load by lowering the cost of draw calls. These lower level APIs also make better use of multi core CPUs, and look at the huge performance differential between the other Macs and the likely high-core-count iMac Pro.

Their performance chart only lists Mac computers, so I assume under the hood this specific implementation is either translating WebGPU calls to Metal calls or at least the implementation is more like Metal. I suppose on other platforms, replace Metal with Vulkan or DirectX 12.

I just like reading about this stuff, I am not a graphics programmer, so I may be wildly off base.

One big way to improve on performance over WebGL is that WebGL exposes a slow layer on top of an already slow imperative API (OpenGL), while new-style APIs (Vulkan, DX12, Metal) are built around command buffers and state objects that you can assemble and then dispatch to the GPU in big chunks.

Think of it like the equivalent between calling memcpy(a++, b++, 1) in a loop and calling memcpy(a, b, n) instead.

It's mentioned in the article, GPU calls (and validation) are done up front instead of in the draw loop. If the gallery is accurate though, looks like there isn't any validation right now.

I just assumed that Apple exposed some API functionality in Webkit that allowed more efficient low-level usage of the GPU hardware. This leads me to believe that adoption of the WebGPU technology will probably fail to break out of the Apple ecosystem.

No, the other browser vendors are on board too. In the case of Apple, the API backend will be Metal. It'll be Vulkan or DX12 on other systems.

Or NVN, libGNM.

Reply on news.ycombinator.com