Bevy chooses CPU render device instead of integrated GPU

[ByteNybbler]

Bevy version

v0.13.1 (issue is still present in v0.13.2)

[Optional] Relevant system information

• My actual GPU: AdapterInfo { name: "Intel(R) HD Graphics 4600", vendor: 32902, device: 0, device_type: IntegratedGpu, driver: "OpenGL", driver_info: "4.3.0 - Build 20.19.15.4531", backend: Gl }
• CPU rendering that gets used instead: AdapterInfo { name: "Microsoft Basic Render Driver", vendor: 5140, device: 140, device_type: Cpu, driver: "", driver_info: "", backend: Dx12 }
• SystemInfo { os: "Windows 10 Home", kernel: "19045", cpu: "Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz", core_count: "4", memory: "15.9 GiB" }
• cargo 1.77.0 (3fe68eabf 2024-02-29)

What you did

cargo run --example 2d_shapes

What went wrong

Bevy 0.13 appears to be using CPU rendering instead of using my integrated GPU.

I don't think this is an issue with my GPU drivers since Bevy seems to properly select my GPU whenever I'm using Bevy versions prior to 0.13. This is probably not a regression on Bevy's part, since the Dx12 backend on my GPU was filtered out by an upstream wgpu change (see below). However, my GPU's Gl backend is still available for use.

CPU rendering tends to be extremely slow and buggy and should only be used as a last resort. If there's any available GPU, I believe it should be chosen instead.

Bevy currently uses wgpu 0.19.3. Running wgpu 0.19.3's hello example shows the following adapters and properly selects the GPU adapter:

[2024-04-27T02:07:10Z INFO  wgpu_examples::hello] Available adapters:
[2024-04-27T02:07:10Z INFO  wgpu_examples::hello]     AdapterInfo { name: "Microsoft Basic Render Driver", vendor: 5140, device: 140, device_type: Cpu, driver: "", driver_info: "", backend: Dx12 }
[2024-04-27T02:07:10Z INFO  wgpu_examples::hello]     AdapterInfo { name: "Intel(R) HD Graphics 4600", vendor: 32902, device: 0, device_type: IntegratedGpu, driver: "", driver_info: "", backend: Gl }
[2024-04-27T02:07:10Z INFO  wgpu_examples::hello] Selected adapter: AdapterInfo { name: "Intel(R) HD Graphics 4600", vendor: 32902, device: 0, device_type: IntegratedGpu, driver: "", driver_info: "", backend: Gl }

However, running Bevy 0.13 apps chooses the CPU adapter instead:

AdapterInfo { name: "Microsoft Basic Render Driver", vendor: 5140, device: 140, device_type: Cpu, driver: "", driver_info: "", backend: Dx12 }

It's possible that Bevy requests render features that my GPU's Gl backend does not have. If that's the case, I wonder if Bevy's render feature requirements should be loosened a bit, or if some other measure should be employed to not pick CPU rendering if there are other options available.

Running wgpu 0.19.3's hello_triangle example causes the CPU adapter to be chosen even though its device request is only the following:

    let (device, queue) = adapter
        .request_device(
            &wgpu::DeviceDescriptor {
                label: None,
                required_features: wgpu::Features::empty(),
                // Make sure we use the texture resolution limits from the adapter, so we can support images the size of the swapchain.
                required_limits: wgpu::Limits::downlevel_webgl2_defaults()
                    .using_resolution(adapter.limits()),
            },
            None,
        )
        .await
        .expect("Failed to create device");

I'm unsure if this counts as an upstream issue because I don't know whether wgpu itself is supposed to be biased towards choosing GPUs over CPUs by default.

EDIT: On the latest commits of wgpu's main branch (trunk), wgpu's hello_triangle example now properly chooses my GPU due to a recent fix. See the comments below for more details.

Additional information

The issue started occurring for me after this PR: #11280 (Update to wgpu 0.19 and raw-window-handle 0.6)

Upstream, wgpu seems to have filtered out the Dx12 backend on certain GPUs due to a security vulnerability: gfx-rs/wgpu#5615

Prior to the upstream wgpu change, Bevy chose my GPU's Dx12 backend and worked fine. However, when Bevy's wgpu dependency got updated to 0.19.1 in the above PR, Bevy could no longer use my GPU's Dx12 backend. It basically makes Bevy 0.13 projects unplayable on my PC whereas it was fine prior to Bevy updating the wgpu dependency to 0.19.1.

[cwfitzgerald]

Weirdly, it should fallback to GL. I wonder if this is gfx-rs/wgpu#5535 making the GL adapter incompatible with the surface.

[ByteNybbler]

Weirdly, it should fallback to GL. I wonder if this is gfx-rs/wgpu#5535 making the GL adapter incompatible with the surface.

Yes, that seems to be the case. The PR you linked appears to fix the issue on my computer, at least when running wgpu's hello_triangle example. Prior to that PR, CPU rendering is incorrectly chosen, but after that PR, my integrated GPU is correctly chosen.

Once the contents of that PR are available in a new wgpu release, Bevy should update its wgpu dependency to that release, and I think that should fix this issue.

[ByteNybbler]

wgpu v0.20.0 was just released, which includes gfx-rs/wgpu#5535, which should fix this issue once Bevy updates its wgpu dependency to that version.

[mnmaita]

wgpu will be updated by #13186

[janhohenheim]

Since WGPU 0.20 is in use now, it would be nice if you could check this on main again @ByteNybbler

[ByteNybbler]

Since WGPU 0.20 is in use now, it would be nice if you could check this on main again @ByteNybbler

I'll be back at my desktop in a bit over a week, so I'll test this again at that time.

[ByteNybbler]

Testing the 2D shapes example on v0.14.0-rc.3 properly selects my integrated GPU adapter! Thank you so much to everyone involved in the fix!

On the other hand, when running the 2D shapes example, I'm now getting the same error spam as #13115, but I'm going to consider the current issue resolved.