5 ms·

> 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 prio

> 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.

adastra22 2y ago
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.
- jblandy 2y ago
  Yes, this.
- kookamamie 2y ago
  Thanks, I checked the WGPU project's roots and you're right - it's not Mozilla's project, per-se.
littlestymaar 2y ago
The irrelevant browser is the one paying developers to build wgpu though…
brookman64k 2y ago
Just to avoid potential confusion: WebGPU and WGPU are different things.
- emidoots 2y ago
  (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.
pjmlp 2y 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 2y ago
  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 2y ago
    > 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 2y ago
      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 https://github.com/gpuweb/gpuweb/issues/4266

adastra22 2y ago

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.

jblandy 2y ago
Yes, this.
kookamamie 2y ago
Thanks, I checked the WGPU project's roots and you're right - it's not Mozilla's project, per-se.

littlestymaar 2y ago

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

brookman64k 2y ago

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

emidoots 2y ago
(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.

pjmlp 2y 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 2y ago
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 2y ago
  > 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 2y ago
    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 https://github.com/gpuweb/gpuweb/issues/4266