panic in wgpu 0.18.0 when AMDVLK 2023.Q4.3 on Radeon RX 7900 XTX

[jokeyrhyme]

• this version/commit of cosmic-term: https://github.com/pop-os/cosmic-term/tree/d9c2ab72eb8c6fe36365cbe19a4d9c033b9d4555
• which uses this version/commit of libcosmic: https://github.com/pop-os/libcosmic/tree/1bd39b17ae7c97934ea214028cd31c578b589e3e
• which uses wgpu 0.18
• on Arch Linux with this version of AMDVLK: https://github.com/GPUOpen-Drivers/AMDVLK/releases/tag/v-2023.Q4.3
• AMDVLK is the default, so this bug causes any wgpu app (e.g. wezterm, cosmic-term, etc) to be unable to launch

launching cosmic-term or AMD_VULKAN_ICD=AMDVLK cosmic-term results in the following error:

wl_drm@53: error 1: Format not advertised by wl_drm
warning: queue 0x563961aec090 destroyed while proxies still attached:
[2024-01-07T20:34:57Z ERROR wgpu_hal::vulkan::adapter] get_physical_device_surface_capabilities: An unknown error has occurred, due to an implementation or application bug
thread 'main' panicked at $HOME/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wgpu-0.18.0/src/backend/direct.rs:778:18:
Error in Surface::configure: Validation Error
Caused by:
Surface does not support the adapter's queue family
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

all of these do work, however:

• launching AMD_VULKAN_ICD=RADV cosmic-term works just fine
• ensuring this AMD_VULKAN_ICD=RADV environment variable is set early enough to apply
• completely uninstalling AMDVLK so that RADV is the only Vulkan implementation

I do not expect this to be addressed in wgpu as this is highly likely to be an AMDVLK bug, just noting this here in case someone else runs into the same issue

[MoSal]

Just out of curiosity, since Wayland appears to be involved, does this issue manifest in X11?

[jokeyrhyme]

Ah, excellent question

I could not reproduce this panic in sway, GNOME wayland, or GNOME x11, so it's likely specific to the early-in-development compositor that I happened to be playing with at the time

I'd previously encountered an earlier bug in AMDVLK that was breaking wgpu so I incorrectly assumed it was another occurrence

Cheers!