Fedora 43 wine-dxvk integration breakage incident thread

Project Discussion
1

According to @adamwill proposition during recent Fedora Quality Meeting, I am creating this thread to discuss issue with wine-dxvk package. Lets see how it goes.

I brought this issue up in Ask Fedora thread first. I assume this is a bug because people there are not teaching me how to do it properly.

Edit: negative karma in this wine-dxvk update is probably caused by this issue, as application using DirectX8 is probably 32-bit.

Edit 2: see the discussion

The breakage appears to be a direct consequence of changes introduced through Fedora Product Bugzilla ticket. There is related ticket.

What was decision making process behind this change?

What should be done to fix the issue now?

What should be done to avoid such issues in future?

I am pasting the problem description from the Ask Fedora thread here.

There is no i686 DXVK package. No i386 alternatives for DLLs.

$ update-alternatives --list | grep -E 'wine-(d3|dx)'
wine-d3d10(x86-64)      auto    /usr/lib64/wine/x86_64-windows/wine-d3d10.dll
wine-dxgi(x86-64)       auto    /usr/lib64/wine/x86_64-windows/dxvk-dxgi.dll
wine-d3d8(x86-32)       auto    /usr/lib/wine/i386-windows/wine-d3d8.dll
wine-d3d11(x86-32)      auto    /usr/lib/wine/i386-windows/wine-d3d11.dll
wine-d3d10(x86-32)      auto    /usr/lib/wine/i386-windows/wine-d3d10.dll
wine-d3d8(x86-64)       auto    /usr/lib64/wine/x86_64-windows/dxvk-d3d8.dll
wine-d3d10core(x86-64)  auto    /usr/lib64/wine/x86_64-windows/dxvk-d3d10core.dll
wine-d3d9(x86-64)       auto    /usr/lib64/wine/x86_64-windows/dxvk-d3d9.dll
wine-d3d10core(x86-32)  auto    /usr/lib/wine/i386-windows/wine-d3d10core.dll
wine-d3d9(x86-32)       auto    /usr/lib/wine/i386-windows/wine-d3d9.dll
wine-d3d11(x86-64)      auto    /usr/lib64/wine/x86_64-windows/dxvk-d3d11.dll
wine-dxgi(x86-32)       auto    /usr/lib/wine/i386-windows/wine-dxgi.dll

32-bit application inside newly created prefix doesn’t pick up 64-bit DXVK libraries and uses WineD3D despite native DLL overrides.

Putting 32-bit DLLs from the official DXVK release archive into $WINEPREFIX/drive_c/windows/syswow64 solves the problem.

WineD3D/DXVK usage can be confirmed with mangohud.

2

Well, I’m not sure there’s been an ‘incident’ here, outside of the changes in Fedora 43? It smells more like a common issue to me, possibly. The update you linked includes a fairly small change which looks like it was an attempt to fix something here; it may not have worked but it doesn’t look like it could have made anything worse.

@frantisekz can you provide some context here? Thanks.

3

I would argue that

  • breaking change requested by Fedora Engineering Steering Comitee member (or some OpenSUSE-aligned impostor?!) with no understanding of how this technology works (judging by the ticket description, curious to know decision making process behind this) and without making sure it does not break things;

  • change implemented and made it into stable distribution without relevant sanity testing, having WoW64 mode (32-bit/64-bit operations) explicitly mentioned;

  • edits 2, 3: issue being present in stable branch for few months and affecting end users (see the discussion) (at least two one, counting myself and @holk4 from the wine-dxvk bodhi update;

is a one big incident.

I have discovered this when investigating another issue with recent “stable” wine 10.20 build. Appears to be known upstream bug, affecting my PC and existing WINEPREFIX. I haven’t tested the build in advance, it got into stable. No big deal. No intended package removals involved.

I had self-debate about opening a Bugzilla ticket, but as I don’t pay for Fedora, I decided that I am not comfortable burdening the maintainer, as this looks like “the party line” kind of incident. Both in “i686-less” and “blame person, not a process” ways. Especially considering that there already is CLOSED NOTABUG related ticket titled “wine-dxvk-2.6.2-1.fc43.i686 does not exist” about F42-F43 upgrade issues having latest reply containing “Please, do not reopen this issue, it’s either wontfix or not a bug. I am open to merge any PR/MR that could help here, I am just not going to dig more, following the official docs to upgrade /or using supported GUI apps to do so works and that should be enough”.

This also illustrates that more niche or non-trivial issues don’t get much traction in Ask Fedora types of forums. So some way to get attention in such cases may be a good thing, in some cases.

Edit: improved wording; removed the pun (sorry :))

