Update wgpu to 28.0.0

[SuchAFuriousDeath]

Supersedes #7789

The capture_buffer change is because of clippy complaining (clippy::useless_let_if_seq).

• I have followed the instructions in the PR template

[github-actions]

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

View snapshot changes at kitdiff

[SuchAFuriousDeath]

The cargo deny failure seems to be pre-existing

[Wumpf]

Nice!
Handling of transient_saves_memory is a bit odd since unlike the other added properties that's not one that goes into an unknown state. Otherwise lgtm

[Wumpf]

thanks!

[Wumpf]

The windows check needs to be addressed https://github.com/emilk/egui/actions/runs/21203049436/job/61125925471?pr=7853
looks like some dependency didn't get updated correctly or something

[Wumpf]

probably also best to add a security exception to the bincode crate for the moment - otherwise it's really hard to see whether there's other failures on individual platofrms

[SuchAFuriousDeath]

The windows check needs to be addressed https://github.com/emilk/egui/actions/runs/21203049436/job/61125925471?pr=7853 looks like some dependency didn't get updated correctly or something

Blocked on AccessKit/accesskit#682, but it should be getting merged soon.

[SuchAFuriousDeath]

@Wumpf Added the security exception.

[ArthurBrussee]

Sadly after this PR I can pretty reliably crash with:

fn main() {
    eframe::run_native(
        "Crash Test",
        Default::default(),
        Box::new(|cc| {
            let state = cc.wgpu_render_state.as_ref().unwrap();
            let queue = state.queue.clone();
            std::thread::spawn(move || {
                loop {
                    queue.submit([]);
                }
            });
            Ok(Box::new(App))
        }),
    )
    .unwrap();
}

struct App;

impl eframe::App for App {
    fn ui(&mut self, ui: &mut egui::Ui, _frame: &mut eframe::Frame) {
        ui.label("render anything");
        ui.request_repaint();
    }
}

[package]
name = "egui_crash"
version = "0.1.0"
edition = "2024"

[dependencies]
eframe = { git="https://github.com/SuchAFuriousDeath/egui", branch="update-wgpu-28", features=["wgpu"] }
egui = { git="https://github.com/SuchAFuriousDeath/egui", branch="update-wgpu-28" }

This might be due to a bug in wgpu 28 or a pre-existing bug in egui, I'm not sure yet! The crash manifests as either a deadlock, and sometimes crashes with a stack trace similair to #7840.

[SuchAFuriousDeath]

I'll try to figure it out.

[Cyrix126]

pretty reliably

What do you mean by that ? how much time are you waiting or what action do you take for it to crash ?

I tried to reproduce the crash in a Windows 11 25H virtual machine, but without any luck.

Your example had a typo, I replaced it by this one that would work as an independent crate:
Cargo.toml

[package]
name = "egui_crash"
version = "0.1.0"
edition = "2024"

[dependencies]
eframe = { version = "0.33.3", features = ["wgpu"] }
egui = {git="https://github.com/SuchAFuriousDeath/egui", branch="update-wgpu-28"}

src/main.rs

use eframe::egui::CentralPanel;
fn main() {
    eframe::run_native(
        "Crash Test",
        Default::default(),
        Box::new(|cc| {
            let state = cc.wgpu_render_state.as_ref().unwrap();
            let queue = state.queue.clone();
            std::thread::spawn(move || loop {
                queue.submit([]);
            });
            Ok(Box::new(App))
        }),
    )
    .unwrap();
}

struct App;

impl eframe::App for App {
    fn update(&mut self, ctx: &eframe::egui::Context, _frame: &mut eframe::Frame) {
        CentralPanel::default().show(ctx, |ui| {
            ui.label("render anything");
            ctx.request_repaint();
        });
    }
}

[ArthurBrussee]

Ah you need to patch eframe as well! I've edited my post with the corrected toml and code now. That version freezes after ~1s or so on Windows 11 and Linux for me. macOS seems fine annoyingly... might be a wgpu bug instead of an egui bug given that macOS works.

[Cyrix126]

Ah you need to patch eframe as well! I've edited my post with the corrected toml and code now. That version freezes after ~1s or so on Windows 11 and Linux for me. macOS seems fine annoyingly... might be a wgpu bug instead of an egui bug given that macOS works.

This will not compile on Window currently (wgpu-hal will fail).
https://github.com/SuchAFuriousDeath/egui/actions/runs/21244039197/job/61128664793

I can not reproduce the issue on Artix Linux with Sway, with intel cpu.

What setup do you use to test on Linux ?

[ArthurBrussee]

You need to run a cargo update after changing the patch to update the cargo.lock and remove the duplicate windows crate.

For Linux, I'm on Arch + Gnome on a AMD CPU, nvidia GPU.

[Cyrix126]

ok thanks. Still can not reproduce in a Windows VM. I can not reproduce either with a Ubuntu 25.10 VM (which is using Gnome 49). Maybe it is related to the GPU used ?

[ArthurBrussee]

Ah strange sorry to hear :/

Seems like it is nvidia related, just tried on Linux on nvidia 4070 TI (crash), and then on my integrated card on AMD (works ok).

So, I'm guessing its some low-level race condition that either wgpu or nvidia is wrong about. Vulkan validation doesn't show anything...

In any case likely need a lower level repro in pure wgpu, and report to them

[ArthurBrussee]

I've created a wgpu issue: gfx-rs/wgpu#9003