You can remove the redundant line 85 from PKGBUILD.
makedepends=(${makedepends[@]} ${depends[@]})
All packages that are in depends are automatically in makedepends.
Search Criteria
Package Details: proton-ge-custom 2:GE.Proton9.1-1
Package Actions
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) |
Dependencies (115)
- attr (attr-gitAUR)
- cabextract
- desktop-file-utils (desktop-file-utils-gitAUR)
- fontconfig (fontconfig-gitAUR, fontconfig-ubuntuAUR)
- freetype2 (freetype2-gitAUR, freetype2-qdoledAUR, freetype2-macosAUR)
- gcc-libs (gccrs-libs-gitAUR, gcc-libs-gitAUR, gcc11-libsAUR)
- gettext (gettext-gitAUR)
- lib32-attr
- lib32-fontconfig
- lib32-freetype2 (lib32-freetype2-v35AUR)
- lib32-gcc-libs (lib32-gccrs-libs-gitAUR, lib32-gcc-libs-gitAUR)
- lib32-gettext
- lib32-libgudev
- lib32-libpcap
- lib32-libsoup
- lib32-libvpx
- lib32-libxcursor
- lib32-libxi
- lib32-libxkbcommon
- lib32-libxrandr
- Show 95 more dependencies...
Required by (6)
- cheat-engine-zh (optional)
- dxvk-gplasync-bin (requires proton) (optional)
- dxvk-gplasync-bin-git (requires proton) (optional)
- latencyflex-proton-ge-custom
- legendary (requires proton) (optional)
- rare (requires proton) (optional)
Sources (10)
- 0001-AUR-Pkgbuild-changes.patch
- 0002-AUR-Do-not-update-cargo-crates.patch
- 0003-AUR-Remove-kaldi-openfst-vosk-api-modules-because-of.patch
- 0004-AUR-Copy-DLL-dependencies-of-32bit-libvkd3d-dlls-int.patch
- 0005-AUR-Strip-binaries-early.patch
- 0006-AUR-Fix-hwnd-redefinition.patch
- https://dl.winehq.org/wine/wine-gecko/2.47.4/wine-gecko-2.47.4-x86.tar.xz
- https://dl.winehq.org/wine/wine-gecko/2.47.4/wine-gecko-2.47.4-x86_64.tar.xz
- https://github.com/madewokherd/wine-mono/releases/download/wine-mono-9.0.0/wine-mono-9.0.0-x86.tar.xz
- proton-ge-custom
brody commented on 2024-01-29 17:27 (UTC)
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 myhaswell
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.
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 throughsteam-native
).This PKGBUILD uses
CFLAGS
,CXXFLAGS
andLDFLAGS
hardcoded in the PKGBUILD itself. By default it uses the sameC[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
andCXXFLAGS
specific to your system this package won't offer much in terms of performance as the upstream build flags already target thenocona
(Core2) architecture. It will possibly perform worse than upstream. The only benefits you get is not depending onsteam linux runtime
as well as linking to Arch libraries. If you still want to build it, you can uncomment the relevant lines in thePKGBUILD
to enableCFLAGS
andCXXFLAGS
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 toafdko
(or any of itspython-
dependencies, they are pulled in due toafdko
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 thePROTON_USER_COMPAT_DATA
env variable to1
.This package requires a Rust 32 bit target, please run
rustup target install i686-unknown-linux-gnu
BEFORE posting any issues if you're usingrustup
.