Package Details: proton-ge-custom 2:GE.Proton9.1-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: 37
Popularity: 0.57
First Submitted: 2020-03-23 23:52 (UTC)
Last Updated: 2024-03-10 08:14 (UTC)

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

1 2 3 4 5 6 .. 32 Next › Last »

brody commented on 2024-01-29 17:27 (UTC)

You can remove the redundant line 85 from PKGBUILD. makedepends=(${makedepends[@]} ${depends[@]}) All packages that are in depends are automatically in makedepends.

loathingkernel commented on 2023-11-24 15:41 (UTC) (edited on 2023-11-24 15:42 (UTC) by loathingkernel)

@xiota I see, and thank you so much for the explanation and your time. The shorter one looks pristine.

xiota commented on 2023-11-24 15:36 (UTC) (edited on 2023-11-24 15:38 (UTC) by xiota)

@loathingkernel The colon is a no-op that still expands arguments and performs redirects. So the ${x:=y} part is still processed, assigning to x only if it is unset or null.

Here's an alternate that's a little shorter:

: ${_system_cflags:=false}

# ...

if [[ x"${_system_cflags::1}" != "xt" ]] ; then
  unset CFLAGS
  unset CXXFLAGS
  unset RUSTFLAGS
  unset LDFLAGS
fi

: ${CFLAGS:="-O2 -march=nocona -mtune=core-avx2 -pipe"}
: ${CXXFLAGS:="-O2 -march=nocona -mtune=core-avx2 -pipe"}
: ${RUSTFLAGS:="-C opt-level=2 -C target-cpu=nocona"}
: ${LDFLAGS:="-Wl,-O1,--sort-common,--as-needed"}

export CFLAGS CXXFLAGS RUSTFLAGS LDFLAGS

loathingkernel commented on 2023-11-24 15:01 (UTC)

@xiota I selected nocona because it is Valve's default, and it is safely close to x86_64.

I am open to adding a switch, and thank you very much for providing an example. I have not seen the colon syntax before, I will look that up to understand it and I will probably add it verbatim.

xiota commented on 2023-11-24 14:40 (UTC) (edited on 2023-12-13 15:50 (UTC) by xiota)

@loathingkernel I'm curious, why nocona instead of x86_64? Also, what about adding a variable to control CFLAGS, etc? People who want to use their own flags set it to true at their own risk.

loathingkernel commented on 2023-11-02 08:48 (UTC) (edited on 2023-11-02 08:50 (UTC) by loathingkernel)

@Anuskuss6

