wgpu icon indicating copy to clipboard operation
wgpu copied to clipboard

Dynamic WebGPU support detection

Open daxpedda opened this issue 2 years ago • 3 comments

Is your feature request related to a problem? Please describe. It's not really a problem at the moment, because no stable browser has WebGPU support turned on by default, yet. In the future, it would be great to be able to ship a single binary in WASM that supports both WebGL and WebGPU, depending on browser support. Currently this is impossible, as selecting the webgl crate feature automatically disables the WebGPU backend.

Describe the solution you'd like Detecting WebGPU support in the browser is fairly easy. So depending on it's availability, the correct backend should be chosen automatically by wgpu.

Describe alternatives you've considered The only solution I can come up with right now, is to have two binaries. Either detect support in the browser and load the appropriate WASM binary, or ship the appropriate binary by the server depending on the requesting browser.

daxpedda avatar Jun 23 '22 09:06 daxpedda

I don't think wgpu is responsible to handle the compilation process of multiple wasm binaries and browser feature detection. Although it's a feasible way to solve this issue, it should be handled by wgpu users.

Another way is we ship a new backend/implementation by wrapping up two kinds of implementations: the webgl one and webgpu one, pattern matching every api call at runtime. The downside is it actually contains two impls in one binary but we eventually can assume almost everyone uses webgpu impl.

mikialex avatar Jun 25 '22 17:06 mikialex

I don't think wgpu is responsible to handle the compilation process of multiple wasm binaries and browser feature detection. Although it's a feasible way to solve this issue, it should be handled by wgpu users.

Just to clarify, I totally agree that compiling multiple WASM binaries and how to handle that is not wgpus responsibility.

Feature detection is, in my opinion, wgpu already does this with the other backends on the desktop. Though I would already be happy if wgpu would allow users to do feature detection themselves.

Currently, as far as I'm aware, you can't even have WebGL and WebGPU support in the same binary, so even if users try to figure out what should be used, it's not possible to do with only one binary.

daxpedda avatar Jun 25 '22 17:06 daxpedda

Feature detection is, in my opinion, wgpu already does this with the other backends on the desktop.

Actually no, the wgpu backend selection is in compile time (through cargo feature). No such runtime detection.

you can't even have WebGL and WebGPU support in the same binary

Actually yes, that is what I said impl a new backend in wgpu that dispatch api calls to webgl/webgpu backend and does runtime feature detection. but I don't recommend it because from a long time perspective it's meaningless and boring

mikialex avatar Jun 28 '22 15:06 mikialex

Cc https://github.com/gfx-rs/wgpu/pull/3051.

daxpedda avatar Dec 16 '22 15:12 daxpedda

This would be very useful to be able to ship one version that detects WebGPU / WebGL2 support, and selects the backend as appropriate at runtime, plus exposes the features and limits as the wgpu API does. We'd love this for bevy.

superdump avatar Apr 15 '23 10:04 superdump

Just to chime in here: at Rerun we bundle a .wasm in our crates and pip packages. Having to bundle two separate .wasm would make those crates/packages much larger, so being able to switch between WebGL and WebGPU backends at runtime would be great.

emilk avatar May 16 '23 14:05 emilk

fyi I started looking into this, looks doable with a not-amazing-but-decent solution. Maybe still bringing up a PR before christmas 🤞

Wumpf avatar Dec 20 '23 12:12 Wumpf

Looks like Santa does read his mail! This feature would be incredible!

KewlKris avatar Dec 21 '23 04:12 KewlKris

started on it, but my holidays got a lot busier than I thought. Still intending to squeeze this in before the upcoming release though!

Wumpf avatar Jan 04 '24 12:01 Wumpf