Use wgpu WebGPU backend on supported browsers (instead of WebGL)

[controversial]

Describe the feature Provide a clear and concise description of your feature request. Why would this feature be useful? Does the feature involve the desktop build, the web build, or both?

On the web build, currently in the latest chrome Ruffle uses the wgpu webgl backend. This involves translating shader code on the fly and other performance pitfalls. Ruffle should be able to get better and more predictable performance in supported browsers by using a WebGPU backend (the API which wgpu is actually designed for) over a WebGL backend (the API wgpu has to do extra work to support).

Since the WebGPU API is available in the latest Chrome, wgpu should be configured to use it where supported.

[Dinnerbone]

We're unfortunately blocked by https://github.com/gfx-rs/wgpu/issues/2804 currently

[Lord-McSweeney]

Unfortunately AFAIK wgpu does not yet support having both webgl and webgpu on the same build. If Ruffle switched over to wgpu-webgpu, all the other browsers that do not yet support webgpu would be forced to fallback to Ruffle's much-less-supported webgl backend (not to be confused with wgpu's webgl backend).

[controversial]

What about making two .wasm builds, and then in the entrypoint (the javascript that loads the wasm bundle) choosing one? @Dinnerbone

if (navigator.gpu) {
  // initialize wasm build of Ruffle targeting WebGPU
} else {
  // initialize wasm build of Ruffle targeting WebGL
}

[torokati44]

I mean, technically we could build a third (or even fourth) module with wgpu set to WebGPU, and dispatch to one of them - much like we already do with WASM extensions... But I don't think it would be worth it in this case. Unless a benchmark proves me wrong...

EDIT: Hahh, you were quicker!

[Dinnerbone]

What about making two .wasm builds, and then in the entrypoint (the javascript that loads the wasm bundle) choosing one? @Dinnerbone

We already do this for vanilla wasm + extensions, so it'd end up with 4 wasm modules :(

[controversial]

it'd end up with 4 wasm modules

imo that could be worth exploring! but I’m not familiar with the tradeoffs therein (in terms of CI infrastructure costs, testing complexity, distribution, etc.)

I think it’s also the case currently that the browsers that support WebGPU are a strict subset of the browsers that support modern WASM extensions, so Ruffle would probably only need 3 separate builds (at least at first):

if (navigator.gpu && browserSupportsWasmExtensions) {
  // initialize wasm build of Ruffle targeting WebGPU with modern WASM
} else if (browserSupportsWasmExtensions) {
  // initialize wasm build of Ruffle targeting WebGL with modern WASM
} else {
  // initialize “baseline” wasm build of Ruffle
}

[torokati44]

That's only a +50% of deployment size! The second build cost us +100%!

[danielhjacobs]

Worth noting, if going the extra WASM module route, even if in 10 years everyone is using a browser that supports WebGPU, it would be impossible to remove the WebGL build unless https://github.com/gfx-rs/wgpu/issues/2804 were resolved because WebGPU is only available in secure contexts. This is different than the WASM extensions build which should theoretically be able to be removed eventually (whenever we're ready to stop supporting Safari <16.4, Chrome <91, and Firefox <89).

[torokati44]

Does the super-duper-secure mode of IE Edge accept all WASM extensions?

[n0samu]

Does the super-duper-secure mode of ~IE~ Edge accept all WASM extensions?

Seems like it does. When I enable it, Ruffle still says:

New Ruffle instance created (WebAssembly extensions: ON | Used renderer: wgpu-webgl)