I do think that x86_64_v3 would make sense though (that's what CachyOS chose as their baseline as well)

I know they are doing it, I have had my hand in some of their gaming packages and we have had long discussions with ptr1337 around optimizations. But CachyOS's whole selling point is using x86-64-v3 as their base optimization level. Any user wanting to use CachyOS knows that. Arch doesn't make such claims. Arch is still on x86_64.

The main takeaway is that I want my flags to be used. I think that's the thing I disagree with. Using either tune=knm or arch=native no-avx builds just fine and if it doesn't (in the future) we can come back to this.

I wouldn't say we disagree, you just don't see the bigger picture. You can look through the comments for this package as well as proton as well as the history of proton-native (the package has been deleted but the git repo is still in the AUR if you know how to access it) to verify for your self the reasons I settled on this way of doing things.

This package builds linux native software, wine and cross-compiles a number of windows dlls with MingW. Many flags that work on linux native compilations will break MingW cross-compilation or wine. You might be using some very basic CFLAGS in your makepkg.conf but neither of us can know what some other user is using. When I started packaging the various proton versions, I tried to filter known bad flags but it quickly became a huge chore. Instead of that mess, I elected to completely ignore them and if the user wanted to mess with them, they would have to modify the PKGBUILD. This is the least time-wasting option for both me and the regular user. You get a working package at the same level of optimization as Arch and I get less guess-work.

We should also report it in that case.

Feel free to do it and get your report closed post-haste. Neither upstream, Valve or GE, want their proton versions to be packaged in this way. I have been in many discussions around how "unsupported" or "debug burden" it is to package proton this way. They proclaim that proton is only supposed to be built using the Steam Runtime and that's where their involvement stops. They have the same stance with the flatpak versions of proton.

If you're instead talking about regressions ("proton-ge-custom-bin runs this game but proton-ge-custom doesn't") that's also easily fixed by just switching between the two.

As niobium93 said, they are not the same thing. This package doesn't use Steam's Runtime.

At least my understanding is (and Gentoo seems to agree with me) that you should build your packages with maximum performance in mind.

And I am giving you that option, I specifically patch the upstream makefile to honor CFLAGS coming from the build environment. That isn't there in the original makefile, just look at the patches of this package. And I exposes that option in the PKGBUILD with some documentation and warnings. All you have to do is edit the PKGBUILD, is it really that hard? I just want people that are going to edit the build process, to do so explicitly.

Yes, it crashes my game with tune=skylake-avx512 or higher.

Good to know, I will keep it in mind in case I encounter issues at some point.

Anuskuss6 commented on 2023-11-01 23:35 (UTC)

I cannot use knm as a tune directive as it will probably impact performance on older systems negatively (I personally use a haswell processor still)

tune=knm was just the last working architecture before my game crashed so I though it'd be a good default. I didn't really consider that people could still be using 10+ years CPUs in their desktop but here we are. I do think that x86_64_v3 would make sense though (that's what CachyOS chose as their baseline as well).

Using -O3 doesn't make much sense either at this point.

Hm, I don't think I made it clear enough. Everything after # is a comment, i.e. CLFLAGS="$CFLAGS -pipe" would result in CLFLAGS="-O3 -march=native -pipe" in my system. So if it does anything at all is irrelevant. The main takeaway is that I want my flags to be used.

This PKGBUILD will NEVER use the CFLAGS specified in makepkg.conf

I don't want to waste time on random build or runtime failures.

I think that's the thing I disagree with. Using either tune=knm or arch=native no-avx builds just fine and if it doesn't (in the future) we can come back to this. We should also report it in that case. If you're instead talking about regressions ("proton-ge-custom-bin runs this game but proton-ge-custom doesn't") that's also easily fixed by just switching between the two. I think you're being overly cautious here. At least my understanding is (and Gentoo seems to agree with me) that you should build your packages with maximum performance in mind. Every demanding program I built myself and for everything else, I just get the bin.

but from my experience x86_64 with avx runs fine on my haswell

I came to the same conclussion. AVX seems to work until tune=knm.

Are saying that you had issues with avx on x86_64?

Yes, it crashes my game with tune=skylake-avx512 or higher.

Anuskuss6 commented on 2023-11-01 22:51 (UTC)

@niobium93 Yes, the flags don't really do too much (in my testing it's less than 2% when CPU bound) but the real question is: why not? Why shouldn't the package offer some free performance compared to proton-ge-custom-bin? A user that's smart enough to use the AUR will be smart enough to switch between the two once a regression arises.

loathingkernel commented on 2023-11-01 08:35 (UTC) (edited on 2023-11-01 14:32 (UTC) by loathingkernel)

@Anuskuss6 I think that this is poorly thought out. I cannot use knm as a tune directive as it will probably impact performance on older systems negatively (I personally use a haswell processor still). Similarly I cannot use knm as an arch directive because this is going not make the package not run on older architectures.

I have considered using x86_64_v3 (roughly haswell) as arch instead of nocona as the baseline but I do not want to alienate users with older processors. core-avx2 is another name for haswell so the tune directive is already at the sensible baseline.

Using -O3 doesn't make much sense either at this point. The -O2 has the more interesting parts of what -O3 used to have such as tree vectorization. If any of these is really interesting or beneficial I would prefer to do it per-option instead of using -O3.

This PKGBUILD will NEVER use the CFLAGS specified in makepkg.conf, I do not plan on even considering it. I don't want to waste time on random build or runtime failures. The configuration is exposed in the PKGBUILD to be easily discovered and modified for this very reason if anyone wants to do so.

I am aware of the issues with avx but from my experience x86_64 with avx runs fine on my haswell optimized builds, that's why I only disable avx2 for it. avx is always disabled for x86. Are saying that you had issues with avx on x86_64?

niobium93 commented on 2023-11-01 07:16 (UTC)

@Anuskuss6 the point of this package is to build proton against native Arch Linux libraries instead of the Steam Runtime. Messing with the CFLAGS isn't magically going to make your games run faster. If build times are an issue for you, ChaoticAUR is a repository that automatically builds this and many other packages.