Test the layer that failed
A GPU name in lspci establishes a PCI device. Kernel driver in use establishes its owner. Neither result proves that the application can load a Vulkan driver. The loader discovers userspace ICDs, enumerates physical devices and negotiates required extensions before a game creates its rendering workload. A successful vulkaninfo summary demonstrates enumeration in that environment, not successful presentation or a stable game. A native window test adds presentation evidence, but cannot reproduce every shader, allocation or synchronization path used by a translated Windows game.
Identify the userspace driver
RADV is Mesa’s AMD Vulkan implementation; AMDVLK is a separate userspace implementation whose upstream project is now discontinued. An existing AMDVLK installation may still appear in logs; identifying it is not a recommendation to install it. Both names describe more than the amdgpu kernel binding. Intel’s ANV and NVIDIA’s proprietary Vulkan implementation also have their own userspace requirements. Read driverName, driverInfo and deviceName rather than inferring a Vulkan implementation from a PCI vendor or loaded module. If only a CPU device such as llvmpipe or lavapipe is listed, enumeration can still succeed while the intended hardware driver is unavailable. Two installed ICDs are not inherently a conflict; tie the failure to a specific candidate and application.
Keep the environment comparable
Run the host checks in the logged-in graphical session without sudo. Then compare the game’s runtime: native Steam, Flatpak Steam, a launcher container and a diagnostic shell can expose different libraries. Loader output may mention a discarded manifest and still find a usable driver. Look for the final enumeration result and the first failing API call, not the presence of the word error alone. Record X11 or Wayland separately if the failure concerns window creation or presentation. Changing the desktop session is a comparison experiment; it does not repair missing device features.
Gather evidence before changing the system
Run one command at a time in the relevant host or game environment. Read its requirements and interpretation first. The website displays commands and never runs them.
Read-only observation
lspci -nnkRequirements: pciutils on a PCI-based machine; virtual or USB devices may need other evidence.
Match the display controller’s numeric PCI ID with Kernel driver in use. Kernel modules lists candidates and does not confirm a binding.
Read-only observation
vulkaninfo --summaryRequirements: Vulkan tools installed; use the same graphical user session as the game.
Record the enumerated device, API version and driver fields. This is normally a native host probe of one architecture, not a test inside every game runtime.
Temporary diagnostic environment
VK_LOADER_DEBUG=error,warn,driver vulkaninfo --summaryRequirements: A Khronos-compatible Vulkan loader and vulkaninfo; this may be verbose.
Compare manifest discovery and library-load failures with the final device list. The variable applies to this invocation only; stderr may include private paths.
A controlled test with a way back
If host enumeration succeeds, use one temporary vkcube window test in the same session, then compare a logged game launch. If the host fails, investigate its exact loader or driver error before changing Proton.
Rollback: Close the test window and remove diagnostic launch variables. Restore any saved per-game options; do not delete ICD manifests to make the warning disappear.
What this test cannot establish: A host probe does not cover 32-bit libraries, every sandbox or game-specific feature requirements. Hardware profile links are reference examples, not automatic identification of your installed GPU.
Sources and scope
This editorial review uses primary project and distribution references. It does not establish that a fix has been reproduced on your hardware. Installed versions, the game runtime and the selected graphics API can change the result.
- Khronos: Vulkan loader interfaces and debugging
Loader, layers, driver discovery and VK_LOADER_DEBUG are separate parts of Vulkan initialization.
- Mesa: RADV driver
RADV is Mesa’s Vulkan driver for supported AMD hardware; it is a userspace component.
- AMD: AMDVLK project
AMDVLK is a separate AMD Vulkan userspace implementation whose upstream project is discontinued.