dxvk broken: missing libmcfgthread-1.dll, stack overflow while initializing

[yshui]

Describe the bug

dxvk dlls are linked with libmcfgthread-1.dll, but setup_dxvk.sh copies a mcfgthread-12.dll

wine error:

04a0:err:module:import_dll Library libmcfgthread-1.dll (which is needed by L"C:\\windows\\system32\\d3d9.dll") not found
04a0:err:module:import_dll Library d3d9.dll (which is needed by L"app.exe") not found
04a0:err:module:loader_init Importing dlls for L"app.exe" failed, status c0000135

Additional context

Add any other context about the problem here.

Notify maintainers

@reckenrode

---

Add a 👍 reaction to issues you find important.

[yshui]

and even after i copied it, it just doesn't work.

[yshui]

building with win32 thread model works, but i don't know if this is the right solution or not. i will leave it to the maintainers to figure out what's going wrong here.

[wegank]

As the transition to GCC 13 is still incomplete in nixpkgs, I don't think mcfgthreads_pre_gcc_13 below can be replaced by mcfgthreads any time soon. If we still stay with MCF Gthread, probably with (pkgsCross.mingwW64.threadsCrossFor pkgsCross.mingwW64.stdenv.cc.version).package...

nixpkgs/pkgs/by-name/dx/dxvk/package.nix

Lines 34 to 35 in 854f467

	--subst-var-by mcfgthreads32 "${pkgsCross.mingw32.windows.mcfgthreads_pre_gcc_13}" \
	--subst-var-by mcfgthreads64 "${pkgsCross.mingwW64.windows.mcfgthreads_pre_gcc_13}"

[yshui]

I think dxvk just doesn't work with gcc 13 mcfgthreads...

04d4:err:module:loader_init "d3d9.dll" failed to initialize, aborting
04d4:err:module:loader_init Initializing dlls for L"app.exe" failed, status c00000fd

[yshui]

whether mcfgthreads is statically linked or not doesn't matter.

at the same time "win32" thread model works normally

[yshui]

I think it's this bug: lhmouse/mcfgthread#91 we should grab that patch

status c00000fd in wine error is stack overflow.

[yshui]

or, the other option, is not using mcfgthread for i686.

[reckenrode]

Does the following patch fix DXVK for you?

diff --git a/pkgs/top-level/all-packages.nix b/pkgs/top-level/all-packages.nix
index 1a7bfa536675..b9bfdb71f077 100644
--- a/pkgs/top-level/all-packages.nix
+++ b/pkgs/top-level/all-packages.nix
@@ -40212,6 +40212,9 @@ with pkgs;
 
   dump = callPackage ../tools/backup/dump { };
 
+  dxvk_1 = pin-to-gcc12-if-gcc13 (callPackage ../by-name/dx/dxvk_1/package.nix { });
+  dxvk_2 = pin-to-gcc12-if-gcc13 (callPackage ../by-name/dx/dxvk_2/package.nix { });
+
   ec2stepshell = callPackage ../tools/security/ec2stepshell { };
 
   ecdsatool = callPackage ../tools/security/ecdsatool { };

[yshui]

@reckenrode that might work, but you would eventually have to fix the copied dlls at least... and we need to figure out what to do with the infinite recursion bug, do we just wait until mcfgthread fix it?

[reckenrode]

I assumed the DLL copying issue was because GCC 13 had renamed it, hence making sure GCC 12 is used with the pre-13 DLL.

Given that the transition is still in progress, I’d prefer to stick with a known-working version of GCC for the 2.3 release. It can be revisited with the next release of DXVK.

Are the nixpkgs GCC maintainers aware mcfgthread issue? It seems like it should affect more than just DXVK.

[yshui]

@reckenrode this issue only affects mcfgthread on 32bit windows, probably nobody noticed it.

[reckenrode]

@reckenrode this issue only affects mcfgthread on 32bit windows, probably nobody noticed it.

I’ll look at applying the patch and submitting a PR to nixpkgs. I’ll also fix the script. One thing I didn’t realize until just now is the version of GCC used is depending on the host platform not the target. Darwin is still using GCC 12, so it’s cross-compiling with GCC 12 while Linux is using GCC 13 to cross-compile to Windows.

[reckenrode]

l apologize for not fixing this issue sooner. I was looking at including in with the DXVK 2.3.1 update, but since it requires the latest Vulkan SDK (1.3.280.0) for the VK_NV_raw_access_chains extension, I going split the change into to PRs: a fix (that I can backport to 23.11 even though it's not affected), and the update (after the current staging-next cycle ends).

I also plan to port the fix back to DXVK 1.10.3 because Darwin with using that version for now. If I can drop the use of mcfgthread from both dxvk_1 and dxvk 2, I'll do that to simplify things. Either way, I'll need to include support for detecting and advising the user to clean up the old mcfgthread-12.dll (with an option to automate it).

[yshui]

I think we should avoid using mcfgthread altogether for i686.

[reckenrode]

I think we should avoid using mcfgthread altogether for i686.

The plan is to drop it completely for both i686 and x86_64. I just want to confirm that DXVK 1.10.3 still builds, so I can continue using the same script for both versions.

[reckenrode]

Status update: I haven’t forgotten about this. I needed to fix DXVK for my ld64/cctools update testing. I can confirm DXVK 1.10.3 builds and works without mcfgthread on Darwin. Performance in FFXIV even seems better (though my testing was pretty limited because joystick support in recent Wine releases is completely broken for me).

I’m going to finish up the scripting changes and get a PR created for that today or tomorrow. I’ll need help from Linux users testing because I don’t have access to Linux systems with meaningful GPUs.

[reckenrode]

#302187 is the PR with the DXVK update and fixes.

I’m pinging everyone who ❤️’d my previous message for testing: @LovingMelody, @yshui, @ghishadow.