protonscr

Wine 9.0 flatpak not working with flatpaked dxvk

dxvkclosed probably not our bug
doitsujin/dxvk#4064 · opened 2024-06-08 by ColinKinloch · updated 2026-02-12 · 8 comments · github
3 matching comments, n / p to jump
CColinKinloch 2024-06-08 github

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 the WINEDLLPATH env var to have wine preferentially load them if the org.winehq.Wine.DLLs.dxvk package is installed.

Fiddling around with WINEPATH and WINEDLLOVERRIDES it seems that I can get it working so long as all the following are true:

  • The dll overrides are set to native: WINEDLLOVERRIDES='d3d9,d3d10core,dxgi,d3d11=n'
  • The dxvk dll locations are in wines PATH: WINEPATH='/app/dlls/lib32;/app/dlls/lib'
  • The dlls are not flagged as builtin
  • The the original dlls don't already exist in windows/system32 etc.

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.

BBlisto91 2024-06-15 github

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.

CColinKinloch 2024-06-15 github

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?

BBlisto91 2024-06-18 github

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.

BBlisto91 2024-10-15 github

@ColinKinloch Are you still having this issue to this day?

CColinKinloch 2024-10-15 github

I'll need to check.
The wine flatpak has been updated to the 24.08 version of the platform. Whereas the dxvk extension is still on 23.08, so isn't loaded.
If it doesn't work I guess it won't get updated to 24.08 which solves the issue :)

CColinKinloch 2024-10-15 github

I checked and it's still an issue.

Uuser1-github 2025-07-10 github

My question is firstly what changed between wine 8 and 9 that caused loading dxvk as builtin to not work.

Don't know if this information would be helpful at this point, but after some more investigation it turns out Wine, since version 9.0 doesn't allow loading dlls marked as builtin from non-system directories. So that's the main reason the DXVK extension has stopped working.

Also, out of curiosity, if I set WINEDLLOVERRIDES='d3d9,d3d11,etc=n' with the appropriate WINEDLLPATH, will Wine still prefer loading the system builtin dlls?

I'm just toying with the idea of making a new DXVK extension for org.winehq.Wine (that won't be autodownloaded like the previous one), but if the only way to make the WINEDLLOVERRIDES=n method work involves removing some system builtin dlls from system32, theres probably no sane way to make such extension at this point.

BBlisto91 2026-02-12 github

Also, out of curiosity, if I set WINEDLLOVERRIDES='d3d9,d3d11,etc=n' with the appropriate WINEDLLPATH, will Wine still prefer loading the system builtin dlls?

It should not load them if marked as builtin then

Launch options