Package Details: vkd3d-proton-mingw-git 2.13.r137.g486dd4bf-1

Git Clone URL: https://aur.archlinux.org/vkd3d-proton-mingw-git.git (read-only, click to copy)
Package Base: vkd3d-proton-mingw-git
Description: Fork of VKD3D. Development branches for Protons Direct3D 12 implementation
Upstream URL: https://github.com/HansKristian-Work/vkd3d-proton
Licenses: LGPL-2.1
Conflicts: d3d12.dll, vkd3d-proton
Provides: d3d12.dll, vkd3d-proton
Submitter: loathingkernel
Maintainer: loathingkernel
Last Packager: loathingkernel
Votes: 2
Popularity: 0.000000
First Submitted: 2021-09-22 23:29 (UTC)
Last Updated: 2024-10-02 16:21 (UTC)

Latest Comments

loathingkernel commented on 2023-11-17 23:42 (UTC)

@ms178 thanks for the heads up, updated

ms178 commented on 2023-11-17 22:33 (UTC)

This package needs some updates:

1) There is trouble with the submodule handling due to https://github.com/HansKristian-Work/vkd3d-proton/commit/1c70df298239dcb1f3575b10968bd38416364306

2) The vkd3d-proton-extraopts.patch doesn't apply past 2.10.r142.g1bcda32e-1

csutcliff commented on 2023-03-18 16:35 (UTC)

7b561f37823bfb14eb2ef41537b4dd63e8df8634 breaks the revert of 2ec6c90ab6676e328883651783e3822579234386

loathingkernel commented on 2022-05-29 21:14 (UTC) (edited on 2022-05-31 09:29 (UTC) by loathingkernel)

@ms178 that is the intention to disable it exactly when it is supported by the CPU, and especially in combination with native and O3. For CPUs that don't support AVX, native will ignore the instruction set, so no-avx makes not difference for these CPUs in the first place. I have documented extensively why I made that choice, you can look for it in the PKGBUILD and in the comments. I will concede that in the case of vkd3d it doesn't matter much since dx12 games are predominantly 64bit games. But for dxvk it really does matter.

There is no chance that I will allow CFLAGS from makepkg.conf because to put it simply it would be stupid. I cannot filter all possible bad or incompatible flags that one might have set for their Linux packages. Please realize that you are cross-compiling, not everything is equal. The simplest of flags will work, others will break the build process.

There is not much performance to be squeezed out of AVX and AVX2, I have done extensive benchmarks. If you can prove to me that there is more than a 3% difference between and AVX and non-AVX build, I will consider it.

ms178 commented on 2022-05-29 21:01 (UTC) (edited on 2022-05-29 21:13 (UTC) by ms178)

@loathingkernel

Please take a closer look at what I am actually proposing. You are right in pointing out that some of my changes are redundant if proper makepkg.conf settings have been made. However some people don't do this. My package is dealing with this and is a good starting point for people with Haswell-compatible CPU to squeeze more performance out of their system. Therefore it has some merit to be mentioned here. As stated in my comment, the first proposal to you was to change the cross_cflags+=" -mstackrealign -mno-avx" section and the identical cxxflags entry and delete -mno-avx there. This adds value as you disable AVX even with an edited makepkg.conf and march=native that way because the mno-avx flag is the last on the command line and therefore overrides anything set before it. It also won't hurt people who don't own an older CPU and therefore is suitable for the AUR package.

The second actionable proposal was to clean up the comments regarding AVX/AVX2 at least as soon as the new MinGW toolchain gets into the stable tree. The problems they might have caused in the past seem to be no longer present. The current wording doesn't reflect that and scares away people from trying it out themselves. I don't propose any changes here as you aim to stay compatible for older CPUs in AUR, but you might reconsider these settings for your personal packages on Github (by the way, many thanks for the Haswell build of proton-ge-custom, it saves me a lot of time - but you could improve performance even further this way). Of course using AVX/AVX2 fully in these packages is still somewhat experimental and I only tested three games with it (Battlefield 1, Company of Heroes 2 and Call of Juarez: Gunslinger), but nevertheless you can test it yourself and it seems to be worth a shot at least for dxvk and vkd3d-proton. My linked PKGBUILD can serve as the base for such a Haswell optimized package. But feel free to do what you seem fit, this discussion might encourage others to try it though.

loathingkernel commented on 2022-05-29 20:04 (UTC) (edited on 2022-05-29 20:05 (UTC) by loathingkernel)

@ms178 I don't see any further optimizations in your pkgbuild. People who don't have their CFLAGS in makepkg.conf edited already won't benefit from it, and people who have them edited, surely can edit the pkgbuild on their own, so I can't say I can see the value of you linking to it.

ms178 commented on 2022-05-29 19:06 (UTC)

As commented on your proton-ge-custom package, I just want to document it here as well that the mentioned AVX/AVX2 problems are probably fixed by now - I've tested this today with the testing packages of Mingw's GCC 12.1.0 and binutils and it works fine (tested with Battlefield 1 with DX12). People with a compatible CPU can try my personal PKGBUILD with further optimizations: https://github.com/ms178/archpkgbuilds/blob/main/packages/vkd3d-proton-mingw-git/PKGBUILD

For this AUR package I'd propose to clean up the AVX/AVX2 related comments and deleting the "-mno-avx" entry around in the cross_cflags+=" -mstackrealign" section.