Remix.run Logo
pjmlp 4 days ago

Outside of the browser the answer is middleware.

WGPU has to decide, either stay compatible with WebGPU, and thus be constrained by the design of a Web 3D API, or embrace native code and diverge from WebGPU.

slimsag 4 days ago | parent [-]

This is the right answer^

But even more, the level at which WebGPU exists (not too high level, not too low level) necessitates that if a native API graphics abstraction sticks with the WebGPU's API design and only 'extends' it, you actually end up with three totally different ways to use the API:

* The one with your native 'extensions' -> your app will only run natively and never in the browser unless you implement two different WebGPU rendering backends. Also won't run on Chromebook-type devices that only have GLES-era hardware.

* The WebGPU browser API -> your app will run in the browser, but not on GLES-era hardware. Perish in the verbosity of not having bindless support.

* The new 'compatability' mode in WebGPU -> your app runs everywhere, but perish in the verbosity of not having bindless, suffer without reversed-z buffers because the underlying API doesn't support it.

And if you want your app to run in all three as best as possible, you need to write three different webgpu backends for your app, effectively, as if they are different APIs and shading languages.

adrian17 3 days ago | parent [-]

> The WebGPU browser API -> your app will run in the browser, but not on GLES-era hardware. Perish in the verbosity of not having bindless support.

Note, regarding "GLES-era": WGPU does have a GLES/WebGL2 backend; missing WebGL1 is unfortunate, but at least it covers most recent browsers/hardware that happens to not have WebGPU supported yet.

(and there's necessarily some added overhead from having to adapt to GLES-style api; it's especially silly if you consider that the browser might then convert the api calls and shaders _again_ to D3D11 via ANGLE)

slimsag 3 days ago | parent [-]

I am referring primarily to the fact that a restricted subset of WebGPU is needed ('compatibility mode') to support D3D11 / GLES era hardware[0]

[0] https://github.com/gpuweb/gpuweb/issues/4266

flohofwoe 3 days ago | parent [-]

There's a *massive* difference in capabilities between GLES3.0 (e.g. WebGL2) and D3D11 though (GLES3.0 is more like 'late D3D9 era') ;)

And interestingly, WebGL2 in Chrome on Windows (which runs on top of D3D11) handily beats WebGPU in some of my tests (with setBindGroup being the bottleneck).