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@winehq.org Reporter: loothelion@nvidia.com CC: leslie_alistair@hotmail.com, z.figura12@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.
https://bugs.winehq.org/show_bug.cgi?id=51541
Liam Middlebrook loothelion@nvidia.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |loothelion@nvidia.com
https://bugs.winehq.org/show_bug.cgi?id=51541
--- Comment #1 from Zebediah Figura z.figura12@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.
https://bugs.winehq.org/show_bug.cgi?id=51541
Sveinar Søpler cybermax@dexter.no changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cybermax@dexter.no
--- Comment #2 from Sveinar Søpler cybermax@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?
https://bugs.winehq.org/show_bug.cgi?id=51541
--- Comment #3 from Zebediah Figura z.figura12@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?
https://bugs.winehq.org/show_bug.cgi?id=51541
--- Comment #4 from Sveinar Søpler cybermax@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.
https://bugs.winehq.org/show_bug.cgi?id=51541
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |6.14
--- Comment #5 from Zebediah Figura z.figura12@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?
https://bugs.winehq.org/show_bug.cgi?id=51541
--- Comment #6 from Zebediah Figura z.figura12@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.
https://bugs.winehq.org/show_bug.cgi?id=51541
jens jp7677@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jp7677@gmail.com
--- Comment #7 from jens jp7677@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.
https://bugs.winehq.org/show_bug.cgi?id=51541
--- Comment #8 from Liam Middlebrook loothelion@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.
https://bugs.winehq.org/show_bug.cgi?id=51541
--- Comment #9 from Sveinar Søpler cybermax@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 :)
https://bugs.winehq.org/show_bug.cgi?id=51541
--- Comment #10 from Liam Middlebrook loothelion@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.
https://bugs.winehq.org/show_bug.cgi?id=51541
--- Comment #11 from Sveinar Søpler cybermax@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?
https://bugs.winehq.org/show_bug.cgi?id=51541
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download
https://bugs.winehq.org/show_bug.cgi?id=51541
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|download |
https://bugs.winehq.org/show_bug.cgi?id=51541
Neko-san nekoNexus@protonmail.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nekoNexus@protonmail.ch
-
WineHQ Bugzilla