4

I found distro-specific DXVK packages outdated compared to upstream for a while, and just move upstream dlls to where they need to go.

I use a general one-liner that extracts the latest DXVK release to a specific Wine prefix; I do this with Diablo 3 since Bnet client needs 32-bit dlls (D3 is 64-bit):

rm -Rf '/tmp/dxvk-'* && tar -xvzf ~/'Downloads/dxvk-'*'.tar.gz' -C '/tmp' && mv -fv '/tmp/dxvk-'*'/x64/d3d11.dll' '/tmp/dxvk-'*'/x64/dxgi.dll' ~/'.wine/Diablo III/drive_c/windows/system32' && mv -fv '/tmp/dxvk-'*'/x32/d3d11.dll' '/tmp/dxvk-'*'/x32/dxgi.dll' ~/'.wine/Diablo III/drive_c/windows/syswow64' && rm -Rf '/tmp/dxvk-'*

Guild Wars 2 is all-64bit and I extract the latest master artifact (zip vs tar.gz):

rm -Rf '/tmp/dxvk-master' && unzip ~/'Downloads/dxvk-master-'*'.zip' -d '/tmp/dxvk-master' && mv -fv '/tmp/dxvk-master/x64/d3d11.dll' '/tmp/dxvk-master/x64/dxgi.dll' ~/'.wine/Guild Wars 2/drive_c/windows/system32'

Classic WoW (2010/not modern DX11 clients) is 32-bit DX9 (DXVK release tar.gz; this worked last night Ubuntu 25.10 and WineHQ Staging 11.0-rc2 in new WoW64 mode):

rm -Rf '/tmp/dxvk-'* && tar -xvzf ~/'Downloads/dxvk-'*'.tar.gz' -C '/tmp' && mv -fv '/tmp/dxvk-'*'/x32/d3d9.dll' ~/'.wine/World of Warcraft 3.3.5/drive_c/windows/syswow64' && rm -Rf '/tmp/dxvk-'*

Changing those lines around slightly depending on the game arch and DirectX version works easy any OS (Ubuntu, openSUSE, Fedora, even FreeBSD), along with being optional (GW2 can use WineD3D Vulkan backend/no 3rd-party DXVK)

I’m kind of curious why distros package their own DXVK:

  • It’s 3rd-party (more-so than Wine)
  • It’s optional (Wine itself handles DX-to-OGL or VK)
  • More burden (this thread existing :stuck_out_tongue:)
  • Afaik DXVK benefits DX9 for performance (not compliance) where WineD3D apparently doesn’t support shader model 3 for the newer Vulkan backend (was only SM4+ so DX10+)

World of Warcraft from 2010 is the most notable thing I play that’s 32-bit DX9, and out-the-box with WineD3D it performs fine max settings. DXVK can be used, but isn’t a direct benefit to performance, along with introducing shader compile stutter (even with GPL), and master artifacts for a while would corrupt graphics subtly (that’ll possibly come to a release version).

Guild Wars 2 being 64-bit DX11 can use WineD3D’s Vulkan backend (faster than WineD3D doing traditional to OpenGL).

I believe keeping Wine as no-frills/basic as possible keeps the distro-side compatibility easy, and DXVK is largely optional (afaik most people either use Wine as-is basic, or gaming and benefit from newer/upstream DXVK/Proton/VKD3D changes sooner than distro-side maintainers should be tasked with trying to keep up with; Steam/Proton handles it on their side with Experimental). Since Wine themselves (afaik) don’t bundle DXVK, it doesn’t seem like it should be a dependency (Steam/Proton afaik don’t need distro-side Wine/DXVK).

Instead of a wine-dxvk distro-specific package, I’m fine with using DXVK dlls from upstream and find it easier and more-consistent.

5

In theory, benefits of packaging are:

  • users are not affected if third party stops providing built binaries
  • packaged versions of wine and dxvk can be tested together to ensure version compatibility and “just works” from a user perspective.
  • edit: supply chain security

Having a way (like setup-dxvk script) to refresh existing prefix with new DLLs (or rollback to previous set of libraries) may be good to have.

1 Like
6

