[Bug 51541] New: nvcuda.dll unable to load within Steam Runtime pressure-vessel
https://bugs.winehq.org/show_bug.cgi?id=51541 Bug ID: 51541 Summary: nvcuda.dll unable to load within Steam Runtime pressure-vessel Product: Wine-staging Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: loothelion(a)nvidia.com CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- Created attachment 70384 --> https://bugs.winehq.org/attachment.cgi?id=70384 [PATCH] nvcuda: use libcuda.so.1 SONAME when making dlopen call nvcuda.dll is unable to find libcuda.so when running within the Steam Runtime pressure-vessel environment. This is because pressure-vessel exposes symlinks to driver DSOs based off their SONAME and the SONAME for CUDA is libcuda.so.1, not libcuda.so I've attached a patch which fixes this issue and lets me launch CUDA applications from Steam. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51541 Liam Middlebrook <loothelion(a)nvidia.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |loothelion(a)nvidia.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51541 --- Comment #1 from Zebediah Figura <z.figura12(a)gmail.com> --- (In reply to Liam Middlebrook from comment #0)
Created attachment 70384 [details] [PATCH] nvcuda: use libcuda.so.1 SONAME when making dlopen call
nvcuda.dll is unable to find libcuda.so when running within the Steam Runtime pressure-vessel environment. This is because pressure-vessel exposes symlinks to driver DSOs based off their SONAME and the SONAME for CUDA is libcuda.so.1, not libcuda.so
I've attached a patch which fixes this issue and lets me launch CUDA applications from Steam.
This is only a hack working around the real problem with the patch set. We should be using WINE_CHECK_SONAME like everything else. Though it's really worth examining whether we really want nvcuda in upstream Wine; and, if not, we should remove it from wine-staging. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51541 Sveinar Søpler <cybermax(a)dexter.no> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cybermax(a)dexter.no --- Comment #2 from Sveinar Søpler <cybermax(a)dexter.no> --- (In reply to Liam Middlebrook from comment #0)
I've attached a patch which fixes this issue and lets me launch CUDA applications from Steam.
Thank you Liam. I can confirm this works for using PhysX/Cuda for games like Batman Arkham Knight under steam/proton. This would also be the case for nvencodeapi and nvcuvid if it were to be used under steam/proton. I am not aware of any usecases atm tho. (In reply to Zebediah Figura from comment #1)
This is only a hack working around the real problem with the patch set. We should be using WINE_CHECK_SONAME like everything else.
That would be dependent on libcuda being installed at configure-time tho won't it? Probably not too hard to achieve...
Though it's really worth examining whether we really want nvcuda in upstream Wine; and, if not, we should remove it from wine-staging.
There are many usecases for having this upstream tho. What is the best argument for scratching this altogether? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51541 --- Comment #3 from Zebediah Figura <z.figura12(a)gmail.com> --- (In reply to Sveinar Søpler from comment #2)
That would be dependent on libcuda being installed at configure-time tho won't it? Probably not too hard to achieve...
That's the standard for libraries. In general the idea is that you compile on the same distribution that you distribute the package for, with the assumption that the library will be located in the same place.
Though it's really worth examining whether we really want nvcuda in upstream Wine; and, if not, we should remove it from wine-staging.
There are many usecases for having this upstream tho. What is the best argument for scratching this altogether?
How many programs need CUDA specifically, and can't use OpenCL or some other library we already provide? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51541 --- Comment #4 from Sveinar Søpler <cybermax(a)dexter.no> --- (In reply to Zebediah Figura from comment #3)
(In reply to Sveinar Søpler from comment #2)
There are many usecases for having this upstream tho. What is the best argument for scratching this altogether?
How many programs need CUDA specifically, and can't use OpenCL or some other library we already provide?
https://en.wikipedia.org/wiki/List_of_games_with_hardware-accelerated_PhysX_... One might argue that you can run PhysX calculations just fine on the CPU, and the GPU accelerated PhysX (cuda) is not required, yet afaik a lot of games will check for nvapi/nvcuda to enable this. If nvapi/nvcuda is not present, the game option is not possible to enable. (Aswell as the PhysX software itself ofc). Some games like Witcher 3 uses CPU for PhysX calculation without (afaik) the option to enable this on the GPU. Other than games i am not currently aware of any useful apps you cannot get to run on Linux directly using libcuda. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51541 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |6.14 --- Comment #5 from Zebediah Figura <z.figura12(a)gmail.com> --- Well, that's not quite the question I asked, but it's close enough. It's rather unfortunate that these applications have chosen to lock themselves in to a vendor-specific API, but what else is new? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51541 --- Comment #6 from Zebediah Figura <z.figura12(a)gmail.com> --- (In reply to Zebediah Figura from comment #5)
Well, that's not quite the question I asked, but it's close enough.
It's rather unfortunate that these applications have chosen to lock themselves in to a vendor-specific API, but what else is new?
I guess I should be fair, it's not like there's a generic alternative to PhysX. But we don't really like to add vendor-specific libraries, for obvious reasons. I'll probably try to push nvcuda upstream anyway. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51541 jens <jp7677(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jp7677(a)gmail.com --- Comment #7 from jens <jp7677(a)gmail.com> --- (In reply to Zebediah Figura from comment #6)
(In reply to Zebediah Figura from comment #5)
Well, that's not quite the question I asked, but it's close enough.
It's rather unfortunate that these applications have chosen to lock themselves in to a vendor-specific API, but what else is new?
I guess I should be fair, it's not like there's a generic alternative to PhysX. But we don't really like to add vendor-specific libraries, for obvious reasons.
I'll probably try to push nvcuda upstream anyway.
Thanks for your considerations. Any chance to get this patch into wine-staging in the meantime? I totally get your point in preferring a better approach, though imho this patch does not makes the already existing hack any worse (or better tbf) but it still fixes the issue described in the original posting. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51541 --- Comment #8 from Liam Middlebrook <loothelion(a)nvidia.com> --- Sorry for the slow reply.
We should be using WINE_CHECK_SONAME like everything else.
How does that work for say distro re-packaging? Note that libcuda.so.1 is a DSO which ships with the driver, so there's a multi-hundered MB cost to having it present on a system. I would assume that most distro re-packagers don't install more graphics drivers than they necessarily need, likely if their focus for a machine (I think a lot of it is done on VMs these days) is just re-packaging, it'll just have Mesa as that's default. Also, I'm a bit confused by the WINE_CHECK_SONAME usage. I skimmed various uses of it (and the subsequent definitions that it creates) and noticed that it doesn't pass along information about the SONAME version to the preprocessor. Maybe I'm misreading something, but it seems like the Wine source has to assume some given SONAME version of a DSO anyways, it can't tell the difference between libcurl.so.3 and libcurl.so.4, it will link against whatever it finds and then hope that the interface it's using matches well enough that it won't hit issues at runtime. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51541 --- Comment #9 from Sveinar Søpler <cybermax(a)dexter.no> --- (In reply to Liam Middlebrook from comment #8) Well, i suppose the idea is that wine configure checks for whatever library needed, and set up the soname from that. Depending on the correctness of the configure script, the build-system's SONAME will be detected and put in the include/config.h file (in the build folder). Example: The config.h file will have #define SONAME_LIBGNUTLS "libgnutls.so.30" The source dlls/crypt32/unixlib.c will have a #ifdef SONAME_LIBGNUTLS that basically remove libgnutls related functions including the line that loads the lib: if (!(libgnutls_handle = dlopen( SONAME_LIBGNUTLS, RTLD_NOW ))) in the case that the SONAME is NOT defined at buildtime. I would assume that in the case of multiple SONAME's of the same lib, whatever highest version will be used. Sorry if i completely misunderstood what you mean tho Liam :) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51541 --- Comment #10 from Liam Middlebrook <loothelion(a)nvidia.com> ---
I would assume that in the case of multiple SONAME's of the same lib, whatever highest version will be used.
I'm not sure that is what happens, but either way that wouldn't work. The versions are not guaranteed to be ABI-compatible with one another. Take for example if Bob wrote a patch to wine that adds some new DLL that makes use of libcurl. Bob uses Debian Etch so he wrote the patch against libcurl.so.3. Then Alice comes along and downloads Bob's patch to build Wine for herself with the patch. Alice uses Archlinux so she has libcurl.so.4. While Bob's patch may key off of a particular function being available, it doesn't protect against future ABI changes in other functions. Alice is able to build Wine successfully, the configure step picking up libcurl.so.4. Then at runtime the dlopen call to libcurl.so.4 succeeds, and a subsequent dlsym call for one of the functions succeeds, but the function signature has changed, so then Wine ends up calling that function in a way that results in issues. This solution may not always be applicable, but it seems like in some cases Alice (or someone else) could write patches that have different paths depending on if libcurl.so.3 or libcurl.so.4 are available on the system. This could either be done via an ifdef, or at runtime depending on how portable Wine builds are expected to be. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51541 --- Comment #11 from Sveinar Søpler <cybermax(a)dexter.no> --- Created attachment 71743 --> https://bugs.winehq.org/attachment.cgi?id=71743 Attempt to load libcuda.so.1 if libcuda.so is not found Attached a patch that would attempt to load libcuda.so first, and libcuda.so.1 if that is not found (similar to what seems to happen if _APPLE_ is defined if i understand this correct). I am not disregarding the above info about actually using correct SONAME, but in the meantime, could this be added? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51541 Ken Sharp <imwellcushtymelike(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51541 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|download | -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51541 Neko-san <nekoNexus(a)protonmail.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nekoNexus(a)protonmail.ch -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla