Package Details: proton-ge-custom 2:GE.Proton9.22-1

Git Clone URL: https://aur.archlinux.org/proton-ge-custom.git (read-only, click to copy)
Package Base: proton-ge-custom
Description: Compatibility tool for Steam Play based on Wine and additional components, GloriousEggroll's custom build
Upstream URL: https://github.com/GloriousEggroll/proton-ge-custom
Keywords: dxvk proton steam valve vkd3d wine
Licenses: custom
Provides: proton
Submitter: loathingkernel
Maintainer: loathingkernel
Last Packager: loathingkernel
Votes: 40
Popularity: 2.23
First Submitted: 2020-03-23 23:52 (UTC)
Last Updated: 2024-12-30 14:02 (UTC)

Dependencies (117)

Required by (7)

Sources (12)

Pinned Comments

loathingkernel commented on 2023-10-12 10:43 (UTC) (edited on 2023-10-12 10:45 (UTC) by loathingkernel)

@rekman, thank you for looking into CUDA issues, at least it gives me an idea on how to fix it. That being said, my position remains to build it in a clean chroot, away from the locally installed packages. It is not feasible for me to carry patches for the build systems of various subprojects in the long run.

By enabling the 0003-AUR-Remove-kaldi-openfst-vosk-api-modules-because-of patch, you lose voice recognition which I assume is not that big of a loss as I haven't encountered a use for it, so I think it is an acceptable alternative.

patlefort commented on 2022-09-22 00:33 (UTC)

Compilation will fail if you happen to have jwasm installed, due to vulkan loader. Workaround: uninstall jwasm or add this line to prepape() in the PKGBUILD:

sed -i 's/VULKAN_LOADER_CMAKE_ARGS = -DUSE_MASM=OFF/VULKAN_LOADER_CMAKE_ARGS = -DUSE_MASM=OFF -DJWASM_FOUND=0/' "$srcdir/$pkgname/Makefile.in"

loathingkernel commented on 2020-11-21 10:28 (UTC) (edited on 2022-09-13 10:55 (UTC) by loathingkernel)

Notes about this package

  • If you encounter issues while using this package, please contact me here first before reporting an issue to the upstream repository.

  • Don't post logs, link to them. If you are using Manjaro, another derivative or an AUR helper, please mention it, I DO NOT TEST AGAINST THEM AND I CANNOT KNOW WHAT MIGHT BE WRONG WITH THE DISTRO/HELPER OF YOUR CHOICE.

  • It takes a LOT of time and space to build. Building with multiple jobs helps but might cause builds to fail in rare cases. Be sure to have at least 16GB of RAM if you are building on tmpfs

  • It is NOT built against Steam Linux Runtime (Sniper, Soldier, etc) and as such it doesn't require it. Still, is detected by Steam and works properly (preferable through steam-native).

  • This PKGBUILD uses CFLAGS, CXXFLAGS and LDFLAGS hardcoded in the PKGBUILD itself. By default it uses the same C[XX]FLAGS as upstream, namely -march=nocona and -mtune=core-avx2. To change them you will have to edit the PKGBUILD itself. Due to the nature of this package some flags can cause it to fail to build or not function properly. I try to filter them out but it is based on testing. If you have a feeling that compile-time options are involved in the issues you are having please include them in your comment. Currently the filtered options are -fstack-protector-{,-strong,-all}(dxvk and vkd3d only), -fno-plt, -z,relro, -z,now. Also the use of AVX instructions is disabled through -mno-avx.

  • If you are not using CFLAGS and CXXFLAGS specific to your system this package won't offer much in terms of performance as the upstream build flags already target the nocona (Core2) architecture. It will possibly perform worse than upstream. The only benefits you get is not depending on steam linux runtime as well as linking to Arch libraries. If you still want to build it, you can uncomment the relevant lines in the PKGBUILD to enable CFLAGS and CXXFLAGS similar to the upstream.

  • There have been reports with afdko failing to find its dependencies during building. I can't do anything about that as I don't maintain that package. It is NOT an issue with this package and I haven't found a way to not depend on it. Please don't report fails due to afdko (or any of its python- dependencies, they are pulled in due to afdko and only used by that), it has been discussed enough. There are possible workarounds in the comments.

  • It contains a patch to store game prefixes in the main Steam Library under $HOME/.local/share/Steam/steamapps/compatdata. It helps with isolation of game prefixes between users and works around issues with shared libraries on NTFS partitions due to drive symlinks. To enable it, set the PROTON_USER_COMPAT_DATA env variable to 1.

  • This package requires a Rust 32 bit target, please run rustup target install i686-unknown-linux-gnu BEFORE posting any issues if you're using rustup.

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 11 12 .. 34 Next › Last »

loathingkernel commented on 2023-08-27 16:46 (UTC) (edited on 2023-08-28 12:57 (UTC) by loathingkernel)

I'd prefer an even more civil tone in this conversation

