Question on bundling vulkan-1.dll
gkarpa opened this issue · 4 comments
Hi,
I'd like to ask if it is safe to assume that the vulkan-1.dll from the Vulkan Runtime components zip will work with any driver/graphics card instead of using the one that gets installed with the occasional gpu's drivers. I want to support Lavapipe in my project for systems without gpu so I believe I need -please correct me if I'm wrong- to bundle the vulkan-1.dll file (or require the Vulkan RT to be installed, but I prefer the former) with the rest of the binaries. The thing is that this .dll will get loaded first even in a typical system with gpu present and drivers installed, hence my original question.
I would also like to understand why vulkan-1.dll appears to have significant differences in its size depending on various sources. For example the one inside the Vulkan RT components zip file is more than double the size (~1.4 MB) than the one in my System32 folder (640 KB), which I assume got installed there via my gpu's drivers. Thanks in advance.
George
The vulkan-1.dll that is installed by graphics drivers is the same thing as the Vulkan Runtime. The exact version used may differ, but with the ABI compatibility that should not matter.
The vulkan-1.dll in your System32 folder may be very old. The easiest way to check is to right click on the vulkan-1.dll in System32, open the properties window for it, go to details, and check the "File version". My system says 1.3.261.1 and is ~1.4MB.
Also, make sure you are comparing like for like (don't compare 32 bit & 64 bit binaries).
I do not recommend shipping vulkan-1.dll in your application directly, though in the case of using a fallback software renderer that recommendation is not as strong. The runtime installer only every 'updates' the loader on the system, so it never installs an older loader ontop of a newer one. This is advantageous because it ensures that a newer loader is always on the system, in the sense that you do not have to update the installer in your application in order for drivers newer than your application to be able to use newer vulkan versions.
If you are shipping a software fallback with the application, it is not the end of the world to ship the vulkan-1.dll with the application, since if you are trying to support systems that do not support vulkan, then there is no reason for vulkan-1.dll to be in System32. And better yet, not installing to System32 will prevent other vulkan applications from finding the loader but failing to create an instance due to missing drivers (because there are no system installed drivers, your application is providing it).
Though, I have to say that the environment variables which tell the loader where to look for drivers are disabled when running with elevated privileges due to security concerns. There is no good way around this unfortunately, not without requiring elevated privileges in the installer. (Who would of thought being able to load arbitrary DLL's just by setting an environment variable is a bad idea...)
Thanks for the tips Charles.
So it looks like the only downside in shipping vulkan-1.dll is that the application will not be able to make use of newer drivers implementing more recent vulkan versions than the loader we ship. I think this is ok right now and the extra automation is worth it. We can keep the loader up to date at will.
I'm aware of the environment variables being disabled in the elevated case (kudos to the detailed documentation!) but this is not a problem since we don't run the application in elevated and the environment variable is being set via code in every execution, and it's not persistent. Unless you're stating something that I didn't get :)
George
Nope that’s the exactly what I meant about security stuff. And while there is a concern that drivers may be located differently in the future, replacing a dll is not the end of the world. I think this answers the questions I saw and so I’ll close the issue. Feel free to reopen if you think it wasn’t addressed or if you have subsequent questions.
It's been perfectly addressed, thank you again for your time.
George