Arch Linux User Repository

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.

@AvianaCruz That's a paru problem, not a PKGBUILD problem.

https://github.com/Morganamilo/paru/issues/763#issuecomment-1140317769

There is nothing in the wiki about pinning submodule commits (not only that, but git will resolve the correct commits on its own) but also official PKGBUILDS from the repos don't do that.

https://github.com/archlinux/svntogit-community/blob/packages/ppsspp/trunk/PKGBUILD

There is a clearly defined way for PKGBUILDs to indicate that something is supposed to build a VCS version of a package and that is the suffix in the package name. I don't see why paru tries to be smart and accommodate for bad package names.

@loathingkernel It would be better to also enforce the versions of Vulkan-Headers and SPIRV-Headers since this is not a "-git" package, so that paru will not trigger update every time when https://github.com/KhronosGroup/Vulkan-Headers.git updates.

@patrick.kopper Thanks for noticing it, reverted.

Please checkout the specific commit of the dxvk git repository (#commit=8f8a936 for 2.0). This package is not named as a "-git" package, yet it will just pick the current HEAD of the dxvk master branch.

@loathingkernel thanks for info I was suspected the same. For some reason after trying to edit my post and use markdown to format console output my question is lost, sorry about that.

@Kerriganx I am aware of it, and that is why the dxvk-async patch is commented out in the PKGBUILD as it was uploaded before you LOCALLY modified it. It has not been updated yet. Why are you posting this here without any context of any kind, a question or something? What do you expect me to do with it?

==> Starting prepare()...
patching file meson.build
Hunk #1 succeeded at 108 with fuzz 2 (offset -21 lines).
patching file src/dxvk/dxvk_context.cpp
Hunk #1 succeeded at 4138 (offset 21 lines).
Hunk #2 succeeded at 4379 (offset 21 lines).
Hunk #3 succeeded at 4401 (offset 21 lines).
Hunk #4 succeeded at 4809 (offset 21 lines).
Hunk #5 succeeded at 5223 (offset 21 lines).
patching file src/dxvk/dxvk_context.h
patching file src/dxvk/dxvk_graphics.cpp
Hunk #2 FAILED at 72.
1 out of 4 hunks FAILED -- saving rejects to file src/dxvk/dxvk_graphics.cpp.rej
patching file src/dxvk/dxvk_graphics.h
Hunk #1 succeeded at 199 (offset 12 lines).
Hunk #2 succeeded at 214 (offset 12 lines).
Hunk #3 succeeded at 243 (offset 12 lines).
Hunk #4 succeeded at 273 with fuzz 2 (offset 13 lines).
patching file src/dxvk/dxvk_image.h
Hunk #1 succeeded at 552 (offset 13 lines).
Hunk #2 succeeded at 595 (offset 13 lines).
patching file src/dxvk/dxvk_options.cpp
Hunk #1 succeeded at 9 (offset 1 line).
patching file src/dxvk/dxvk_options.h
Hunk #1 succeeded at 18 (offset 3 lines).
patching file src/dxvk/dxvk_pipecompiler.cpp
patching file src/dxvk/dxvk_pipecompiler.h
patching file src/dxvk/dxvk_pipemanager.cpp
patching file src/dxvk/dxvk_pipemanager.h
Hunk #2 succeeded at 101 with fuzz 1.
patching file src/dxvk/meson.build
==> ERROR: A failure occurred in prepare().
Aborting...

@ms178 the goal of the pkgbuild is first and foremost to compile the software in a way that it works. On the other hand, people who want to experiment will find their way around the pkgbuild and probably don't require any handholding. To put it simply, if someone needs for it to be made simpler than it already is, they should not be messing with it in the first place. For example your adapted patch to dxvk is utterly wrong, you are force-enabling instruction sets irregardless of CPU. Your suggestions seem to me to conflict with each other.

That is not to say that you are wrong. These workarounds might not be needed any more, but that is not something that I will experiment with in the pkgbuild I upload here. If enough evidence is gathered that they are not an issue any more, only then I will consider changing it.

@loathingkernel

Sure, it is still experimental, but I want to encourage people to try it as some former issues might be fixed by now. A workaround was mentioned in the linked bug report https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49001

Also the assembler in binutils 2.38 gained the -muse-unaligned-vector-move option that helps with an AVX alignment issue, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412

For the last issue, it seems Debian carries a patch around: https://salsa.debian.org/mingw-w64-team/gcc-mingw-w64/-/blob/master/debian/patches/vmov-alignment.patch

I don't know if the AUR mingw-gcc package carries that one around, but that issue seems to be solved that way.

Only more testing will give us more insight after all to move this forward...

@ms178 testing one game is not adequate evidence that they are not required any more.