Yeah, as per report in 2413536 – Can't run games that use D3D8 in Fedora 43, Library d3d8.dll not found , this has nothing to do with the packaged dxvk, as the issue occurs even with all dxvk packages removed, and only vanilla wine installed.

This suggests it’s wow64 transition related, but there is nothing to do wine-dxvk package side (nor our wine packaging probably).

7

According to DXVK upstream, 64-bit wine prefix has to have both 64-bit and 32-bit DXVK DLLs in system32 and syswow64 respectively. For 32-bit prefix it is enough to have 32-bit DLLs in system32

Current wine-dxvk-2.7.1-4.fc43 build is not shipping 32-bit DLLs files inside x86_64 packages and has no i686 packages. So there is no way to get 32-bit DXVK DLLs through official Fedora repositories. These are required fort 32-bit applications in 64-bit prefix. These are also required for 32-bit applications in 32-bit prefix.

I have upgraded to F43 by removing and installing wine before and after upgrade, so I just now see that https://bugzilla.redhat.com/show_bug.cgi?id=2401666 still goes on. Cool.

Recent F43 wine builds have both x86_64 and i686 RPMs. x86_64 RPMs include both 64-bit and 32-bit DLLs.

$ dnf --disablerepo='*' --enablerepo=updates provides '*/wine-d3d9.dll'
Updating and loading repositories:
Repositories loaded.
wine-core-10.19-1.fc43.x86_64 : Wine core package
Repo         : @System
Matched From :
Filename     : /usr/lib64/wine/i386-windows/wine-d3d9.dll
Filename     : /usr/lib64/wine/x86_64-windows/wine-d3d9.dll

wine-core-10.20-2.fc43.i686 : Wine core package
Repo         : updates
Matched From :
Filename     : /usr/lib/wine/i386-windows/wine-d3d9.dll

wine-core-10.20-2.fc43.x86_64 : Wine core package
Repo         : updates
Matched From :
Filename     : /usr/lib64/wine/i386-windows/wine-d3d9.dll
Filename     : /usr/lib64/wine/x86_64-windows/wine-d3d9.dll

To match that it is required to:

  • provide 32-bit DXVK DLLs in wine-dxvk-*.x86_64 packages in addition to x86_64 DLLs.
  • provide 32-bit DXVK DLLs in wine-dxvk-*.i686 packages

because now

$ dnf --disablerepo='*' --enablerepo=updates provides '*/dxvk-d3d9.dll'
Updating and loading repositories:
Repositories loaded.
wine-dxvk-d3d9-2.7.1-4.fc43.x86_64 : DXVK D3D9 implementation
Repo         : @System
Matched From :
Filename     : /usr/lib64/wine/x86_64-windows/dxvk-d3d9.dll

wine-dxvk-d3d9-2.7.1-4.fc43.x86_64 : DXVK D3D9 implementation
Repo         : updates
Matched From :
Filename     : /usr/lib64/wine/x86_64-windows/dxvk-d3d9.dll

Regarding the update and stock d3d8.dll.

I see that wine package does not provide 32-bit d3d8.dll in WoW64 mode according to spec file.

Uninstalling wine-dxvk doesn’t change a thing in this case because nothing provides alternative for 32-bit d3d8.dll.

I tried to install alternative manually with

$ sudo alternatives --install /usr/lib64/wine/i386-windows/d3d8.dll 'wine-d3d8(x86-32)' /opt/dxvk-2.7.1/x32/d3d8.dll 20

and d3d8.dll is indeed not copied into new prefix.

Still, this is not in any way a valid reason to not ship required 32-bit DLLs, but one more argument to introduce a dxvk-setup script (like Debian has, for example) to allow updating old and setting up new prefixes to cover Direct X 8 case.

8

Yes, and is a bug that it doesn’t, but most likely in wine upstream, or our wine package, I don’t know.

If you just dnf install wine on clean F43+, it doesn’t pull a single i686 package in, nor it should.

That wine-dxvk doesn’t builds 32 bit dlls in wow64 way is another issue (prs against the package are welcome, but as wow64 only, we aren’t reintroducing the old multilib way, and are following wine here).

9

Okay, you can try dxvk build from a copr Making sure you're not a bot! if you want @jv025 - I am not going to push it into the repositories before we have wine resolved in F43 ( Making sure you're not a bot! )

10

World of Warcraft runs great with Latest Proton selected in Lutris.

1 Like