fix: force wgpu to use dedicated/discrete graphics-card, to avoid Vulkan issues

[user583953]

I've spent like an hour looking through Iced, and apparently there is no option to pass config to wgpu, it always picks settings from env:

https://docs.rs/iced_renderer/0.12.1/src/iced_renderer/compositor.rs.html#252
https://docs.rs/iced_wgpu/0.12.1/src/iced_wgpu/settings.rs.html#47

Also, for some reason, on my PC setting via WGPU_BACKEND=gl (either in terminal or using set_env) only fixes the issue when compiling with --release.

fixes #848

[adhirajsinghchauhan]

I'm hesitant to merge this, to avoid this issue popping up again. Even though GL is a much older standard than Vulkan, forcing GL-only for everyone may again lead to similar issues in the future. Also, as far as I understand it, Vulkan, if used properly, offers lower power usage for the same performance (less overhead). It shouldn't make that much of a difference for this project, but it goes in line with our debloater ethos.

If it's only wayland that crashes, wouldn't the better solution be to use GL only for wayland? Users can set the env in their home configs for now.

Side-note: do we know that it crashes for all wayland users, across all distros, or only for the reporter?

[user583953]

wouldn't the better solution be to use GL only for wayland?

I can add check for XDG_SESSION_TYPE=wayland, and if true, use GL.

do we know that it crashes for all wayland users, across all distros, or only for the reporter?

I've looked for similar issues based on the crash log:

#459 fail with either Wayland/Xorg + Nvidia.

This comment from #383 mentions AMD + Wayland though it's old,

and the #383 itself mentions problem with Nvidia + Xorg and lack of it with AMD + Wayland.

gfx-rs/wgpu#6159 Nvidia + Wayland and a comment that the problem also occurs on AMD + Wayland and another comment that has the same config as I do (Nvidia dGPU + amd iGPU, though I didn't try to blocklist amdgpu).

gfx-rs/wgpu#6320 Nvidia + Wayland.

One of those issues mentions improper usage of surface, so I tried to run an Iced example from the latest branch to see if it was fixed, it failed, but it had a nice crash log:

Log

2025-02-15T11:05:54.734378Z  INFO iced_wgpu::window::compositor: Available adapters: [
    AdapterInfo {
        name: "NVIDIA GeForce GTX 1050",
        vendor: 4318,
        device: 7297,
        device_type: DiscreteGpu,
        driver: "NVIDIA",
        driver_info: "565.77",
        backend: Vulkan,
    },
    AdapterInfo {
        name: "AMD Radeon Graphics (RADV RAPHAEL_MENDOCINO)",
        vendor: 4098,
        device: 5710,
        device_type: IntegratedGpu,
        driver: "radv",
        driver_info: "Mesa 24.3.4",
        backend: Vulkan,
    },
    AdapterInfo {
        name: "llvmpipe (LLVM 19.1.7, 256 bits)",
        vendor: 65541,
        device: 0,
        device_type: Cpu,
        driver: "llvmpipe",
        driver_info: "Mesa 24.3.4 (LLVM 19.1.7)",
        backend: Vulkan,
    },
    AdapterInfo {
        name: "NVIDIA GeForce GTX 1050/PCIe/SSE2",
        vendor: 4318,
        device: 0,
        device_type: Other,
        driver: "",
        driver_info: "",
        backend: Gl,
    },
]    
2025-02-15T11:05:54.739952Z  INFO wgpu_core::instance: Adapter Vulkan AdapterInfo { name: "AMD Radeon Graphics (RADV RAPHAEL_MENDOCINO)", vendor: 4098, device: 5710, device_type: IntegratedGpu, driver: "radv", driver_info: "Mesa 24.3.4", backend: Vulkan }    
2025-02-15T11:05:54.739990Z  INFO iced_wgpu::window::compositor: Selected: AdapterInfo {
    name: "AMD Radeon Graphics (RADV RAPHAEL_MENDOCINO)",
    vendor: 4098,
    device: 5710,
    device_type: IntegratedGpu,
    driver: "radv",
    driver_info: "Mesa 24.3.4",
    backend: Vulkan,
}