Sure, I'd like that but then you should have refrained from passive aggressive comments such as the following.

You can thank me later when Arch upgrades

That being said,

I've just checked again, the EA app seems to exchange the default dxvk files with 6fce0949429d51640b079bbfbe94410d966148e5 dxvk (v1.10.1-1365-g6fce0949) upon installing Battlefield 1 for the first time.

Either show me the code where it happens or I still believe that you simply misunderstand what is going on.

The version you claim to be ancient, it is 1365 commits after 1.10.1, which if you look at it, quite possibly aligns close to version 2.2-164. YOU ARE MISSING THE GIT TAGS. And since you are missing it the version is calculated as an offset from the latest tag git can find. This is a problem on your end. This package when built in a clean chroot in my github actions has the proper tags in it, so it's not a problem with this package.

On an up-to-date repository at the time of writing, the current revision offset-ed from tag v1.10.1 is v1.10.1-1383-gbbd1d84c. Your ""ancient"" version is literally 18 commits old.

You can check yourself, clone the dxvk repository, and run git fetch --tags followed by git describe --long --tags --match=v1.10.1

Appearently, there is such a functionality or I wouldn't have bothered to report such a thing here.

The only way this would likely happen is through the bundled protonfixes and I can't find it anywhere. Feel free to check yourself. There is no "apparently" here, just your false assumptions and lack of understanding of the involved technologies.

ms178 commented on 2023-08-27 16:32 (UTC)

@loathingkernel

I'd prefer an even more civil tone in this conversation as yelling stupid into each other's faces does not bring anyone forward on a Sunday evening; thank you. I haven't demanded anything from you, I just wanted to share some knowledge (without being accused of spreading misinformation for a part that was intentionally formulated as a speculation initially, by the way).

Speaking of which, I've just checked again, the EA app seems to exchange the default dxvk files with 6fce0949429d51640b079bbfbe94410d966148e5 dxvk (v1.10.1-1365-g6fce0949) upon installing Battlefield 1 for the first time. Appearently, there is such a functionality or I wouldn't have bothered to report such a thing here.

I've learned something new today from your answers as well. Great, sharing knowledge makes us all wiser in the end.

loathingkernel commented on 2023-08-27 16:01 (UTC) (edited on 2023-08-27 16:36 (UTC) by loathingkernel)

I am going to try to be as kind as possible but I hope you realize you are just making a bunch of utterly insane assumptions.

so does Battlefield 1, the EA app or Steam silently exchange dxvk files in the background without telling users? This is the only explanation I can come up with that is in line with what I saw (and no, I wasn't making this up).

That explanation is completely false, they do not exchange versions, there is no such functionality anywhere. Why are you even using journalctl -b? Just enable the DXVK HUD with DXVK_HUD=version, the version is backed in the library.

it was using v1.10.1-1365-g6fce0949

No it is not ancient, it is 1365 commits after 1.10.1, which if you look at it, quite possibly aligns close to version 2.2-164. YOU ARE MISSING THE GIT TAGS. And since you are missing it the version is calculated from the offset from the latest tag. This is a problem on your end. This package when built in a clean chroot in my github actions has the proper tags in it, so it's not a problem with this package.

On an up-to-date repository, the current revision offset-ed from tag v1.10.1 is v1.10.1-1383-gbbd1d84c. Your ""ancient"" version is literally 18 commits old.

however I would have expected that their specific AUR-packages exchange the files that come bundled with proton.

Why? What good would it do to modify the versions of software that is bundled with proton? How reproducible would a failure be if it worked in the way you assume?

Which other purpose do these seperate packages serve otherwise? I can't see any

To be used with wine for users who manage their wine prefixes on their own.

their use case is simple: To not have to compile the whole proton-package again,

This is not simple, it is simplistic, to the border of stupid.

The rest is highly relevant for this package, just not yet for you. People that build newer toolchains and hit such bugs along the way might find it interesting nonetheless.

It is not at all relevant, this is the AUR, the basis of Arch stable is not only assumed but also a requirement. Not even testing is the target for AUR pkgbuilds. If you gonna change every little piece of core software you are not running Arch any more, you are running something that is of your own creation that started as Arch at some point. So yes, it is UTTERLY IRRELEVANT.

You can thank me later when Arch upgrades its mingw-toolchain eventually if they are still present then.

If the problems you mention ever occur I will look into them and try to solve them after understanding them, I won't just throw compilation flags at them hoping that something sticks.

ms178 commented on 2023-08-27 15:35 (UTC) (edited on 2023-08-27 16:17 (UTC) by ms178)

@loathingkernel

to 3) Well, I was surprised to see this as well, but "journalctl -b" doesn't lie, I am afraid. It told me it was using v1.10.1-1365-g6fce0949 with Battlefield 1; which is ancient. But I just double-checked the files in its original state from the unzipped proton-ge-custom archive and the default file version seems to be indeed from 2.2, just as you said. That is even more puzzling as I haven't messed manually with these files before, so does Battlefield 1, the EA app or Steam silently exchange dxvk files in the background without telling users? This is the only explanation I can come up with that is in line with what I saw (and no, I wasn't making this up).

To your second part, I know that the dxvk/vkd3d-files come bundled with proton, however I would have expected that their specific AUR-packages exchange the files that come bundled with proton. Which other purpose do these seperate packages serve otherwise? I can't see any, their use case is simple: To not have to compile the whole proton-package again, just exchanging parts of it with newer versions (and compile them with different flags or get newer builds of these componants that way). At least that's what I've always assumed.

The rest is highly relevant for this package, just not yet for you. People that build newer toolchains and hit such bugs along the way might find it interesting nonetheless. You can thank me later when Arch upgrades its mingw-toolchain eventually if they are still present then.

loathingkernel commented on 2023-08-26 23:31 (UTC) (edited on 2023-08-26 23:41 (UTC) by loathingkernel)

@ms178 please, don't post misinformation

3) the dxvk shipped by default in /usr/share/steam/compatibilitytools.d/proton-ge-custom/files/lib/wine/dxvk (and lib64) seems to be ancient but gets used regardless of more recent packages installed on the system

