jsgroth
Draft: enable webgpu conditional compile.
Conditional compile for webgpu support, tested in both chromium and firefox-nightly to work. I did try servo but it was hitting a bug I will try to debug at a later point, that's to be expected since servo is still very beta.
I elected to put this behind a build flag since
A) I havent learned the interop stuff for this yet B) It's behind a nightly browser for firefox, and a config flag for chrome anyways so nothing can actually use it out of box C) Not sure how to best handle configuring it to begin with. Perhaps an option above image filtering? Not sure how changing that live would work anyways.
Cargo keeps force changing libloading in cargo.lock me, not sure why.
EDIT: I did notice a slight improvement when playing sonic-cd with this, I dont have many other games to test.
Thanks, this looks good!
Putting WebGPU behind a build flag and building two different versions might actually be the simplest way to handle this right now. It's been a while since I did any real testing of WebGPU, but last time I tested it was tricky to detect at runtime if WebGPU was supported, and trying to use WebGPU when it wasn't supported didn't always fail in the same way on different browsers. It might be easier nowadays, I think I last tested this with wgpu 0.17 or so.
In theory it would be possible to configure WebGL vs. WebGPU at runtime by completely recreating the WgpuRenderer in response to an option change event, although I'm not sure how well that would work in practice, and there'd need to be some way to detect if WebGPU is actually supported (or at least gracefully degrade if it's selected and then doesn't work on the current platform).
So it looks like wgpu actually properly supports automatically choosing between webgpu or webgl, Considering most browsers don't support webgpu in the first place this shouldn't cause issues with one caveat.
Firefox allows setting dom.webgpu.enabled even though webgpu isn't compiled in, this causes webgpu to panic, I could more or less copy and paste some of this if necessary https://github.com/emilk/egui/pull/3895
but considering that a user needs to go out of their way to enable webgpu, if possible it may be better to throw a popup error to the user instead of gracefully falling back so the user doesn't misunderstand, not sure how to do this.
Sorry for the very late response, I just got a chance to look over this.
The auto-choosing looks convenient, I didn't realize it could do that. I'm not worried about the emulator not working if the user manually configures the browser to report that WebGPU is supported, but unfortunately Chrome on Linux seems to behave like this by default - it reports that WebGPU is supported even though WebGPU doesn't work at all. The egui PR you linked mentioned that this happened in Chrome 121 and I just verified that it still behaves this way in Chrome 128 on Linux. The wgpu instance.request_adapter(..) call returns an error because WebGPU doesn't actually work in Chrome on Linux.
A solution very similar to that egui PR would be reasonable I think. It looks like if both WebGPU and OpenGL/WebGL are requested backends, they try to create a wgpu adapter with no surface, and if that returns an error then they remove WebGPU from the requested backends before properly initializing wgpu. That makes sense to me.
Sorry, I don't think I will be able to work on this much anymore. I may find some time to finish this up, however I have been dealing with worsening RSI so pretty much all coding has been put on the back burner, I can close the PR if wished. Though im not sure how much of this even still applies.
Sorry to hear that. If you don't think you'll be able to finish this then you can close the PR, but it's up to you.
As far as I can tell all of this still applies - I haven't yet added WebGPU support to the web frontend, and Chrome still doesn't support WebGPU on Linux even though it tells the application that it does. It doesn't look like Chrome is going to properly support WebGPU on Linux any time soon, so some sort of workaround is still necessary for that.
I've since upgraded wgpu to v22, but a workaround similar to what eframe does for WebGPU/WebGL should still work - v22 slightly changed the semantics around requesting a WebGL adapter (a compatible wgpu::Surface is now required instead of optional when requesting the adapter) but I don't think that breaks the workaround since the surface is still optional for WebGPU adapters. I haven't tested it though.