Renaming Intel and Virtio ICD files to resolve Vulkan conflicts with NVIDIA GPUs.

[Steffen70]

Description

This pull request adds a new section to the Linux Troubleshooting Guide in the ALVR GitHub Wiki. The new section provides a solution for users experiencing black screens due to Vulkan conflicts when using an NVIDIA discrete GPU alongside an Intel integrated GPU.

The fix involves renaming the Intel and Virtio ICD files to prevent Vulkan from initializing multiple drivers, ensuring only the NVIDIA GPU is used. Additionally, the section instructs users to update SteamVR's launch options for compatibility.

Changes

• Added a new section titled "Vulkan Conflicts with Multiple GPUs (Intel + NVIDIA)".
• Provided detailed steps for renaming the Intel and Virtio ICD files to resolve conflicts.
• Included instructions on updating SteamVR's launch options for consistency.

[Steffen70]

In my experience, despite setting VK_ICD_FILENAMES to target only the NVIDIA ICD, Vulkan still attempted to initialize multiple drivers, resulting in the Intel GPU being used due to energy-saving defaults. Even after setting the NVIDIA GPU to performance mode, I found that the entire system ended up running on the NVIDIA GPU, which led to increased load and performance issues—especially with the additional processing requirements from SteamVR.

By renaming the Intel and Virtio ICD files, I was able to ensure that Vulkan used only the NVIDIA GPU. This solution allowed me to keep system-wide power efficiency while ensuring SteamVR performed optimally on the discrete GPU without affecting the rest of the system.

While the solution I proposed may involve more direct file manipulation, I found it to be the most reliable way to achieve consistent GPU usage with Vulkan in a dual-GPU setup (high-end laptops), especially in a scenario with high GPU demand like SteamVR.

[Meister1593]

As far as i could see, people using all the envs (prime + vulkan) could work with that Did you include them into your commandline too?

[Meister1593]

Not very comfortable putting such file manipulation with root under guide that supposedly very beginners could see and blindly follow

[Steffen70]

No problem. This is what worked for me, and I tried different things for about 6 hours—this was the solution that worked best. The mirroring didn't work because I believe the X11 session was running on the Intel GPU. So, no problem if you reject the pull request. I just thought it would have helped me a lot to find the solution sooner. Maybe you could add it with a disclaimer.

PS: This did not work for me—Vulkan always started on the Intel chip, even with all the environment variables set.

[The-personified-devil]

Don't know how to make the env-var version reliable, but this is just an absolute no-go. I already don't like disabling the igpu in the bios, but at least that's a clear toggle you can just turn back on and it's comparatively easy to debug in case you forgot you did that change.

[Steffen70]

I understand your concerns, and I appreciate you taking the time to review my pull request.

I do agree that disabling the integrated GPU in the BIOS is not ideal, as the integrated GPU serves an important purpose, especially in laptops for power-saving, which allows longer battery life during non-intensive tasks. That's why I believe keeping the integrated GPU enabled is beneficial, particularly for general use cases.

However, in scenarios involving Vulkan applications—like gaming or VR—nobody really needs to run these demanding applications on the integrated GPU instead of the discrete NVIDIA GPU. Vulkan conflicts and GPU allocation issues have been a challenge for me, and I found that renaming the Intel ICD files (adding a .bak extension) was the most effective solution to ensure that Vulkan consistently used the dedicated GPU. This approach maintains the integrity of the files and can be easily reverted.

I understand that this might not be suitable for everyone, but for those experiencing similar issues, having such an option documented could save them a lot of time and frustration. I do think a disclaimer could help users make informed decisions, knowing that the change is reversible and would not permanently impact their system.