D3D_MODULE_PATH has no affect

[rea987]

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 and libd3dadapter9-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!

[axeldavy]

Have you tried pointing at the .so for D3D_MODULE_PATH ?

[rea987]

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.

[dhewg]

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)

[rea987]

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!

[dhewg]

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? :)

[q4a]

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