Open ColinKinloch opened 3 weeks ago
Just for clarity. None of the devs maintain the flatpak nor use it.
Builtin in the case of Wine usually means to use the DLLs shipped with Wine it self which for Direct3D would be wined3d not dxvk. But i don't personally know about flatpak terminology.
Understand it's not maintained by the devs I just thought that posting here would have the highest likelihood of a insightful response.
The wine flatpak defines the env variable WINEDLLPATH
and the dxvk extension places the dxvk dlls in that path.
So if the extension is installed wine loads dxvk as builtin and ignores wined3d.
Since Wine 9.0 this fails. Does dxvk depend on being builtin wined3d in some way?
Gotcha. Didn't know about those.
I tried locally (not flatpak) to play with both winebuild --builtin
and WINEDLLPATH
but couldn't get Wine to load the dxvk DLLs as builtin with either Wine 7, 8 or 9.
Since the wine flatpak was updated to 9.0 the flatpaked version of dxvk no longer works (https://github.com/flathub/org.winehq.Wine/issues/119).
The flatpak version works by marking the dlls as builtin using
winebuild --builtin
and using theWINEDLLPATH
env var to have wine preferentially load them if theorg.winehq.Wine.DLLs.dxvk
package is installed.Fiddling around with
WINEPATH
andWINEDLLOVERRIDES
it seems that I can get it working so long as all the following are true:WINEDLLOVERRIDES='d3d9,d3d10core,dxgi,d3d11=n'
WINEPATH='/app/dlls/lib32;/app/dlls/lib'
My question is firstly what changed between wine 8 and 9 that caused loading dxvk as builtin to not work. And secondly whether there is a more appropriate way to package DXVK.
Personally I'd prefer being able to enable/disable them by editing only
WINEDLLOVERRIDES
rather than having them used whenever they're installed.