-
Notifications
You must be signed in to change notification settings - Fork 954
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
Make wgpu-core
users responsible for choosing back ends.
#3254
Conversation
3eeef01
to
3a782dc
Compare
a085cbc
to
6124f8e
Compare
Codecov Report
@@ Coverage Diff @@
## master #3254 +/- ##
==========================================
- Coverage 65.60% 64.98% -0.63%
==========================================
Files 82 82
Lines 39468 39474 +6
==========================================
- Hits 25894 25652 -242
- Misses 13574 13822 +248
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
ac6e85f
to
44268ce
Compare
44268ce
to
6100d15
Compare
db23fc9
to
25f66c0
Compare
Give `wgpu-core` a set of features parallel to those in `wgpu-hal`, and pass them through. Within `wgpu-core`, use features to decide when back-end-specific code is enabled. Move the platform-specific dependencies that select appropriate backends as high as possible in the dependency DAG: `wgpu` and `deno_webgpu`. Since all the `gfx_select` macros now use configuration predicates of the same form, simplify those macros and their uses. Similarly, let `wgpu-core`'s users decide whether to support renderdoc and emscripten, not `wgpu-core` itself. In wgpu-hal give a more helpful error when no backends are enabled. Don't select backends in CI that the current platform can't handle. Before this change, backend selection is done by target dependencies in `wgpu-core/Cargo.toml`, giving `wgpu-core` users no way to override those choices. (Firefox doesn't want the GLES back end, for example.) There doesn't seem to be any way to have a crate select backends based on target architecture and OS that users of that crate can still override. The default features can't be selected based on the target, for example. That implies that we should do the selection as late in the dependency DAG as feasible. Having `wgpu` (and `wgpu-core`'s other dependents) choose backends seems good enough.
25f66c0
to
0a71de5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!
I have ideas to build on this on how we can expand this to the users and have non-platform specific features.
When building for WebAssembly using the WebGPU backend, don't try to build the entire workspace. wgpu-hal isn't meant to be used in this case, and since #3254, it complains if no backends have been explicitly selected. Instead, pass `--package wgpu` when doing the WebGPU-backend build.
When building for WebAssembly using the WebGPU backend, don't try to build the entire workspace. wgpu-hal isn't meant to be used in this case, and since gfx-rs#3254, it complains if no backends have been explicitly selected. Instead, pass `--package wgpu` when doing the WebGPU-backend build.
NOTE: This PR extends #3253.
Before this change, backend selection is done by target dependencies in
wgpu-core/Cargo.toml
, givingwgpu-core
users no way to override thosechoices. (Firefox doesn't want the gles back end, for example.)
There doesn't seem to be any way to have a crate select backends based on target
architecture and OS that users of that crate can still override. The default
features can't be selected based on the target, for example. That implies that
we should do the selection as late in the dependency DAG as feasible. Having
wgpu
(andwgpu-core
's other dependents) choose backends seems good enough.Draft, because there are still some issues around the renderdoc feature. But comments are welcome!
Checklist
cargo clippy
.RUSTFLAGS=--cfg=web_sys_unstable_apis cargo clippy --target wasm32-unknown-unknown
if applicable.Connections
Link to the issues addressed by this PR, or dependent PRs in other repositories
Description
Describe what problem this is solving, and how it's solved.
Testing
Explain how this change is tested.