Windows 11 Unable to find a GPU (with workaround using DISABLE_LAYER_AMD_SWITCHABLE_GRAPHICS_1)

[Clonkex]

Bevy version

0.13.1

[Optional] Relevant system information

cargo 1.79.0-nightly (d438c80c4 2024-03-19) OS: Windows 11 Version 10.0.22631 Build 22631 CPU: AMD Ryzen 5 4600H GPU: GTX 1660 Ti Device: 2021 Omen 15 gaming laptop (15-en0016ax)

What you did

cargo run

What went wrong

2024-03-26T19:56:30.314723Z  INFO bevy_winit::system: Creating new window "App" (0v1)
2024-03-26T19:56:32.594139Z ERROR log: enumerate_adapters: A return array was too small for the result
thread 'main' panicked at C:\Users\clonk\.cargo\registry\src\index.crates.io-6f17d22bba15001f\bevy_render-0.13.1\src\renderer\mod.rs:141:10:
Unable to find a GPU! Make sure you have installed required drivers!
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace`

Additional information

I previously had this same issue with Godot 4.0 (because they switched to a Vulkan renderer). Eventually I found somewhere that doing set DISABLE_LAYER_AMD_SWITCHABLE_GRAPHICS_1=1 before running Godot made it work. I have no idea what that variable does or why it works. On a whim I decided to try it with Bevy as well and lo and behold it works also. So I guess it must be a Vulkan variable then? Very strange.

I believe I got my drivers up-to-date when I had this issue with Godot, but I'll check after I get home from work today.

The problem no longer occurs for me with newer versions of Godot. It seems maybe they're just setting that environment variable automatically on Windows. One of their graphics programmers said that flag simply causes the GPUs to present separately instead of combined into one switchable one.

[Clonkex]

Ok, even easier than manually setting that environment variable before cargo run is doing this:

fn main() {
    set_var("DISABLE_LAYER_AMD_SWITCHABLE_GRAPHICS_1", "1");
    App::new().add_plugins(DefaultPlugins)
        .run();
}

[matiqo15]

From PR that you linked:

While a AMD driver update can resolve this issue, it still gets reported regularly and is likely to become a source of support headache for people distributing projects made with Godot (as this also affects exported projects).

Could you try updating drivers?

[Clonkex]

Could you try updating drivers?

As I mentioned I believe I already tried that at the time, but I'll try again when I get home after work today.

[Mart-Bogdan]

Also without this flag I have graphical artifacts in full screen games.

And windowed games aren't starting. But looks like I have driver from windows update, not from AMD.

[Clonkex]

But looks like I have driver from windows update, not from AMD.

Windows update usually contains official drivers from AMD or Nvidia. They're not Microsoft drivers. OEMs work with Microsoft to have their drivers included in Windows Update so their users don't have to manually update anything and they get a seamless experience (which, on my laptops, is actually true most of the time).

[Mart-Bogdan]

It usually have dated versions of Drivers. And my adrenalin software was telling me that I have wrong version.

I've reinstalled driver from official package, and now Bevy games are starting no problem without this ENV variable.

But I guess it still would be nice to port workaround from godot. Or add it as retry if regular detection fails.

[Mart-Bogdan]

I think it would be best if Bevy's function run return a result to let developer handle error and display error message instead of just crashing whole app in panic.

Or dev is supposed to use catch_unwind ? Or perhaps let bevy show error message, as on Windoews there are not terminal for UI apps.

And on Linux also if app was launched from menu it won't have terminal.

But I'd suggest letting app developer handler error and provide inside Bevy's API some helper functions to show Message Box in platform independent way would be nice.

[Mart-Bogdan]

I assume that we need to set_var ony it is UNSET. if it already have either 0 or 1 there -- we should not touch this, because User of app might want to set it.

but it sound hacky either way.

Sadly I'm unable to find any documentation about this variable in the internet. I guess only source of knowledge would be opensource Linux AMD drivers

[Clonkex]

I assume that we need to set_var ony it is UNSET. if it already have either 0 or 1 there -- we should not touch this, because User of app might want to set it.

That's plausible, but unlikely given how undocumented this switch is.

but it sound hacky either way.

I disagree. It's just configuring the Vulkan system to actually inform us of the real GPUs instead of pretending there's only one. Ok so maybe it's a little hacky, but only slightly, especially if we respect any user-specified settings.

I guess only source of knowledge would be opensource Linux AMD drivers

Is it a driver thing or a Vulkan thing? I just assumed it was a Vulken-specified switch implemented in the driver, in which case the Vulkan docs/spec should give some info. But I haven't looked.