[...edited out...]

[destroyed object]: error 7: importing the supplied dmabufs failed
Protocol error 7 on object @0: 
2025-02-15T11:05:54.847644Z ERROR wgpu_hal::vulkan::adapter: get_physical_device_surface_present_modes: ERROR_SURFACE_LOST_KHR    
2025-02-15T11:05:54.847665Z ERROR wgpu_hal::vulkan::adapter: get_physical_device_surface_formats: ERROR_SURFACE_LOST_KHR    
thread 'main' panicked at /home/user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wgpu-core-0.19.4/src/device/global.rs:1859:21:
internal error: entered unreachable code: Fallback system failed to choose present mode. This is a bug. Mode: AutoVsync, Options: []
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I am on PC and monitor is connected to Nvidia dGPU, not on a laptop, but it selected AMD iGPU instead. There's a similar issue: gfx-rs/wgpu#3747 mentions Nvidia + Intel hybrid laptop + Wayland

I'll create an issue on Iced issue tracker later if it doesn't already exist.

[Rudxain]

wouldn't the better solution be to use GL only for wayland?

I was thinking of a simple mechanism for UAD to detect when it crashes, so that the next startup forces GL-use to try to prevent a crash. This is very hacky, so false positives/negatives would be detected. For example, depending on implementation details, an unclean computer-shutdown would make the next UADNG startup assume a crash happened.

Users can set the env in their home configs for now

I agree, we should add this to the FAQ. I'll do it in a minute.

Side-note: do we know that it crashes for all wayland users, across all distros, or only for the reporter?

I remember Windows users having issues with Vulkan, too

[user583953]

I did some more investigation (see my comment at gfx-rs/wgpu#6159), and it looks like the problem is that it selects Amd iGPU for some reason. If I force wgpu to use dGPU via WGPU_POWER_PREF=high, it selects Nvidia dGPU on Vulkan and runs fine.

Running on dGPU will not force either GL or Vulkan on users, but will prevent crashes at the cost of slightly higher power usage on laptops.

[AnonymousWP]

Thank you so much for wanting to fix this issue, it's appreciated.

Also, for some reason, on my PC setting via WGPU_BACKEND=gl (either in terminal or using set_env) only fixes the issue when compiling with --release.

Is that always or still the case or did you find a workaround?

---

I'm hesitant to merge this, to avoid this issue popping up again. Even though GL is a much older standard than Vulkan, forcing GL-only for everyone may again lead to similar issues in the future. Also, as far as I understand it, Vulkan, if used properly, offers lower power usage for the same performance (less overhead). It shouldn't make that much of a difference for this project, but it goes in line with our debloater ethos.

That's correct, and I agree.

Side-note: do we know that it crashes for all wayland users, across all distros, or only for the reporter?

It seems it only affects users using X11:

• bug(GUI): Unreadable (tofu) text #523
• bug(scope): EGL says it can present to the window but not natively #459
• bug(startup): 1.0.3 core dump in Xorg session #383

---

I can add check for XDG_SESSION_TYPE=wayland, and if true, use GL.

That'd be good, as long as the endgoal/solution is an efficient fix.

[AnonymousWP]

Let's wait with merging. This user is still experiencing issues: #523 (comment)

[user583953]

I don't think #523 is related. The problem there is that text is not being rendered correctly, while here the problem is hard crash.

Quote from the open iced-rs/iced#2709, which describes the same issue as #523:

Adding shaping(text::Shaping::Advanced) makes the text render properly. So I'm not sure if it means the default font lookup makes a bad guess, or?

I'll try to make a separate PR tomorrow.

[AnonymousWP]

Ah I see, I saw they were both related to wgpu or Vulkan. Anyway, I merged this now based on your conclusion. Thanks again. 🙂