Open rea987 opened 2 years ago
Have you tried pointing at the .so for D3D_MODULE_PATH ?
Have you tried pointing at the .so for D3D_MODULE_PATH ?
Pointing d3dadapter9.so, d3dadapter9.so.1 or d3dadapter9.so.1.0.0 had no affect;
$ D3D_MODULE_PATH=/usr/lib/i386-linux-gnu/d3d/d3dadapter9.so.1 protontricks -c 'wine ninewinecfg' 9450
wineserver: using server-side synchronization.
err:d3d9nine:common_load_d3dadapter Failed to load d3dadapter9.so.1 set by D3D_MODULE_PATH (/usr/lib/i386-linux-gnu/d3d/d3dadapter9.so.1)
However, it turned out that latest available official Proton version which is compatible with wine-nine-standalone v0.8 is Proton 4.2-9 which ran DOW:SS via Gallium Nine fine;
$ protontricks -c 'wine ninewinecfg' 9450
ATTENTION: default value of option vblank_mode overridden by environment.
Native Direct3D 9 v0.8.0.385-release is active.
For more information visit https://github.com/iXit/wine-nine-standalone
Although I am happy to see DoW is finally working, I need to point out that Proton 4.2-9 has been released in 27 Jun 2019 which pre-dates recent EAC enabled Proton releases by 2 years. In fact, it looks like Smite has received EAC support which blocks Proton 4.2 whereas Proton 6.20-GE launches Smite without Gallium Nine just fine. Considering that AMD powered Steam Deck will bring so many players to the platform, I believe that it's crucial to wine-nine-standalone catch up with latest Proton releases.
For the non-working case, the /usr/lib/i386-linux-gnu/GL/lib/d3d
path you're seeing is just the last it tried, it will work without setting D3D_MODULE_PATH
with the common default paths: https://github.com/iXit/wine-nine-standalone/blob/master/common/library.c#L105-L111
I suspect proton ships a library which interferes with our dependencies.
Can you please paste the output from ldd /usr/lib/i386-linux-gnu/d3d/d3dadapter9.so.1
?
If you compare that from the old working proton to the new non-working one it hopefully points at the culprint.
I get:
linux-gate.so.1 (0xf7ef3000)
libdrm.so.2 => /lib/i386-linux-gnu/libdrm.so.2 (0xf6a62000)
libLLVM-12.so.1 => /lib/i386-linux-gnu/libLLVM-12.so.1 (0xf1439000)
libexpat.so.1 => /lib/i386-linux-gnu/libexpat.so.1 (0xf1409000)
libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xf13ec000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf13e6000)
libsensors.so.5 => /lib/i386-linux-gnu/libsensors.so.5 (0xf13d5000)
libzstd.so.1 => /lib/i386-linux-gnu/libzstd.so.1 (0xf1304000)
libdrm_radeon.so.1 => /lib/i386-linux-gnu/libdrm_radeon.so.1 (0xf12f5000)
libelf.so.1 => /lib/i386-linux-gnu/libelf.so.1 (0xf12d7000)
libdrm_amdgpu.so.1 => /lib/i386-linux-gnu/libdrm_amdgpu.so.1 (0xf12ca000)
libdrm_nouveau.so.2 => /lib/i386-linux-gnu/libdrm_nouveau.so.2 (0xf12be000)
libvulkan.so.1 => /lib/i386-linux-gnu/libvulkan.so.1 (0xf1259000)
libstdc++.so.6 => /lib/i386-linux-gnu/libstdc++.so.6 (0xf104f000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf0f4a000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf0f2b000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf0f0a000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf0d1c000)
/lib/ld-linux.so.2 (0xf7ef5000)
libatomic.so.1 => /lib/i386-linux-gnu/libatomic.so.1 (0xf0d13000)
libffi.so.8 => /lib/i386-linux-gnu/libffi.so.8 (0xf0d08000)
libedit.so.2 => /lib/i386-linux-gnu/libedit.so.2 (0xf0cd0000)
librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xf0cc3000)
libz3.so.4 => /lib/i386-linux-gnu/libz3.so.4 (0xef4cb000)
libtinfo.so.6 => /lib/i386-linux-gnu/libtinfo.so.6 (0xef49f000)
libxml2.so.2 => /lib/i386-linux-gnu/libxml2.so.2 (0xef2ce000)
libbsd.so.0 => /lib/i386-linux-gnu/libbsd.so.0 (0xef2b6000)
libicuuc.so.67 => /lib/i386-linux-gnu/libicuuc.so.67 (0xef0c7000)
liblzma.so.5 => /lib/i386-linux-gnu/liblzma.so.5 (0xef09b000)
libmd.so.0 => /lib/i386-linux-gnu/libmd.so.0 (0xef08c000)
libicudata.so.67 => /lib/i386-linux-gnu/libicudata.so.67 (0xed573000)
For the non-working case, the /usr/lib/i386-linux-gnu/GL/lib/d3d path you're seeing is just the last it tried, it will work without setting D3D_MODULE_PATH with the common default paths: https://github.com/iXit/wine-nine-standalone/blob/master/common/library.c#L105-L111
Yes, Proton 4.2-9 with wine-nine-standalone v0.8 required no D3D_MODULE_PATH, it simply found and applied correct path.
Can you please paste the output from
ldd /usr/lib/i386-linux-gnu/d3d/d3dadapter9.so.1
?
$ ldd /usr/lib/i386-linux-gnu/d3d/d3dadapter9.so.1
linux-gate.so.1 (0xf7edb000)
libdrm.so.2 => /lib/i386-linux-gnu/libdrm.so.2 (0xf67ab000)
libLLVM-13.so.1 => /lib/i386-linux-gnu/libLLVM-13.so.1 (0xf1179000)
libexpat.so.1 => /lib/i386-linux-gnu/libexpat.so.1 (0xf114c000)
libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xf112e000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf1128000)
libsensors.so.5 => /lib/i386-linux-gnu/libsensors.so.5 (0xf1116000)
libzstd.so.1 => /lib/i386-linux-gnu/libzstd.so.1 (0xf1047000)
libdrm_radeon.so.1 => /lib/i386-linux-gnu/libdrm_radeon.so.1 (0xf1037000)
libelf.so.1 => /lib/i386-linux-gnu/libelf.so.1 (0xf1019000)
libdrm_amdgpu.so.1 => /lib/i386-linux-gnu/libdrm_amdgpu.so.1 (0xf100c000)
libdrm_nouveau.so.2 => /lib/i386-linux-gnu/libdrm_nouveau.so.2 (0xf0fff000)
libdrm_intel.so.1 => /lib/i386-linux-gnu/libdrm_intel.so.1 (0xf0fd6000)
libvulkan.so.1 => /lib/i386-linux-gnu/libvulkan.so.1 (0xf0f75000)
libstdc++.so.6 => /lib/i386-linux-gnu/libstdc++.so.6 (0xf0d58000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf0c53000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf0c34000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf0c12000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf0a15000)
/lib/ld-linux.so.2 (0xf7edd000)
libatomic.so.1 => /lib/i386-linux-gnu/libatomic.so.1 (0xf0a0c000)
libffi.so.8 => /lib/i386-linux-gnu/libffi.so.8 (0xf0a02000)
libedit.so.2 => /lib/i386-linux-gnu/libedit.so.2 (0xf09c7000)
librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xf09bc000)
libtinfo.so.6 => /lib/i386-linux-gnu/libtinfo.so.6 (0xf0993000)
libxml2.so.2 => /lib/i386-linux-gnu/libxml2.so.2 (0xf07c4000)
libpciaccess.so.0 => /lib/i386-linux-gnu/libpciaccess.so.0 (0xf07b7000)
libbsd.so.0 => /lib/i386-linux-gnu/libbsd.so.0 (0xf079e000)
libicuuc.so.67 => /lib/i386-linux-gnu/libicuuc.so.67 (0xf05aa000)
liblzma.so.5 => /lib/i386-linux-gnu/liblzma.so.5 (0xf057e000)
libmd.so.0 => /lib/i386-linux-gnu/libmd.so.0 (0xf0570000)
libicudata.so.67 => /lib/i386-linux-gnu/libicudata.so.67 (0xeea55000)
If you compare that from the old working proton to the new non-working one it hopefully points at the culprint.
How can I do that? Thanks!
From a shell where proton is configured. I don't use proton myself, so dunno how to do that. First search result points to https://github.com/alex4321/steam-proton-wine-shell Maybe that? :)
When I ran old qapitrace:
export D3D_MODULE_PATH=/home/q/git/mesa/cmake-build-gcc-Debug/src/gallium/targets/d3dadapter9/d3dadapter9.so
wine64 /home/q/soft/apitrace/bin/qapitrace.exe ./storm.trace
I got similar error:
err:d3d9nine:common_load_d3dadapter Failed to load d3dadapter9.so.1 set by D3D_MODULE_PATH (/home/q/git/mesa/cmake-build-gcc-Debug/src/gallium/targets/d3dadapter9/d3dadapter9.so)
Native Direct3D 9 will be unavailable.
Problem is gone after updating from last autobuilded apitrace-win32-x86
:
https://github.com/apitrace/apitrace/actions?query=branch%3Amaster
Greetings,
I am unable to utilize Gallium Nine with Ubuntu Mate 21.04 on my AMD Ryzen 7 4800H with Vega 7 system;
https://www.tuxedocomputers.com/en/Linux-Hardware/Linux-Notebooks/15-16-inch/TUXEDO-Book-Pulse-15-Gen1.tuxedo
I have already upgraded Mesa and installed
libd3dadapter9-mesa
andlibd3dadapter9-mesa:i386
via Oibaf's graphics-drivers PPA;https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers/
I have installed wine-nine-standalone via latest protontricks and winetricks. The games I am trying to run with Gallium Nine are Dawn of War: Soulstorm (32 bit) and Smite (64 bit). It looks like the path the tool is looking for
d3dadapter9.so.1
is either hardcoded or I am unable to change it. Its default is/usr/lib/i386-linux-gnu/GL/lib/d3d
;https://gist.github.com/rea987/aa6e18da63b99f726f1809bd97f75f05
Creating the aforementioned directory and linking it to
/usr/lib/i386-linux-gnu/d3d
doesn't make a change.Using D3D_MODULE_PATH does work but ninewinecfg keeps complaining about shared object file;
https://gist.github.com/rea987/e62e9645edbde1151b608b7298b6cc4b
D3D_MODULE_PATH=/usr/lib/i386-linux-gnu/d3d D3D_MODULE_PATH=/usr/lib/x86_64-linux-gnu/d3d:/usr/lib/i386-linux-gnu/d3d D3D_MODULE_PATH="/usr/lib/x86_64-linux-gnu/d3d:/usr/lib/i386-linux-gnu/d3d"
Result of these are the same. I also couldn't figure out how to enter regkey Software\Wine\Direct3DNine\ModulePath and I am unsure if that'd help. What am I missing?
Thank you!