Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dynamic WebGPU support detection #2804

Closed
Tracked by #3674
daxpedda opened this issue Jun 23, 2022 · 9 comments · Fixed by #5044
Closed
Tracked by #3674

Dynamic WebGPU support detection #2804

daxpedda opened this issue Jun 23, 2022 · 9 comments · Fixed by #5044
Labels
api: webgpu Issues with direct interface with WebGPU area: api Issues related to API surface help required We need community help to make this happen. type: enhancement New feature or request

Comments

@daxpedda
Copy link
Contributor

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.

@cwfitzgerald cwfitzgerald added type: enhancement New feature or request help required We need community help to make this happen. area: api Issues related to API surface api: webgpu Issues with direct interface with WebGPU labels Jun 23, 2022
@mikialex
Copy link

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.

@daxpedda
Copy link
Contributor Author

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.

@mikialex
Copy link

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

@daxpedda
Copy link
Contributor Author

Cc #3051.

@superdump
Copy link
Contributor

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.

@emilk
Copy link
Contributor

emilk commented May 16, 2023

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.

@Wumpf
Copy link
Member

Wumpf commented Dec 20, 2023

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

@KewlKris
Copy link

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

@Wumpf
Copy link
Member

Wumpf commented Jan 4, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api: webgpu Issues with direct interface with WebGPU area: api Issues related to API surface help required We need community help to make this happen. type: enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants