> implementing missing features so that they can ship WebGPU support in Firefox

Sounds like WGPU, the project, should be detached from Firefox?

To me the priority of shipping WGPU on FF is kind of mind-boggling, as I consider the browser irrelevant at this point in time.

▲

brookman64k 10 months ago | parent | next [-]

Just to avoid potential confusion: WebGPU and WGPU are different things.

	▲	slimsag 10 months ago \| parent [-]
		(a) WebGPU -> Specification or browser API (b) WGPU, gfx-rs/wgpu, wgpu.rs -> Rust crate implementing WebGPU (c) wgpu -> the prefix used by the C API for all WebGPU native implementations. (d) 'wgpu' -> a cute shorthand used by everyone to describe either (a), (b), or (c) with confusion.

▲

littlestymaar 10 months ago | parent | prev | next [-]

The irrelevant browser is the one paying developers to build wgpu though…

▲

pjmlp 10 months ago | parent | prev | next [-]

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 10 months 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 10 months 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 10 months 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 10 months 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).

▲

adastra22 10 months ago | parent | prev [-]

Is WGPU even a Mozilla project? I think he is just saying that those paid developers (paid by Mozilla) have that priority, and everyone else is volunteer. Not that WGPU is a Firefox project.

	▲	kookamamie 10 months ago \| parent \| next [-]
		Thanks, I checked the WGPU project's roots and you're right - it's not Mozilla's project, per-se.
	▲	jblandy 10 months ago \| parent \| prev [-]
		Yes, this.