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 .. 34 Next › Last »

corax2.05 commented on 2024-03-23 17:49 (UTC) (edited on 2024-03-23 17:50 (UTC) by corax2.05)

hm... I can't see what the problem is.

Building proton-ge-custom... ==> Making package: proton-ge-custom 2:GE.Proton9.2-1 (Sa 23 Mär 2024 18:45:55 CET) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... -> Cloning proton-ge-custom git repo... Cloning into bare repository '/var/tmp/proton-ge-custom/proton-ge-custom'... -> Downloading wine-gecko-2.47.4-x86.tar.xz... % Total % Received % Xferd Average Speed Time Time Time Current

CUT

99 39.0M 99 38.7M 0 0 5570k 0 0:00:07 0:00:07 --:--:-- 6003k 100 39.0M 100 39.0M 0 0 5576k 0 0:00:07 0:00:07 --:--:-- 6004k -> Found 0001-AUR-Pkgbuild-changes.patch -> Found 0002-AUR-Do-not-update-cargo-crates.patch -> Found 0003-AUR-Remove-kaldi-openfst-vosk-api-modules-because-of.patch -> Found 0004-AUR-Copy-DLL-dependencies-of-32bit-libvkd3d-dlls-int.patch -> Found 0005-AUR-Strip-binaries-early.patch -> Found 0006-AUR-Fix-hwnd-redefinition.patch ==> Validating source files with sha256sums... proton-ge-custom ... NOT FOUND wine-gecko-2.47.4-x86.tar.xz ... Passed wine-gecko-2.47.4-x86_64.tar.xz ... Passed wine-mono-9.0.0-x86.tar.xz ... Passed 0001-AUR-Pkgbuild-changes.patch ... Passed 0002-AUR-Do-not-update-cargo-crates.patch ... Passed 0003-AUR-Remove-kaldi-openfst-vosk-api-modules-because-of.patch ... Passed 0004-AUR-Copy-DLL-dependencies-of-32bit-libvkd3d-dlls-int.patch ... Passed 0005-AUR-Strip-binaries-early.patch ... Passed 0006-AUR-Fix-hwnd-redefinition.patch ... Passed ==> ERROR: One or more files did not pass the validity check! Failed to build proton-ge-custom

corax2.05 commented on 2024-03-23 13:53 (UTC)

ok many thanks I will look at this

loathingkernel commented on 2024-03-23 13:26 (UTC)

@corax2.05 it's on your end, works here

https://github.com/loathingKernel/PKGBUILDs/actions/runs/8402114215

corax2.05 commented on 2024-03-23 12:52 (UTC)

Build fails. It seems cloning the GE Proton git fails.

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.

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