Skip to content

Update to wgpu 25 #6744

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

Merged
merged 2 commits into from
May 10, 2025
Merged

Update to wgpu 25 #6744

merged 2 commits into from
May 10, 2025

Conversation

torokati44
Copy link
Contributor

@torokati44 torokati44 marked this pull request as draft April 14, 2025 10:24
@torokati44 torokati44 force-pushed the wgpu-25 branch 2 times, most recently from 4ebc603 to f571ee2 Compare April 14, 2025 10:30
Copy link

Preview available at https://egui-pr-preview.github.io/pr/6744-wgpu-25
Note that it might take a couple seconds for the update to show up after the preview_build workflow has completed.

mikialex added a commit to mikialex/rendiation that referenced this pull request Apr 15, 2025
mikialex added a commit to mikialex/rendiation that referenced this pull request Apr 17, 2025
@torokati44 torokati44 mentioned this pull request Apr 22, 2025
emilk pushed a commit that referenced this pull request Apr 24, 2025
Prerequisite of #6744.
See: gfx-rs/wgpu#7218,
gfx-rs/wgpu#7425

Please be aware that Rust 1.84 enables some (more) WASM extensions by
default, and ships with an `std` built with them enabled:
https://blog.rust-lang.org/2024/09/24/webassembly-targets-change-in-default-target-features/
According to `rustc +1.84 --print=cfg --target wasm32-unknown-unknown`,
these are: `multivalue`, `mutable-globals`, `reference-types`, and
`sign-ext`.
(c.f. `rustc +1.84 --print=cfg --target wasm32-unknown-unknown -C
target-cpu=mvp` enabling none.)
For reference: https://webassembly.org/features/

----

If support is desired for ancient/esoteric browsers that don't have
these implemented, there are two ways to get around this:
- Target `wasm32v1-none` instead, but that's a `no-std` target, and I
suppose a lot of dependencies don't work that way (e.g.
gfx-rs/wgpu#6826)
- Using the `-Ctarget-cpu=mvp` and `-Zbuild-std=panic_abort,std` flags,
and the `RUSTC_BOOTSTRAP=1` escape hatch to allow using the latter with
non-`nightly` toolchains - until
https://github.com/rust-lang/wg-cargo-std-aware is stabilized. (For
reference:
https://github.com/ruffle-rs/ruffle/pull/18528/files#diff-fb2896d189d77b35ace9a079c1ba9b55777d16e0f11ce79f776475a451b1825a)

I don't think either of these is particularly advantageous, so I suggest
just accepting that browsers will have to have some extensions
implemented to run `egui`.
@torokati44 torokati44 force-pushed the wgpu-25 branch 2 times, most recently from dafe378 to 2059f4a Compare April 25, 2025 12:37
@torokati44 torokati44 changed the title Update to wgpu 25.0.1 Update to wgpu 25 Apr 25, 2025
WgpuError::NoSuitableAdapterFound("`request_adapters` returned `None`".to_owned())
WgpuError::NoSuitableAdapterFound(format!("`request_adapters` returned `Err`: {}", e))
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps it would be better to do this...?

pub enum WgpuError {
    #[error(transparent)]
    NoSuitableAdapterFound(#[from] wgpu::RequestDeviceError),

But then that would spread into NativeAdapterSelectorMethod...

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I solved that now by exposing this as a separate error 🤷

@@ -195,12 +186,9 @@ impl Default for WgpuSetupCreateNew {
..base_limits
},
memory_hints: wgpu::MemoryHints::default(),
trace: wgpu::Trace::Off,
Copy link
Contributor Author

@torokati44 torokati44 Apr 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is loss of functionality - but unfortunately, wgpu::Trace::Directory(std::path::PathBuf) is behind the wgpu-core/trace feature, and I couldn't find a way to check for it being enabled using cfg!, and to add another feature (such as wgpu-trace) to enable it, wgpu-core would also have to be declared as a direct dependency, and... 😵‍💫

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See: #6860

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not exposed right now because the feature is a bit on hiatus right now gfx-rs/wgpu#5974
it's still used by Mozilla internally which uses wgpu-core (rather than wgpu)

@emilk emilk added this to the 0.32.0 milestone Apr 30, 2025
@Wumpf Wumpf self-assigned this May 10, 2025
Copy link
Collaborator

@Wumpf Wumpf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thank you for the update and sorry it took so long to get it approved!
Looks all good to me, but went the suggested path of adding a separate error to expose the wgpu adapter selection error directly

@Wumpf Wumpf merged commit 773232b into emilk:main May 10, 2025
26 checks passed
mikialex added a commit to mikialex/rendiation that referenced this pull request Jun 23, 2025
@torokati44 torokati44 mentioned this pull request Jul 1, 2025
mikialex added a commit to mikialex/rendiation that referenced this pull request Jul 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants