Vulkan Runtime Packaging on Windows NT Systems

nVidia currently ships Vulkan Runtime, a.k.a. VulkanRT-Installer.exe within its driver package, referenced and included in various files, both in nv_disp.cat and in nv_dispwi.inf, for instance, shipped with Quadro driver version R375 U8 (377.48). Wherever a driver installation proceeds from .cat and .inf files, which happens both to setup.exe installation and to DISM with /Add-Driver, VulkanRT-Installer.exe is copied to Windows Driver Store, which nVidia’s co-installers nvdispco64.dll and nvdispgenco64.dll call in silent mode. This post serves to bring to light problems of installation process mentioned before and to provide a backward-compatible remedy to these problems.

Both Intel and AMD, at this time, ship their own Vulkan Runtime files within their respective driver packages in a manner not dissimilar to that of nVidia, which entails, on a hypothetical system with multiple GPU packages, each from a different vendor, a collision of Vulkan Runtime files. An extension standardized in one Vulkan version would thus become unavailable when another GPU driver overwrites the Runtime. To examine the issue in a more realistic context, simply imagine a notebook computer with both Intel and nVidia GPU packages, with either Optimus or Microsoft Hybrid Graphics switched on.

To eliminate potential collision between Vulkan Runtime files from different driver packages, a higher authority has to step in to deal with Vulkan Runtime installation on behalf of GPU vendors. However, this is unlikely, since Microsoft, authority would-be, runs a rival interface of its own. And yet, relegating duties of maintaining Vulkan Runtime to system administrators is not an option either, since such practice hurts out-of-box user experience.

A compromise is then in order. GPU vendors such as nVidia should still ship Vulkan Runtime, however, in a different manner. Instead of imposing VulkanRT-Installer.exe on the driver package, which is monolithic and hard to modify thanks in part to WHQL, nVidia should instead focus on providing Vulkan Runtime as a default installation option that resides outside the driver tree that is Display.Driver. Already capable of handling packages and options, nVidia’s setup.exe is then supposed to provide an additional option for Vulkan, which users can switch off. Now that VulkanRT-Installer is removed from the driver package proper and is now handled by setup.exe instead, this allows enterprise customers, who provision Windows NT images to their computers, to ship a Vulkan Runtime of their own choice.

Shipping colliding versions of Vulkan Runtime brings only further frustration and market fragmentation, all of which serve to impair both user and developer experience in a manner that will only fuel the popularity of competing interfaces such as Direct3D 12. Do consider also extreme use cases such as Windows 10 S and Windows 10 IoT, where Microsoft primed Direct3D to succeed.

Please, nVidia, move Vulkan Runtime out of the driver-exclusive tree.

The VulkanRT-Installer is designed so that it will never replace a new loader with an old loader. In other words, if the NVIDIA display driver is installed first and it installs VulkanRT-1.0.51.0 and then the Intel display driver is installed which has VulkanRT-1.0.48.0, the system will keep VulkanRT-1.0.51.0.

Are you seeing a different behavior? If so, that’s a bug we should file with LunarG (https://vulkan.lunarg.com/).