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.19
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 .. 10 11 12 13 14 15 16 17 18 19 20 .. 34 Next › Last »

ms178 commented on 2022-05-29 18:36 (UTC) (edited on 2022-05-29 18:38 (UTC) by ms178)

@loathingkernel, RubenKelevra

While I agree that march=native is not suitable for AUR without description on which architecture it was build on, in general such a march=CPU architecture package has some value for people on newer architectures. The benefits of such a CPU-architecture specific package would be even greater if the current limits on AVX and AVX2 in the PKGBUILD and patches were lifted. From my own testing today with the dxvk and vkd3d-proton MinGW packages, I found that these ISA restrictions are no longer needed there (yes, I checked and edited all entries in the patches and PKGBUILDs accordingly and checked the terminal output). I don't know if these restrictions are still needed for the proton-ge-custom package as I am still waiting for a fixed mingw-binutils to test that, but I would encourage people to try it themselves on the above mentioned packages and see if they see some performance gains (for anyone interested, see my customized dxvk-mingw and vkd3d-proton-mingw-git PKGBUILDS and patches at https://github.com/ms178/archpkgbuilds/tree/main/packages/).

loathingkernel commented on 2022-05-29 13:02 (UTC) (edited on 2022-05-29 16:25 (UTC) by loathingkernel)

@RubenKelevra Actually no, I am not ok with that. The reasons are purely technical. You can take a look to the comments of this and proton packages for various failures due to CFLAGS. I would prefer if people want to change it, they have looked through the PKGBUILD first. Also using native goes against the spirit of reproducibility in your previous comment as each package is going to be different depending on the machine it is going to be built on.

avoid having to modify the PKGBUILD on each and every machine and update.

The AUR is not a personal repository, and this looks like a change that would be useful only to you. This should be handled in some other private to you way and not in the AUR.

RubenKelevra commented on 2022-05-29 12:40 (UTC)

Thanks for the fast response @loathingkernel!

This makes sense and I'll look into the issue on the paru side. :)

Btw I created a tiny fork of this package with the -native suffix to avoid having to modify the PKGBUILD on each and every machine and update. Hope you're alright with that. :)

loathingkernel commented on 2022-05-28 18:31 (UTC) (edited on 2022-05-28 18:46 (UTC) by loathingkernel)

@RubenKelevra That is a paru or a configuration issue. The correct commits are defined in the way of git submodules and the PKGBUILD respects those. The PKGBUILD itself is absolutely predictable and reproducible unless upstream decided to force-push and overwrite a specific commit, which in either way it was handled, it would be problematic. The exact version depends on the containing repo's tag and it doesn't change for each specific version.

I don't know why paru wants to update a package when the PKGBUILD's version didn't change and it doesn't have a vcs suffix as if it was a vcs package, but that is not something the PKGBUILD should fix.

RubenKelevra commented on 2022-05-28 17:04 (UTC)

Paru seems to like to rebuild this package on every single commit on every single git that's linked.

I was wondering if you could freeze the other gits just to a tag/commit and also make the build more predictable/reproduceable?

Thanks!

patlefort commented on 2022-05-20 00:22 (UTC)

@loathingkernel Builds fine for me with your fix, thank you very much.

ms178 commented on 2022-05-19 23:59 (UTC)

@loathingkernel I spent some hours today but still couldn't get it to build, as I now face problems with dxvk-nvapi. But as I customized the files a bit, eg. changed the jobs to 4 in the RevertMe patch and use other buildflags, that might need more experimentation to what went wrong this time.

loathingkernel commented on 2022-05-19 08:22 (UTC)

@pattlefort @dmfay @ms178 I have made an unversioned update to this package that should fix the issue. The reason it is unversioned is because of an unrelated upstream issue wine takes a long time to build, and I didn't want to force an update to the people who have it working already. The gotcha is that it disables inline-asm for the x86 ffmpeg (while enabling lto and optimizations for ffmpeg similar to the rest of the libraries) so I don't know of the performance impact it might have.

loathingkernel commented on 2022-05-18 14:57 (UTC) (edited on 2022-05-18 22:11 (UTC) by loathingkernel)

@ms178 I am just beyond that point. I tried what the gentoo bugreport suggested but it still failed. I also tried changing optimization levels after but any of the permutations I tried didn't help either.

Edit: I have a fix I think, I will update tomorrow after I test.

« First ‹ Previous 1 .. 10 11 12 13 14 15 16 17 18 19 20 .. 34 Next › Last »