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

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

Open
Dinnerbone opened this issue Dec 25, 2024 · 1 comment
Open

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

Dinnerbone opened this issue Dec 25, 2024 · 1 comment
Labels
platform: wasm Issues with webassembly type: enhancement New feature or request

Comments

@Dinnerbone
Copy link
Contributor

Is your feature request related to a problem? Please describe.
naga, wgpu and related crates should have std as a (default) feature, specifically for wasm32v1-none support.

Describe the solution you'd like
There's a hope to get the wasm ecosystem slowly shifting from wasm32-unknown-unknown to wasm32v1-none, which is hopefully stabilizing in rust 1.84. This is primarily because wasm32-unknown-unknown is something of a moving target and can change the browser requirements at will, which we recently discovered when older Safari stopped working 😅

The main differences between wasm32v1-none and wasm32-unknown-unknown are:

  • It does not enable any wasm features by default (which means it won't arbitrarily break browser compatibility with rust updates)
  • It has no std (as opposed to a stubbed pseudo-std)

Unfortunately, no_std is both a blessing and a curse: it's neat to get things using core/alloc where possible, but it sucks that the majority of the ecosystem needs churn to make this viable.

I've done a quick investigation and I think it's plausible to get at least web working in no_std, but potentially other platforms too. wgpu-types is the easiest to get no_std, it only needs it for one specific dx12 config. naga is possibly the second easiest crate, but it requires some work in dependencies. wgpu-core and wgpu-hal will need more work mostly surrounding the use of mutexes.

Describe alternatives you've considered
We could just not, but that means it's impossible to allow users of wgpu to have any control over which browsers they support.
We can also limit this to a specific set of features, there's no real need today for DX12 and no_std, for example.

@bushrat011899
Copy link

I think there's value in having even just a subset of wgpu be no_std compatible. For context, I'm working on making Bevy no_std compatible, and a big line in the sand right now is anything related to our rendering crates, since they're built around wgpu and would be almost impossible to make independent of wgpu for the sake of an std feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
platform: wasm Issues with webassembly type: enhancement New feature or request
Projects
Status: Todo
Development

No branches or pull requests

3 participants