Enabling the wgpu feature results in a panic "The surface isn't supported by this adapter" #5269
Comments
|
I agree we shouldn't panic here. Maybe @Wumpf wants to take a look at some point? 🙏 |
|
yep, we definitely shouldn't crash and instead try to forward an error if needed As to actual source of the issue (and how to show it better): this might be a tricky one. This piece of log output seems to come directly from wayland And searching for this a bit brings up people recommending to downgrade the nvidia driver from 560 to 555, e.g. here |
|
Is it possible to force Egui/eframe with wgpu to use xwayland as a test? Some environment variable perhaps? Also, vkcube and glxgears both work fine under Wayland with both Intel and nvidia graphics. This indicates to me that both basic platform APIs work (at least to some extent). So it seems like the issue could be on the wgpu side. |
|
Hmm yeah then it is probably something that wgpu could do different. There's unfortunately quite many wayland issues there that are waiting for contributors to look into (the maintainers either don't have local repro cases (that includes myself) or no high priority to look into these (most of the time both)). You could try with |
|
So uh, tried this again. It isn't happening any more (at least in hybrid mode, with and without Though according to As I'm on Arch Linux (which is rolling release) that could be from some update or other. In this case the only difference I can find is that I'm now on KDE Plasma 6.2.1 and Kernel 6.11.3. Mesa is the same version. I did not note down the nvidia driver version before, but now it is 560.35.03-16. |
|
Unsetting WAYLAND_DISPLAY does not make the program use X for some reason (program is not listed in output of Building eframe without the |
|
Aha, in pure Intel mode it still fails. That is interesting. If WGPU incorrectly uses the nVidia GPU when it is not supposed to (as indicated above, in hybrid mode) that could definitely cause issues. As the programs exits too quickly, it is hard to know. I tried to set a breakpoint to where it crashes and use nvidia-smi to see if anything was using the nVidia GPU at that point, but nvidia-smi comes up blank (so unclear). However, if I run |
|
Huh, strange why would docs fail for 0.29 Oo. They're up for 0.28 and the struct hasn't changed. Yes, indeed you should be able to adjust which gpu is choosen by changing the power_preference. |
|
Docs were fixed by this: #5204 But we'd need to make a new patch release for the docs to show up |
|
Setting There should be a way (either automatically by egui/eframe or by the application) to fall back to opengl if vulkan isn't working. Possibly this also means being able to fall back to glow if wgpu isn't working and you compiled in support for both. A prerequisite for this is to not panic though (I would rather not mess around with
I will try to look into that soon, I'm currently dealing with a rather nasty cold, so it may take a few days. |
|
Yeah I think that "this surface doesn't have any formats" should be an exclusion criteirum for an adapter. That ofc still leaves the separate issue of the surface mysteriously not advertising any formats. |
|
Unfortunately
I have not tested messing with this programatically. |
|
for reference, found this issue on |
|
This probably relevant fix landed in wgpu 23.0.1: gfx-rs/wgpu#6510 we have to update wgpu in the egui lock file as well for this to take effect on the egui demo there are ofc two remaining issues:
|
|
wgpu 23.0.1 is now on egui |
|
I had time to test it today, using commit 13352d6 I enabled the wgpu feature and ran the hello world demo. (I think this is what I did last time, but it has been a while.) It appears to work fine. I don't know for sure how to tell if it uses OpenGL or Vulkan though. But this seems to indicate GLES? ❯ RUST_LOG=warn cargo run
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.38s
Running `/home/arvid/src/egui/target/debug/hello_world`
[2024-12-09T21:58:21Z WARN wgpu_hal::vulkan::instance] InstanceFlags::VALIDATION requested, but unable to find layer: VK_LAYER_KHRONOS_validation
[2024-12-09T21:58:21Z WARN wgpu_hal::gles::egl] Re-initializing Gles context due to Wayland window
[2024-12-09T21:58:21Z WARN wgpu_hal::gles::adapter] Detected skylake derivative running on mesa i915. Clears to srgb textures will use manual shader clears.
[2024-12-09T21:58:21Z WARN wgpu_hal::gles::adapter] Detected skylake derivative running on mesa i915. Clears to srgb textures will use manual shader clears. |
|
nice! That's probably GLES: the we we run with wgpu here it tries through all adapters before it settles on one. If you run with regardless let's keep this ticket open: egui still shouldn't panic on surface not supported |
Describe the bug
Enabling the
wgpufeature causes the program to crash immediately at startup. This can be reproduced on thehello worldexample even.The full backtrace is:
To Reproduce
Steps to reproduce the behavior:
examples/hello_worlddirectorywgpufeature foreframeinCargo.tomlcargo runExpected behavior
Program should start without errors. Or at least not panic (return an Error instead). And that error should be less cryptic. (I'm not a GPU expert, I'm trying to make a simple GUI.).
I don't know what the error means, but it should probably select a suitable surface instead of an unsupported surface. Whatever a surface is in this context.
Screenshots
Desktop (please complete the following information):
prime-runto run on the nVidia GPU).Additional context
The text was updated successfully, but these errors were encountered: