Package Details: dxvk-mingw 2.3.1-1

Git Clone URL: https://aur.archlinux.org/dxvk-mingw.git (read-only, click to copy)
Package Base: dxvk-mingw
Description: Vulkan-based implementation of D3D9, D3D10 and D3D11 for Linux / Wine, MingW version
Upstream URL: https://github.com/doitsujin/dxvk
Licenses: zlib/libpng
Conflicts: d9vk, dxvk
Provides: d9vk, dxvk
Submitter: loathingkernel
Maintainer: loathingkernel
Last Packager: loathingkernel
Votes: 9
Popularity: 0.036817
First Submitted: 2019-12-16 17:34 (UTC)
Last Updated: 2024-03-21 10:44 (UTC)

Pinned Comments

loathingkernel commented on 2019-12-16 19:48 (UTC) (edited on 2019-12-16 19:49 (UTC) by loathingkernel)

This package contains three patches which are not applied by default. Feel free to read the documentation inside the PKGBUILD on what they do and how to enable them.

Don't report issues with these patches enabled to the dxvk creator before posting here. If you do, please be aware that they will probably close your issue nevertheless.

Latest Comments

« First ‹ Previous 1 2 3 4 Next › Last »

ventureo commented on 2021-10-07 15:47 (UTC)

@loathingkernel Okay, thanks anyway!

loathingkernel commented on 2021-10-07 15:11 (UTC) (edited on 2021-10-07 15:14 (UTC) by loathingkernel)

@ventureo I have decided to not include them in this package, unlike these patches, dxvk-async is proven to work, and people know what it is more or less. Instead you can use my personal dxvk PKGBUILD.

ventureo commented on 2021-10-05 17:14 (UTC)

@loathingkernel It is true that it is not stable yet, but I ask you to include it optionally like you did with dxvk-async (uncomment the line). I know that d3d11.floatControls seems to do something similar to this PR, but isn't it distributed only for d3d11? It's just that #2094 seems to work for d3d9 as well.

loathingkernel commented on 2021-10-04 14:25 (UTC)

@ventureo I looked at the PR and it seems that the same things can be achieved by using d3d11.floatControls = False too. From what I can gather from the comments after hastely reading them, is that it might cause issues with Mesa, in which case I don't think I should include it. If I missed something, feel free to tell me. I will test it on my system and see.

ventureo commented on 2021-10-04 14:08 (UTC)

Can you add this patch as an option? According to some information it can help NVIDIA users improve performance.

https://github.com/doitsujin/dxvk/pull/2094

loathingkernel commented on 2021-06-16 11:40 (UTC) (edited on 2021-06-16 11:41 (UTC) by loathingkernel)

@katt actually disabling lto was correct nonetheless as dxvk is unhappy with it performance-wise, at least the last few times I tried it (it was months, maybe a year ago).

You are correct, issues with these flags manifest in wine too, but for some reason, while they are the new makepkg.conf defaults, they have not made it in the makepkg.conf for building in a chroot. Probably I will hard-code some sane flags for it in the PKGBUILD similar to the ones used by proton.

katt commented on 2021-06-16 10:38 (UTC)

Terribly sorry for the confusion, but it seems it wasn't LTO after all, but rather the new CFLAGS in makepkg.conf:

CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions \
        -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security \
        -fstack-clash-protection -fcf-protection"

Seemingly everything in the 2 last rows makes x86_64-w64-mingw32-gcc unhappy, but building with LTO + -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions works. Not sure how I came to my previous conclusion.

loathingkernel commented on 2021-06-03 14:15 (UTC)

Thanks for pointing it out. I don't build with lto, I would have missed it.

« First ‹ Previous 1 2 3 4 Next › Last »