Expose Windows DLL files shipped with NVIDIA Linux Driver package inside of pressure-vessel
Follow-up from an email thread titled: Re: Pressure-Vessel Interactions with Subdir of /usr/share/
In an upcoming NVIDIA Driver Release Windows DLL files will be added for use with Proton/WINE. These files should be exposed by SLR to Proton so that Windows applications with features that depend on these DLLs can function.
The initial line-of-thought on the driver shipping these DLL files was to place them in a new directory /usr/share/nvidia/wine
. However after initial discussion @smcv suggested that it may be more advantageous to use a path within ${libdir}
for these files so that support for different architectures can be handled gracefully.
The current proposal from NVIDIA's side is put the files in one of the two following locations:
${libdir}/wine
${libdir}/wine/nvidia
[edited to minimize confusion: During discussion we decided ${libdir}/nvidia/wine
was better. —@smcv]
The first seems more ideal to us as it matches the existing convention which has been established by the WINE project. However I understand that it may make things more complicated for implementation within pressure-vessel. To start, NVIDIA is looking to install a single dll file with the Linux Driver Package, nvngx.dll
. Currently we only plan to ship a x86_64 version of this DLL, but having a ${libdir}
based path will be useful for any future endeavors where we may wish to expand platform support.
Please let me know what the preferences are from the above options for your team. I'll work with others internally at NVIDIA to ensure that we reach a installation solution for these DLL files which is amicable to the various customization desires/needs of our customers, and is structured in a way where by default pressure-vessel can easily find these files without additional manual configuration.
Once the DLL(s) are exposed within the vessel, I believe we may also want pressure-vessel to set an environment variable so that Proton can be instructed on where to find them. Currently this aspect of the design is under review in aforementioned email thread with Andrew Eikum, but once that is finalized I'll leave a comment here.