sotrh / learn-wgpu

Guide for using gfx-rs's wgpu library.
https://sotrh.github.io/learn-wgpu/
MIT License
1.49k stars 260 forks source link

wgpu and winit update tracker #503

Open ifsheldon opened 11 months ago

ifsheldon commented 11 months ago

Hey! Here is just a heads-up that wgpu 0.18 and winit 0.29.2 came up recently with a lot breaking changes.

For the breaking changes from wgpu, please see https://github.com/gfx-rs/wgpu/releases/tag/v0.18.0. I think these are easy to be fixed when upgrading from 0.17.

However, for the newer winit, it brings a LOT API changes. See https://github.com/rust-windowing/winit/releases/tag/v0.29.2

I think virtually a rewrite on sections about windowing is needed.

If it helps, I just did the upgrade to winit 0.29.2 for my wgpu DVR renderer in this commit. In short, we need to:

But wait, why do we need to upgrade winit?

I don't know honestly, because when I upgraded wgpu from 0.17 to 0.18 while keeping winit as 0.27, my code weirdly breaks because an abnormal resize event which gives a new window size to (u32::max, u32::max). I thought that should be a bug from winit so I upgraded winit as well. Probably winit 0.27 does not work with macOS Sonoma, I don't know, but now the problem is gone, so I don't want to dig deeper.

sotrh commented 9 months ago

I've already upgraded to 0.18, but an upgrade to winit 0.29 might take a little longer. I created different demo using winit 0.29 so hopefully it shouldn't be too painful.

vfx1b commented 8 months ago

Hi, I've been working through the learn-wpgu book, but with updated winit and wgpu. Id be happy the help out with rewriting stuff!

ifsheldon commented 8 months ago

wgpu 0.19 is just released. We just need a few minor changes to remove the last bit of unsafe code in the tutorial when creating a Surface. It works perfectly in my webgpu DVR renderer. But I'm using the latest winit so I don't know how it works with older winit. The breaking changes of wgpu 0.19 are not fully documented but it's easy to fix the breaking pieces. Just for your information, my changes in my renderer due to the wgpu update are here.

tgross35 commented 5 months ago

Winit 0.30 was released just yesterday, which seems to prefer the ApplicationHandler trait rather than an event loop. This was very tricky to get working but I think I have something, which I posted to https://github.com/rust-windowing/winit/issues/3626#issuecomment-2081794856.

ifsheldon commented 5 months ago

@tgross35 Thanks for the heads-up. How about async methods?

I have the following code in my GfxStates::new()

let instance = wgpu::Instance::default();
        let surface = instance.create_surface(window).expect("Failed to create surface");
        // need adapter to create the device and queue
        let adapter = instance
            .request_adapter(&wgpu::RequestAdapterOptions {
                power_preference: wgpu::PowerPreference::default(),
                force_fallback_adapter: false,
                compatible_surface: Some(&surface),
            })
            .await
            .unwrap();
        let (device, queue) = adapter
            .request_device(
                &wgpu::DeviceDescriptor {
                    label: None,
                    required_features: wgpu::Features::empty(), //The device you have limits the features you can use
                    required_limits: wgpu::Limits::default(), //The limits field describes the limit of certain types of resource we can create
                },
                None,
            )
            .await
            .unwrap();

but the trait method is synchronous, so do we have to introduce a blockon() to get the result?

ifsheldon commented 5 months ago

Just FYI, I updated my code to wgpu 0.20, which was released 5 hrs ago and is very easy to migrate to. Just follow rustc's error messages.

tgross35 commented 5 months ago

I have just been using block_on for those two functions, but that is a good point. I wish I better understood why these were async at all, I guess maybe this comes from webgpu? Seems like an unlikely point to have performance wins from a nonblocking API.

(reposting here since I accidentally posted this comment on the winit tracker)

sotrh commented 5 months ago

Yeah the async bit is from the webgpu spec.

ifsheldon commented 2 months ago

Using wgpu::Surface with Window of winit>0.30.0 is a bit tricky, which may cause self-reference. You can refer to https://github.com/gfx-rs/wgpu/discussions/6005#discussioncomment-10105507 and my commit that updates my renderer to get an idea on how to avoid self-referential types and adapt to newer winit APIs.

Bentebent commented 1 month ago

What is the current thoughts on upgrading to winit 0.30? It feels like a significant effort to move all beginner tutorials to 0.30 but could it be interesting to have an intermediate tutorial that shows how to port to 0.30?

ifsheldon commented 1 month ago

I think as of now, both wgpu and winit have reached a sort of stable stage, as wgpu release a major version 22.x and winit has stayed in 0.30.x for several months and on track of its roadmap. So, I guess now is a good point to revisit the tutorial?

sotrh commented 1 month ago

I created a branch to experiment with 0.30. While I got the code to run on WASM, the canvas was being sized to 1x1 for some reason. That killed the momentum I had to work on it, and I haven't had time to come back to it.

sotrh commented 1 month ago

Accidentally closed the issue while trying to make a comment