Driver ID and vkResetCommandPool ValidationError

[sashabjorkman]

Hello, if I run wgpu/examples/cube using cargo run --example cube I get the following errors printed to my terminal: wgpu_error.txt

The cube is shown as expected. But if I try to run any example from the Bevy engine, nothing is drawn. Probably because the Bevy engine treats these errors a something more fatal than the example code does. Either way, even if the cube shows up, the terminal being spammed with errors doesn't seem right.

If I instead try to use the GL backend by running WGPU_BACKEND=gl cargo run --example cube, the following happens:

thread 'main' panicked at 'No suitable GPU adapters found on the system!', wgpu/examples/cube/../framework.rs:136:14

When Bevy was using an older version of wgpu, I was able run programs using wgpu just fine. Something that handles device detection must have changed recently, causing this issue.

Platform:

• Ubuntu Linux 20.04.3 LTS x86_64
• X11 DWM
• NVIDIA GeForce GTX 1660 SUPER
• AMD Ryzen
• NVIDIA 470 Drivers

Warmest regards

[sashabjorkman]

In other similar issues vulkaninfo was requested. So in case it comes in handy, here it is: vulkaninfo.txt

[kvark]

Thank you for filing this!
Hypothetically, here is what's happening:

1. Your system exposed NV GPU as well as a software implementation (lavapipe)
2. Our example defaults to "LowPower" preference. wgpu sees 2 adapters, one of which is a high-power one, and chooses the other.
3. Lavapipe is non-conformant, and it returns our zero-initialized driverId and other fields in PhysicalDeviceVulkan12Properties
4. Passing this back to Vulkan triggers the validation layer yelling at us

So there are multiple issues at play here. One is Lavapipe being exposed but non-conformant. It's really difficult to put a finger on who's responsible for fixing this. Your system configuration is somewhat to blame (but not 100%), since it provides the lavapipe implementation visible to Vulkan loader. It's not something wgpu has rights to interfere with.

However, we can probably do better with priorities. We shouldn't use a software implementation just because the user selected "LowPower" - this is unlikely be welcome. The user should get a software impl only if they either force it, or there is nothing else to choose from. So this is something I'm going to address now.

thread 'main' panicked at 'No suitable GPU adapters found on the system!'

That's a bit surprising. It'd expect your platform to offer GLES-3 just fine. Could you attach logs with WGPU_BACKEND=gl RUST_LOG=wgpu_hal=debug?

You could also try WGPU_POWER_PREF=high cargo run --example cube, I think it would pick your NVidia properly and work as expected. In this case, try to see if Bevy offers a way to configure this as well, at least for a workaround.

[kvark]

Hmm, interesting. The power preference should already pick your NVidia instead of Lavapipe:

        let preferred_gpu = match desc.power_preference {
            PowerPreference::LowPower => integrated.or(other).or(discrete).or(virt).or(cpu),
            PowerPreference::HighPerformance => discrete.or(other).or(integrated).or(virt).or(cpu),
        };

[kvark]

What does wgpu-info say?

[sashabjorkman]

Yes, as you have correctly predicted it would seem like the NVidia drivers are already being selected and that Lavapipe is not the issue since running WGPU_POWER_PREF=high cargo run --example cube yields the same result.
This is the log for running: WGPU_BACKEND=gl RUST_LOG=wgpu_hal=debug cargo run --example cube: gl_hal_log.txt
This is the output of running cargo run --bin wgpu-info: wgpu-info.txt

Warmest regards

[kvark]

EGL reports as unable to present to the window natively:

[2022-01-31T23:32:46Z WARN wgpu_hal::gles::egl] EGL says it can present to the window but not natively

This may be due to the fact your system considers the display to be attached to AMD, thus it says NVidia can't present on it natively, but it should still be able to present. We just don't know that and we are being conservative here.

So that explains why GL doesn't work for you, at least.

[naturalfreak]

Same problem here

[cwfitzgerald]

Closing this as stale - if the issue with vkResetCommandPool still happens, please refile (though may be #3193)