MVP no_std for wgpu-core

[bushrat011899]

Connections

• Contributes to Support no_std where possible (specifically for wasm32v1-none) #6826

Description

Adds no_std support to wgpu-core through 3 changes:

1. Use num-traits within timestamp_normalization to account for the floating point methods only available with std.
2. Make parking_lot optional by falling back to either std::sync::{Mutex, RwLock}, spin::{Mutex, RwLock}, or core::cell::RefCell based on selecting either parking_lot, std, spin, or no locking implementation.
   a. Note that spin was already in the lockfile via crossbeam-deque so this feature is "free"
   b. Note that RefCell is !Sync, so users should select spin in no_std environments. The use of RefCell as a fallback just allows compilation to succeed without any features enabled.
3. Make once_cell optional by falling back to core::cell:OnceCell.
   a. Note that once_cell is no_std compatible, but it requires activating the critical-section feature to access its implementation of OnceCell. Adding such a feature would therefore add critical-section to the lockfile, requiring thorough review due to its use of unsafe and extern "Rust". I believe it is a safe inclusion, but it can be avoided here so I'd rather save that quality of life feature for a follow-up. Users are still able to use once_cell with wgpu-core on no_std, they just have to enable once_cell/critical-section themselves.
   b. Note that core::cell::OnceCell is !Sync, so users should prefer to enable critical-section themselves.

To preserve existing behavior, the newly added parking_lot and once_cell features are enabled by default.

Testing

Added wgpu-core to the wasm32v1-none CI test.

Squash or Rebase?

Squash

Checklist

• Run cargo fmt.
• Run taplo format.
• Run cargo clippy --tests. If applicable, add:
  • --target wasm32-unknown-unknown
• Run cargo xtask test to run tests.
• If this contains user-facing changes, add a CHANGELOG.md entry.

[Wumpf]

really well documented both in code and PR description, thank you!

Would like to see some of it paraphrased in the feature docs to help users make the right choice.

Make once_cell optional by falling back to core::cell:OnceCell.
a. Note that once_cell is no_std compatible, but it requires activating the critical-section feature to access its implementation of OnceCell. Adding such a feature would therefore add critical-section to the lockfile, requiring thorough review due to its use of unsafe and extern "Rust". I believe it is a safe inclusion, but it can be avoided here so I'd rather save that quality of life feature for a follow-up. Users are still able to use once_cell with wgpu-core on no_std, they just have to enable once_cell/critical-section themselves.
b. Note that core::cell::OnceCell is !Sync, so users should prefer to enable critical-section themselves.

It irks me to add yet another feature just because of that, also given that once_cell is such a small and common crate. I think if we could we'd want to imply not enabling std to enable once_cell/critical-section.
Since this isn't possible I'd instead argue it's better to just keep always depending on once_cell and point out to users that they have to use once_cell/critical-section if they want Sync. That's already the case with the PR as-is, only that a user also has to enable the once_cell feature.
This would save us feature permutations, an extra code path and complexity for users. What do you think?

[bushrat011899]

It irks me to add yet another feature just because of that, also given that once_cell is such a small and common crate. I think if we could we'd want to imply not enabling std to enable once_cell/critical-section. Since this isn't possible I'd instead argue it's better to just keep always depending on once_cell and point out to users that they have to use once_cell/critical-section if they want Sync. That's already the case with the PR as-is, only that a user also has to enable the once_cell feature. This would save us feature permutations, an extra code path and complexity for users. What do you think?

Agreed! The ideal solution (that we can implement without changes to Cargo or rustc of course) would just be to make once_cell a required dependency and add a critical-section feature to enable Sync support. This can be done, but doing so adds critical-section to the Cargo.lock file, which would necessitate a review of that crate and its usage of unsafe (which it does use). I'm happy to refactor this PR to do this, but I'm unsure if adding critical-section to the lock file is a non-starter.

[bushrat011899]

I've split out the Mutex and RwLock changes into #7830, as they are a good fit for wgpu-types and would help with Naga and wgpu-hal too.

[Wumpf]

Sorry for the long lead times on these. It's been quite busy at work and I'm now out for a couple of days. Will likely get to it some point next week 🤞

[bushrat011899]

No stress! Thanks for your help 🙂