Intel vulkan adapter is marked cannot present in intel-only prime mode.

[branan]

Description
The Optimus detection code relies only on the presence of the optimus Vulkan layer. When this layer is found, the intel adapter is marked as unusable to present surfaces. This is incorrect when prime is in intel-only or on-demand mode, as in those cases the intel adapter is absolutely the correct adapter.

This causes the examples (which request surface compatibility) to fall back to OpenGL mode. In code which doesn't specifically request surface compatibililty, like Bevy, this causes the application to panic when attempting to set up the swap chain.

Platform
Ubuntu 20.04 (vendor-installed) on a Dell precision 3551. Prime is in intel-only mode.

[branan]

This was recently added in d48bc62.

[branan]

On my laptop, the intel GPU is the primary one to which all the displays are connected. xrandr lists 0 outputs for the nvidia device:

$ xrandr --listproviders
Providers: number : 2
Provider 0: id: 0x48 cap: 0x9, Source Output, Sink Offload crtcs: 3 outputs: 6 associated providers: 0 name:modesetting
Provider 1: id: 0x28d cap: 0x0 crtcs: 0 outputs: 0 associated providers: 0 name:NVIDIA-G0

[branan]

I think that IF wgpu is the right place to fix it, the change to make is to gate the workaround on both the optimus layer AND the presence of an nvidia GPU. It also likely should be gated on driver version once there's an upstream fix. It looks like there's a "partial" fix that landed in mesa 21.1.0, but my laptop is still on 21.0.3

Gating the workaround on the presence of an nvidia GPU would give us the following cases:

prime intel only

	Surface Compat	No surface compat
LowPower	Intel VK	Intel VK
HighPerformance	Intel VK	Intel VK

prime on-demand

	Surface Compat	No surface compat
LowPower	Intel GL	Intel VK (Incorrectly no present)
HighPerformance	Nvidia VK	Nvidia VK

prime nvidia only

	Surface Compat	No surface compat
LowPower	Nvidia VK	Intel VK (Correctly no present)
HighPerformance	Nvidia VK	Nvidia VK

Bevy should work in all case with that change, since it request a HighPerformance device.

There's still a bevy bug that it doesn't request surface compat even though it should. Making wgpu fail less-often in that case is a workaround in some ways.

[kvark]

Checking both criteria sounds fine to me.

[branan]

Looks like this got fixed in 28ba9d8