MVP `no_std` for `wgpu-core` #7746

bushrat011899 · 2025-06-02T02:30:56Z

Connections

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

Description

Adds no_std support to wgpu-core through 3 changes:

Use num-traits within timestamp_normalization to account for the floating point methods only available with std.
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.
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?

wgpu-core/Cargo.toml

wgpu-core/src/lock/vanilla.rs

bushrat011899 · 2025-06-09T23:45:05Z

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 · 2025-06-19T01:45:14Z

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 · 2025-06-19T14:15:57Z

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 · 2025-06-19T21:31:23Z

No stress! Thanks for your help 🙂

Wumpf · 2025-06-25T07:24:13Z

finally getting coming back to this after a break! First of all, thanks for all the added docs, looks great now.
I'd like to discuss ways to reduce amount of features a bit more though, after all this quite significantly increases the number of permutations and thus technically the number of versions that ought to be tested.

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.

Not entirely sure I'm following it all the way: right now the PR exposes once_cell as a separate feature and expects anyone that wants to use no_std to do once_cell/critical-section if they want resource pool to be Sync. In other words there's a way to get to Sync but it requires --features once_cell/critical-section. If we were to drop once_cell feature and always depend on once_cell would this change then, or does cargo no longer allow --features once_cell/critical-section and requires you instead to add this to your application's Cargo.toml?

But either way we still end up with imho way to many hard to use feature knobs. I'm wondering if we instead should adjust a little bit:

have parking_lot be directly implied by std without a parking_lot feature
- parking_lot can't be used in a no_std environment anyways and it's what we always used for std so far
two features to configure no_std - if cargo would allow it I'd definitely force-auto-enable those whenever std is disabled to cut down on things, but alas we can't:
- add spin feature as done in this pr, have it yield to std like it yields in hits pr right now to parking_lot
- add critical-section feature as you've described, replacing once_cell feature

@ErichDonGubler does Mozilla care about dependencies that show up in the lock file but aren't ever enabled in Firefox? Should be fine, after all we also have testing dependencies in the same situation, no?

ErichDonGubler · 2025-06-25T15:34:53Z

@ErichDonGubler does Mozilla care about dependencies that show up in the lock file but aren't ever enabled in Firefox? Should be fine, after all we also have testing dependencies in the same situation, no?

So long as they don't show up in mozilla-central's Cargo.lock file, then 🤷🏻‍♂️ it's not something we have to vet, and therefore not something we might have to reject.

Wumpf · 2025-07-02T15:13:04Z

great! :)

@bushrat011899 sounds like we could above mentioned suggestion then, what do you think?

have parking_lot be directly implied by std without a parking_lot feature

parking_lot can't be used in a no_std environment anyways and it's what we always used for std so far

two features to configure no_std - if cargo would allow it I'd definitely force-auto-enable those whenever std is disabled to cut down on things, but alas we can't:

add spin feature as done in this pr, have it yield to std like it yields in hits pr right now to parking_lot

add critical-section feature as you've described, replacing once_cell feature

cwfitzgerald · 2025-07-24T22:17:28Z

wgpu-core/src/lock/vanilla.rs

+                let guard = loop {
+                    if let Ok(guard) = self.0.try_borrow() {
+                        break guard;
+                    }
+                    core::hint::spin_loop();


This will definitionally never yield as there isn't another thread that can access the RefCell

I think i'd prefer if not having either spin or parking_lot was a compile error. Similarly, do we need to have separate std and parking_lot features?

cwfitzgerald · 2025-07-24T22:20:04Z

wgpu-core/src/pool.rs

+        // NOTE: Unlike `once_cell`, the `OnceCell` from `core` is _not_ `Sync`.
+        use core::cell::OnceCell;


Can't we use once_cell::unsync for these?

cwfitzgerald · 2025-07-24T22:24:34Z

wgpu-core/src/pool.rs

                Ok(weak)
-            })?;
+            };
+            cfg_if::cfg_if! {


This pains me a lot to have yet another layer of stuff to try to get through. I'm worried about the consequences of various program orderings in the non-once-cell branch here, so I'll need to come back and re-audit this.

cwfitzgerald · 2025-08-13T15:14:37Z

@bushrat011899 poke!

cwfitzgerald · 2025-08-27T20:20:30Z

Hey! I know personal life got busy for you, take your time, but I'm going to demote these two PRs to drafts, and you can re-promote them when they're ready for review again!

MVP no_std for wgpu-core

c0dc73c

bushrat011899 requested a review from a team as a code owner June 2, 2025 02:30

bushrat011899 added 2 commits June 2, 2025 12:34

CI Feedback

069196d

Address unused_mut

9368f26

jimblandy assigned Wumpf Jun 4, 2025

Update CHANGELOG.md

89e256a

Wumpf requested changes Jun 8, 2025

View reviewed changes

wgpu-core/Cargo.toml Show resolved Hide resolved

wgpu-core/Cargo.toml Show resolved Hide resolved

wgpu-core/Cargo.toml Show resolved Hide resolved

wgpu-core/Cargo.toml Show resolved Hide resolved

wgpu-core/src/lock/vanilla.rs Show resolved Hide resolved

bushrat011899 added 2 commits June 10, 2025 09:50

Document cross-feature interactions and fallback behaviour

c186bfb

Merge remote-tracking branch 'upstream/trunk' into no_std_wgpu-core

e3d6d3f

bushrat011899 requested a review from Wumpf June 18, 2025 06:43

bushrat011899 mentioned this pull request Jun 19, 2025

[wgpu-types]: Add cross-platform Mutex and RwLock #7830

Draft

6 tasks

cwfitzgerald assigned cwfitzgerald and unassigned Wumpf Jul 16, 2025

cwfitzgerald reviewed Jul 24, 2025

View reviewed changes

cwfitzgerald marked this pull request as draft August 27, 2025 20:21

cwfitzgerald removed their assignment Aug 27, 2025

		// NOTE: Unlike `once_cell`, the `OnceCell` from `core` is _not_ `Sync`.
		use core::cell::OnceCell;

MVP no_std for wgpu-core #7746

Are you sure you want to change the base?

MVP no_std for wgpu-core #7746

Uh oh!

Conversation

bushrat011899 commented Jun 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Wumpf left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

bushrat011899 commented Jun 9, 2025

Uh oh!

bushrat011899 commented Jun 19, 2025

Uh oh!

Wumpf commented Jun 19, 2025

Uh oh!

bushrat011899 commented Jun 19, 2025

Uh oh!

Wumpf commented Jun 25, 2025

Uh oh!

ErichDonGubler commented Jun 25, 2025

Uh oh!

Wumpf commented Jul 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cwfitzgerald Jul 24, 2025

Choose a reason for hiding this comment

Uh oh!

cwfitzgerald Jul 24, 2025

Choose a reason for hiding this comment

Uh oh!

cwfitzgerald Jul 24, 2025

Choose a reason for hiding this comment

Uh oh!

cwfitzgerald Jul 24, 2025

Choose a reason for hiding this comment

Uh oh!

cwfitzgerald commented Aug 13, 2025

Uh oh!

cwfitzgerald commented Aug 27, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

MVP `no_std` for `wgpu-core` #7746

MVP `no_std` for `wgpu-core` #7746

bushrat011899 commented Jun 2, 2025 •

edited

Loading

Wumpf commented Jul 2, 2025 •

edited

Loading