Add wgpu crate features for backends

[daxpedda]

This adds crate features dx12 and metal to wgpu, which are enabled by default.
dx12 is no-op unless used on Windows.
metal is no-op unless used on MacOS/iOS.

Vulkan and OpenGL can currently not guarded by such a crate feature because it would mess up our defaults, e.g. a gles crate feature can not be enabled by default without also enabling if for MacOS and Windows, which is currently not what we want. See #3514 (comment) for more details.

Cc #3514.

[daxpedda]

I will add some documentation upon some initial feedback if we can proceed like this.

CI already tests --no-default-features, but doesn't test all sorts of crate feature combinations. Let me know if you want me to change/add something there.

[daxpedda]

I believe CI failure is unrelated.

[Wumpf]

I like where this is going (having an explicit feature for every platform backend) but I feel like we should first figure out what to do with Vulkan and Gl, otherwise this gets even more confusing for anyone trying to use wgpu and make a choice of feature flag.
Let's try finishing the discussion on #3514 first

[Wumpf]

Hmm maybe we could leverage https://docs.rs/cfg_aliases/latest/cfg_aliases/ to detangle things a bit further. I wouldn't mind having something like gles-linux, gles-windows, gles-mac (which implies angle iff we're on mac) and then we use config aliases in the code to distill the real gles feature.

What do you think?

[daxpedda]

Hmm maybe we could leverage https://docs.rs/cfg_aliases/latest/cfg_aliases/ to detangle things a bit further. I wouldn't mind having something like gles-linux, gles-windows, gles-mac (which implies angle iff we're on mac) and then we use config aliases in the code to distill the real gles feature.

What do you think?

This would be nice if we can solve the crate feature issue. Unfortunately, e.g. gles-linux = ["wgc/gles"] would still pull in all OpenGL dependencies on MacOS as well.

I described this problem in more detail in #3514.

[daxpedda]

I believe the CI failure is unrelated, but it's consistent, so I assume it's broken on trunk as well if we rerun it there.
See #4813 for the same CI failure.

[daxpedda]

Rebased after #4828.
Which also fixed the CI.

[Wumpf]

we talked about this PR (and the general feature story) on our weekly wgpu maintainers call. Key takeaways:

• reaffirming that we want to go the route of detailed opt-in features
• this PR is as-is an improvement despite unsolved vulkan/gles stuff
• going forward we want to rely on cfg_alias to reduce the complicated cfg expressions in the code (this also affects other stuff like the notoriously length cfg checks on send/sync on wasm)
• if possible we don't want the dummy.rs way of not having a backend, but the rationale makes sense so if we don't find another way let's go for it
  • maybe it's possible to fail instance creation before even instantiating any instance since everything already goes through DynContext 🤔 . I want to experiment with it before we commit to dummy.rs
• we don't have a great out-of-the-box solution for the vulkan/gles problematic; handing more things down to wgc is definitely on the table

-> Action points for this PR before landing:

• experiment with default-feature builds that don't rely on dummy.rs @Wumpf
• changelog update

-> Next steps after this PR

• iterate on GLES/Vulkan issue
• start cfg_alias'ing things to make cfg configs nicer

[daxpedda]

• if possible we don't want the dummy.rs way of not having a backend, but the rationale makes sense so if we don't find another way let's go for it

  • maybe it's possible to fail instance creation before even instantiating any instance since everything already goes through DynContext 🤔 . I want to experiment with it before we commit to dummy.rs

So I did remove the Dummy backend, instead I'm relying on hal::api::Empty to let everything compile. I believe right now it's not going to error on Instance::new(), but I'm not entirely sure where to implement returning the error.

1. Instance::new()
2. direct::Context::init()
3. wgc::Global::new()
4. wgc::Instance::new()

Let me know how you want me to proceed.

[daxpedda]

-> Action points for this PR before landing:

• experiment with default-feature builds that don't rely on dummy.rs @Wumpf

• changelog update

I covered both points now.
Whats still missing is figuring out where exactly we want to error out when no backend is available.

Otherwise the PR should be ready!

[Wumpf]

Ah nice, the empty feature makes actually a lot of sense, didn't think of that. What I actually meant is something along those lines
Wumpf@9c7f77068

Haven't tried it out yet, but this also gives a suggestion of when to panic in the stack: Right on wgpu::Instance. I.e. compared to the dummy solution we fail before the first call into the context. Also, I sketched this out to be information that's easily accessible to the user at compile time.
What do you think of that direction? (also my attempt to doc status quo in there surely has some mistakes?)

[daxpedda]

Panicking at wgpu::Instance looks fine to me. I don't think Instance::any_backend_feature_enabled() will actually be used by anybody? But it's a nice place to document all that, alternatively we can make the function private and put the documentation on Instance itself.

The whole hal::api::Empty is still necessary to make things compile, unless we want to put guards in all the functions in wgpu that use gfx_select!. E.g. your current solution in Wumpf@9c7f77068 won't compile with cargo build --target x86_64-apple-darwin -p wgpu --no-default-features.

(also my attempt to doc status quo in there surely has some mistakes?)

I left a comment here: Wumpf@9c7f77068#r135074861.
Except the crate features names it's great!

---

Let me know how you want to proceed, I'm happy to pull in your commit here.

EDIT: I made a commit with what I'm proposing. Happy to change it of course.

[Wumpf]

ah, thanks for fixing up the feature names and docs! Needing the hal::api::Empty makes a lot of sense, by basing off that version I meant to imply that it's included 😄

I'd really like any_backend_feature_enabled to be pub - I already can see that some library write wants to run all their tests in no-default-features and then wants a convenient runtime check to opt out of creating a wgpu instance, so I think it would be really useful to expose it. Unless you see some good reason better not to?

But I think that's all I have left to note. I'd would do a final pass over it tomorrow (or maybe later today) and then finally merge it in :)

[daxpedda]

Needing the hal::api::Empty makes a lot of sense, by basing off that version I meant to imply that it's included 😄

Ah, my bad! I didn't even check 😅

I'd really like any_backend_feature_enabled to be pub - I already can see that some library write wants to run all their tests in no-default-features and then wants a convenient runtime check to opt out of creating a wgpu instance, so I think it would be really useful to expose it. Unless you see some good reason better not to?

No, that sounds absolutely fine to me! I've done that now.

[Wumpf]

Confirming that all looks good now. Great step forward, thanks @daxpedda for being patient and going through these iterations!