[BUG] Pick better vulkan driver by default

[Vinjul1704]

trafficstars

Currently there doesn't seem to be any logic behind what vulkan driver SteamVR picks, which can result in it picking incompatible ones such as lavapipe or 32-bit drivers that either crash SteamVR or freeze the whole system, which was the case for me. This can be worked around manually by using the VK_ICD_FILENAMES environement variable of course, but that's hard to figure out for many people, especially since the error messages or logs don't seem to give any hints.

SteamVR should pick a compatible vulkan driver by default, possibly based on a simple pre-defined list. Alternatively, it should detect issues with the selected vulkan driver and inform the user with an error message.

[ChristophHaag]

You mean vulkan driver, not loader.

32 bit drivers are not going to be selected. You may see an error message regarding a failure to load a 32 bit driver, but the loader will not load the driver in this case, it will go on to try the next driver. That's just how it is set up on "multilib" systems right now.

But it's still a good issue report. In particular SteamVR does not work well with amdvlk. When both amdvlk and radv drivers are available, SteamVR usually uses amdvlk here but it would be better to choose radv.

What makes this more complicated is that drivers are starting to add vulkan API layers that meddle with GPU selection and multi GPU configurations

• https://www.phoronix.com/scan.php?page=news_item&px=Mesa-20.1-Vulkan-Dev-Selection
• https://www.phoronix.com/scan.php?page=news_item&px=AMDVLK-Easier-RADV-Usage
• https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-435.17-Linux-Driver

[Vinjul1704]

Thanks, I changed loader to driver.

About 32-bit drivers not being selected: I only had radv installed, both 64-bit and 32-bit, and SteamVR would either crash or freeze the whole system if I didn't point VK_ICD_FILENAMES to the 64-bit icd file. That's why I assumed it picked the 32-bit one by default and caused issues. That was on my Arch system.

I tried it on fresh Ubuntu 21.04 and Linux Mint 20.1 too with just Steam and drivers from the oibaf PPA installed and again, it caused the same issues unless I used the environment variable.

[mcoffin]

You can also use something like vulkan-device-filter to have it select a more proper device. That's what I've been using (and what I made it for originally xD)

[HadetTheUndying]

It is not SteamVR causing this issue. Your system will pick drivers in alphabetical order. This happens with games too. If you have a lot of Vulkan drivers installed you need to set the VK_ICD_FILENAMES environment variable to select the driver you think should be loaded. In the case of AMD users it should be something like VK_ICD_FILENAMES= /usr/share/vulkan/icd.d/radeon_icd.x86_64.json

[Coreforge]

I've noticed this can also cause problems with OpenVR applications that use OpenGL for rendering. On my system, it was likely trying to use llvmpipe (even though steamVR itself is using RADV just fine), which then lead to some errors and a failed assertion.

Sat Dec 30 2023 16:59:23.857909 [Error] - No GPU timing Vulkan device in CVRCompositorSharedTextures::BeginGPUTimingCommandBuffer!
Sat Dec 30 2023 16:59:23.857931 [Error] - No Vulkan command buffer open in CGpuTiming::MarkEvent!
Sat Dec 30 2023 16:59:23.857947 [Error] - Invalid command buffer in CVRCompositorSharedTextures::FinishOpenCommandBuffer!
Sat Dec 30 2023 16:59:24.276095 [Error] - ASSERT: "Required vulkan device extension is unavailable: VK_KHR_external_semaphore_fd" at /data/src/common/vrcommon/vulkan.cpp:208.

I was getting some debug output from radv as well (I was running hellovr_opengl with RADV_DEBUG=startup), but setting VK_ICD_FILENAMES fixed the issue, so while I don't fully know why this was happening (and only happening with applications that only used vulkan in openvr_api, not ones that also rendered with vulkan), I think this is related.