Arch Linux User Repository

@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.

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"

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.

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.

@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.

@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?

@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.

I find it a bit strange that you build this like proton-ge-custom-bin is built. What's the point of the package then? 30 minute build times are not worth it for some marginal space savings.

Anyway, I tried to build with -march=native (tigerlake) but my game (Rocket League) crashed. I then tried to bisect the archs until I found out that knm builds while skylake-avx512 doesn't. So it would make sense to have that as a baseline instead of nocona:

CFLAGS="$CFLAGS -mtune=knm -mno-avx2 -pipe" # -O3 -march=native -mtune=knm -mno-avx2 -pipe

I also found out that if you want to build with native (or at least tigerlake) you're going to need -mno-avx. So this would also be a sensible default:

CFLAGS="$CFLAGS -mno-avx -mno-avx2 -pipe" # -O3 -march=native -mno-avx -mno-avx2 -pipe

What do you think?

@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.

The kaldi32 target fails to build: nvcc reports "unknown option -m32". Package builds fine if I undo the commenting out of line 168 in the PKGBUILD:

    patch -p1 -i "$srcdir"/0003-AUR-Remove-kaldi-openfst-vosk-api-modules-because-of.patch

I haven't yet tried editing the patch to build only the 64-bit target. I can, however, build the AUR kaldi package. So it seems it's the 32-bit that's the problem.

@Xakurinha32 Kaldi's build system is using an outdated method of finding CUB headers. (There's a CMake warning before that error about it.) It should be inspecting the CUDA_PATH system variable and look in $CUDA_PATH/include, but effectively only looks in /usr/include. Because Arch's CUDA package puts its files in /opt/cuda Kaldi can't find cub/cub.h.

To work around this simply ln -st /usr/include $CUDA_PATH/include/cub.

Alternatively the PKGBUILD here could patch Kaldi's build system to pass -DCUB_INCLUDE_DIR=$CUDA_PATH/include to cmake...

@Xakurinha32 https://aur.archlinux.org/packages/proton-ge-custom?O=30#comment-930706

I got the following error:

CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
  Could NOT find CUB (missing: CUB_INCLUDE_DIR)
Call Stack (most recent call first):
  /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:600 (_FPHSA_FAILURE_MESSAGE)
  cmake/FindCUB.cmake:17 (find_package_handle_standard_args)
  CMakeLists.txt:200 (find_package)