First, this is not true. It is the version proton-ge includes, and it is version 2.2-164 with the latest one being 2.2-182 or something close to that. 18 commits old is hardly ancient https://imgur.com/u3IY7o4.png. You either fucked up your submodules or you are missing tags.

Second, proton and proton-ge-custom use their own bundled versions of dxvk, they do not use some externally installed dxvk, period. I wonder why would you expect it to do that when it is supposed to be a complete solution. For all of your efforts, did you bother to read the proton script?

I won't reply to the rest as it is highly specific to you and utterly irrelevant to this package.

ms178 commented on 2023-08-26 22:56 (UTC)

A dozen compiles later, some other observations which others might find interesting: 1) mingw-w64-binutils 2.40 is the last known-working version currently without the missing vulkan library issue mentioned recently; 2) there seems to be a compiler bug with my custom flags in the dxvk component with mingw-GCC-13.2.1 that prevents DX11 and some DX9 games from launching (OpenGL, DX12 and Vulkan games seem to work though); 3) the dxvk shipped by default in /usr/share/steam/compatibilitytools.d/proton-ge-custom/files/lib/wine/dxvk (and lib64) seems to be ancient but gets used regardless of more recent packages installed on the system (you can monitor this via "journalctl -b"); 4) what works best is to exchange the files in these directories manually with the files from my separate and up-to-date dxvk-mingw / vkd3d-proton-mingw packages (the former compiled with the GCC 12 toolchain) and to keep mingw-GCC-13.2.1 with the aggressive flags for the proton-ge-custom package itself (as the GCC 12 toolchain has a slow compile problem and takes more than double the time to finish with my flags).

ms178 commented on 2023-08-25 10:06 (UTC) (edited on 2023-08-25 20:29 (UTC) by ms178)

@loathingkernel That's the default of the VKD3D_LDFLAGS in the Makefile.in as it only adds "static-libgcc" to the CROSSLDFLAGS; however, that fails. I've tried "-static -static-libgcc" but that failed, too. I am now trying several other combinations, e.g. removing "-static-libgcc" alltogether but don't have high hopes. [edit:] Indeed, only a downgrade of mingw-w64-binutils from 2.41 to the CachyOS default 2.38 solved this issue, even with the rest of the toolchain beeing mingw-11 and gcc 13.2.1.

loathingkernel commented on 2023-08-25 08:13 (UTC) (edited on 2023-08-25 08:13 (UTC) by loathingkernel)

@ms178, yes, remove the -static flag from vkd3d in the makefile. That flag isn't there in my builds due to this failure.

ms178 commented on 2023-08-24 22:26 (UTC)

@loathingkernel

I see this failure during the configure run of 32-bit vkd3d:

checking for -lvulkan... not found checking for -lvulkan-1... not found checking for -lMoltenVK... not found configure: error: libvulkan and libMoltenVK not found.

This is with a mingw-gcc13 toolchain of my own. vkd3d/lib32-vkd3d 1.8 is installed on the system, also the vulkan-headers-git and vulkan-icd-loader-git packages. However, this seems related to the -static / -static -static-libgcc discussion you brought up recently. The error occures with both options set in the Makefile.in though. Do you have any ideas how to solve this?

loathingkernel commented on 2023-08-24 14:49 (UTC) (edited on 2023-08-24 14:49 (UTC) by loathingkernel)

@Freso this seems to fail due to finding cuda installed in your system. I would suggest to either uninstall cuda, build the package and then install cuda again, or build the package in a clean chroot.

CUDA is not necessary for building this package and Kaldi doesn't seem to offer an option to disable it through CMake, or at least I am unable to find it.

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 11 12 .. 34 Next › Last »