-
Notifications
You must be signed in to change notification settings - Fork 3
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
[DRAFT] wgpu v0.20.0 #50
Conversation
As an FYI, the reason I'm currently on older versions of wgpu/winit/egui is because of an annoying dependency issue related to raw-window-handle and sdl2. wgpu and winit have moved on to raw-window-handle 0.6 while sdl2 is still on the incompatible 0.5. The web frontend doesn't use sdl2, but the native frontend does and the rendering code is shared. wgpu makes enough breaking changes between minor versions that it would be pretty unpleasant to support multiple versions simultaneously in the renderer. It should be possible to upgrade everything across the entire project once this sdl2 PR is merged: Rust-SDL2/rust-sdl2#1385 In the long term I'd eventually like to migrate the native frontend to use winit for windowing instead of sdl2. This is not a straightforward change unfortunately, but it would remove the dependency on sdl2's raw-window-handle implementation and make it much easier to keep wgpu/winit/egui up to date. (I do still want to use SDL2 for audio and joystick/controller inputs, and thankfully those parts of SDL2 are usable without an SDL2 window.) |
yeah I initially wanted to touch on this since I was running into issue since no matter what I did with wgpu v0.18 I can't manage to get webgpu to init, I was able to get it to initialize with v0.20 but ran into the bugs I described above. I don't see any other obvious way to get webgpu to somewhat work without bumping wgpu |
The linked sdl thing has been merged, but I have yet to find a simple way around the atomics issue |
Thanks for pointing out the sdl2 0.37 publish! From some local testing with these changes: The project as a whole won't currently build with wgpu 0.20 because egui-wgpu and glyphon both still require wgpu 0.19 on their latest releases. Do you need 0.20 specifically or would 0.19.4 work for the time being? Looking at wgpu's release notes, it looks like the major improvements for WebGPU usability were made in 0.19.0 and 0.19.3: The atomics feature is needed for audio to work correctly (it's required by the ring buffer for sending samples from the main thread to the audio worklet thread), so disabling it isn't really an option unless there's another way to make audio work. wgpu failing to build with atomics now is only because of wgpu::RequestDeviceError. I think it would be reasonable to change that RendererError variant to just stringify the error, maybe gated behind conditional compilation since this isn't an issue on native. The width/height 0 issue seems to be caused a change in winit behavior from 0.28 to 0.29. I haven't yet figured out a good way to fix it though - with_inner_size/with_min_inner_size/with_max_inner_size don't seem to have any effect in 0.29, at least on web. I might take a look at finishing up some of these upgrades myself later today because I'd like to get the native frontend on wgpu 0.19+ to pick up some bugfixes, and I'd prefer to upgrade the whole project at once so that the web build isn't broken. |
I just pushed a change to master that upgrades wgpu to 0.19 and winit to 0.29 along with the other libraries that were held back by sdl2 / raw-window-handle. It looks like the API changes between wgpu 0.19 and 0.20 are minor - the only change that affects this project is the addition of the The width/height 0 issue was indeed caused by a breaking change in winit 0.29, specifically this one I think:
With winit 0.29, the canvas is initialized with a size of 0, and then it automatically adjusts its size based on what wgpu requests. Applications control the size through the wgpu::SurfaceConfiguration. Attempting to set the size through winit has no effect, and as such having the renderer set the surface size based on the window size no longer works on web. I changed the API a bit so that the frontend passes through the window size (which is now constant on web) instead of the renderer fetching the size from the window handle. I also had to make some small changes to the event loop handler to fix some really poor frame pacing and occasional freezing after upgrading to winit 0.29. The handler now sets the control flow to ControlFlow::WaitUntil(now() + 1ms) instead of ControlFlow::Poll whenever it's too soon to generate the next frame. It now seems to work better than it did before though. |
I don't think there was anything in specific that needed v0.20.0, so i'll go ahead and close this! thanks a bunch! |
I originally wanted to try and play with webgpu, so I decided to try and bump wgpu to v0.20.0 which requires a winit bump too. Draft PR to bump wgpu and egui stuff to v0.20.0 however there are some issues I haven't reconciled yet.
I actually sadly ran out of time and hope to be able to pick this back up, however when I will be able to do so, I don't know, so I've made a draft PR instead for now as a starting point.
surface.configure(&device, &surface_config);
in renderer.rs not sure if this is related