This is an unofficial version of Proton rebased to more current wine version, including various patches to fix bugs and improve performance. It is also a testbed for work-in-progress implementations.
Do not report problems with this version upstream to Valve, report them here instead.
This distribution targets people with some technical skills to benefit from an optimized Proton built. It contains experimental patches and minor problems should be expected. Thus, it is expected that users are comfortable with analyzing and reporting bugs patiently. This project is a spare-time project. I am not able to fix all problems on my own and need your help and cooperation.
If you're not willing to accept one or another patch, and to participate in analyzing, fixing, and testing a problem, this project is not for you.
The goal of this project is primarily to fix selected games so we can run them with SteamPlay properly and with good performance. A secondary goal is to grow and improve some patches that could hopefully be upstreamed to proton or wine.
It also aims at providing more consistent performance in games. This means it doesn't try to squeeze out the last few fps possible but instead reduce lag and stutter, thus having a better overall average fps rate with more consistent frame times.
First, check this README (it may have been updated between version of my build) if you find anything about the particular issue you're experiencing. If it is not listed, check https://github.com/kakra/wine-proton/issues for known/solved problems (look for closed issues, too). You may comment on closed issues, I'll follow up on those.
If you didn't find anything, let's start with logging. I need the output
of cat /proc/cpuinfo
and the SteamPlay log file. Edit user_settings.py
in the Proton folder to include:
"WINEDEBUG": "fixme+all",
Now, run the game. It will create a log file, pick the latest, it has the steam game id of the game you've run in its name:
ls -lt $HOME/steam-*.log
Check the file for obvious problems, the origin cause may be listed somewhere in the middle of the file, don't just look at the end. The first serious problem shown is probably causing your problem.
You may leave the logging enabled as WINEDEBUG=fixme+all
has only a minor
performance overhead with my build currently.
Here's an example from https://github.com/kakra/wine-proton/issues/8:
The log file shows:
info: Game: PathOfExile_x64Steam.exe
info: DXVK: v0.95-25-g4f58c2b
warn: OpenVR: Failed to locate module
info: Required Vulkan extension VK_KHR_get_physical_device_properties2 not supported
info: Required Vulkan extension VK_KHR_surface not supported
info: Required Vulkan extension VK_KHR_win32_surface not supported
DxvkInstance: Failed to create instance
err: DxvkInstance: Failed to create instance
Wine crashes with a read fault later due to this:
Unhandled exception: page fault on read access to 0x0002fc50 in 64-bit code (0x0000000140614095).
[...]
System information:
Wine build: wine-4.0-rc7
Platform: x86_64
Version: Windows 7
Host system: Linux
Host version: 4.20.3-arch1-1-ARCH
So the origin cause is the DXVK error. Essentially it says that Vulkan is not
fully supported. The solution was to install the required support drivers
for AMD Readeon
.
If you still need help or think your findings are worth a troubleshooting example here, feel free to open an issue report.
The patches are regularly rebased onto wine/proton updates. Thus, the main branch is not suitable for git-merge workflows.
Tagged releases are available to checkout specific repository versions. Patches should be sent based on either vanilla wine, wine-proton or this repository branch. Monolithic patches are not acceptable (you would find those most commonly in Lutris or similar distributions). The atomic-commit approach allows you to filter out any SteamPlay-related patches easily through an interactive rebase. That way you could craft a version that runs outside of Steam.
Patch series introducing too many rebase conflicts will most likely be dropped from this repository, i.e. it used to have the D3D11 deferred context patches and the PBA patches. But wine master seems to work in this area a lot currently, and thus these patches were dropped. Dropped patches are unlikely to return into this repository if they don't or cannot provide a benefit, i.e. DXVK as a winelib renders D3D11 deferred context patches and PBA patches mostly useless. I later tweaked the winelib build to properly work with Proton wined3d/dxvk selection but I currently have no plans in putting the other patches back in.
This repository includes DXVK. This can be a major problem for 32-bit users because DXVK uses more memory than the native wine implementation of DX10/DX11. You will most probably run out of address space early. Games won't run well in 32-bit mode. It is thus recommended to use 64-bit games only. However, turning DXVK off the Proton-way works now.
Pulseaudio users can somewhat improve the situation by limiting the SHM size
of pulseaudio to 1 MB. Simply add shm-size-bytes=1048576
in
/etc/pulseaudio/daemon.conf
and restart. This version is also compiled
without debug support to reduce the memory footprint.
With transparent hugepages it could make more sense to use bigger shared
memory sizes to align nicely with hugepages: shm-size-bytes=2097152
. But
I'm not sure if this could provide any benefit.
While testing, I found that DXVK can interact badly with the transparent
huge pages of the kernel. While overall performance seems a little bit
smoother, it fails early to allocate more DirectX memory even before you've
run out of VRAM. In my tests, this situation can be mostly avoided by running
a kernel with CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y
instead of
CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y
. This still results in a little less
smooth experience while keeping the benefits of huge pages for applications
that actively ask for it. So far, DXVK crashes due to memory allocation are
gone for me with this setting. If your kernel doesn't set either of these
options, you're probably safe.
Hint: To properly support my large pages patch, you need to enable
CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y
.
If you want to experiment with this, I can recommend starting with the following settings:
#!/bin/sh
# /etc/local.d/transparent_hugepages.start
echo within_size >/sys/kernel/mm/transparent_hugepage/shmem_enabled
echo always >/sys/kernel/mm/transparent_hugepage/enabled
echo defer+madvise >/sys/kernel/mm/transparent_hugepage/defrag
echo 128 >/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_none
This would enable a sane feature set with the potential of exposing the memory allocation issue observed above.
Games tend to allocate and free vast amounts of memory especially during loading screens. This puts the memory manager of Linux under a lot of pressure. When this becomes a problem, you may see multi-second stalls and the system freezes for short periods of time (coming back to life with HDD activity). Audio usually also stops for the duration of the freeze. What you're seeing is probably an effect called "allocstall" in Linux.
You can watch the numbers here:
grep allocstall /proc/vmstat
I found that there's great potential of removing this effect by adjusting kernel parameters but YMMV depending on your system. This effect is most visible to me in SOTTR and PoE. To improve this issue, create the following file:
# /etc/sysctl.d/99-gaming.conf
vm.vfs_cache_pressure = 50
vm.watermark_scale_factor = 200
The first parameter (default 100) will instruct the kernel to prefer keeping cache memory around and instead swap out process memory you currently don't need during gaming (idle background applications).
The second parameter (default 10) will instruct the kernel to wake kswapd more early and more often to keep a minimum amount of free memory for latency-free allocations. This is the most prominent parameter to reduce allocation stalls. As far as I could research, the scale of this parameter has changed at some kernel version, it's now a factor of 0.1%. If you're running an old kernel, a value of "200" may be a bad idea. Kernel 4.9 or later should be safe, this is around the time when I started testing this.
You can activate the settings immediatly by running
sysctl -p /etc/sysctl.d/99-gaming.conf
or you just reboot. If you want to test the settings first, don't put the file
into /etc/sysctl.d
just yet.
Be careful to not adjust the parameters too far away from the defaults or too extreme as this may have very negative effects (it could OOM-kill your whole session, leaving you unable to login even after reboot).
Users of btrfs benefit especially from this as btrfs is quite a heavy user of memory allocations. If you don't think you're experiencing allocation stalls, I recommend to not fiddle with these settings. If you're low on memory, I recommend to adjust these settings only very carefully (8 GB or less of RAM).
As a result, you should see the kernel keeping more unused memory around (so neither cached nor used). This memory is then available to latency free allocations. Having reduced latency for memory allocations comes at the cost of loosing some otherwise available memory: It's not really lost because it's available when needed but the kernel takes care of freeing some other memory instead early then in the background - so it's kind of a buffer for memory allocations that doesn't involve swapping or compacting (which introduces latency spikes otherwise).
To return to defaults, just remove the file and reboot.
This is a summary of the current patch series status of patches applied to vanilla wine:
This is a summary of the patches in the subprojects. The objective here is to keep the amount of patches small, if possible they should be upstreamed instead:
The following patches have been upstreamed so everyone running Proton can benefit from it:
SCHED_BATCH
scheduling and low priority to the state cache shader compiler, reduces audio stutter in loading screens and increases throughput of the compiler (DXVK 0.93, needs wine patches included here)The following patches have been dropped because either an issue has been fixed upstream, or the patch conflicted and wasn't important:
A work-in-progress list of applied patches is kept in docs/patches
in YAML
format. The current design is a manually crafted inverse dependency list. In
the future it should generate this tree automatically from staging definition
files. The leafs of this tree are the patche series applied to this
repository.
Running tools/mkpatchlist.rb
will generate a list of files suitable to be
fed to git am
.
You need to point the tool to the staging patches repository by creating a symlink to its patches directory, e.g.:
echo "/patches" >>.git/info/exclude
ln -s ../wine-staging/patches
Now run tools/mkpatchlist.rb
to compile a list of patch files for git am
.
In the future this tool will be part of a toolchain to recreate this wine
branch from scratch on top of a vanilla wine branch. Also in the future, it
will list the Proton patches as individual patch series to make crafting an
individual wine version more easy. I'll then push a wine patches repository
forked from the staging patches repository.
There are a few patches and features I'd appreciate one or another helping hand for:
This version of wine-proton includes a reworked realtime priorities patchset
based on staging. It enables setting thread priorities by default and can use
SCHED_ISO
to support multimedia realtime workloads better. But to take full
advantage of high priorities, you need to adjust pam limits and rtkit. Given
that your login user is member of the users
group:
# /etc/security/limits.d/99-wine-proton.conf
@users - rtprio 90
@users - nice -15
Depending on your distribution, you may also need to install and configure rtkit or RealtimeKit. How to do this in your distribution is out of the scope of this project. Google is your friend.
Changes to these configuration files require a restart of your login session.
Games may also benefit running a SCHED_ISO
-enabled kernel. Distributions
usually ship an alternative kernel you'd need to install that has the CK or
PF patchset. Both variants offer the SCHED_ISO
feature (through the MuQSS
or PDS-MQ schedulers). How to install and switch the kernel is also not the
scope of this project. Your favorite distribution should have a wiki
explaining that in more detail than this project could ever do.
There's also Feral GameMode which can temporary switch your CPU from a powersave mode to performance mode. DXVK recommends to do exactly that. To use GameMode, you have to install the daemon, then add the relevant library preload instruction to the Steam launcher commandline in the options of the specific game. I'm currently planning to integrate support for GameMode natively into wine-proton so all games can benefit once you installed GameMode.
This repository was developed while actively playing and testing the following games and journalling my development progress.
My system is a medium-aged system with the following properties:
My game progress: Late into Act 2, no crashes observed yet
The game runs exceptionally well even with higher graphics settings. I've added a patch to make ntdll.dll support large page mode (which translates to transparent huge pages in Linux). This setting can be enabled in the game options and theoretically improves performance. Memory throughput of huge pages can be up to 10% better.
But a deeper look at system metrics and wine logs shows that the game currently doesn't seem to do the correct VirtualAlloc() call, probably it was removed due to a bug in Windows 10 handling this properly (memory corruption due to delayed memory zeroing). It would also explain why Steam forums often report absolutely no difference between both settings in the game. OTOH, my patch may just be incomplete: Help very much appreciated.
If the game uses scaled-down render resolution, find render.cfg
and edit
the following lines to show your desired resolution:
"ScreenHeight16by9" "1080.000000"
"ScreenWidth16by9" "1920.000000"
After this change, do not open the graphics settings menu again, or your change will be overwritten.
My game progess: 100% completion, rare crashes or freezes
The game generally runs at only half the speed it could achieve, CPU and GPU are only used 50% at maximum. This is probably a CPU/GPU-sync problem. You probably need to reduce the graphics settings a lot if that happens. Also switch to SMAA if you experience the black pixels bleeding bug. There are reports that setting texture quality too high may result in slowly decreasing performance over time during gameplay.
See also: Notes about "allocstalls" above.
My game progress: Complete walk-through including almost all side quests, very rare crashes/freezes observed
My installation uses the unofficial game-developer mod and HD texture patch. The HD Reworked Project includes configuration updates to provide better performing texture streaming: https://www.nexusmods.com/witcher3/mods/1021?tab=files
My game progress: Somehwere mid-game, multiplayer has been tested and worked, no crashes or performance issues yet
I'm running this game in Vulkan mode. Game startup after switching the graphics engine takes a huge amount of time, be patient. The game runs at a hard 60 fps limit (due to vsync) with CPU/GPU usage around 25%.
My game progress: Somewhere around 85%, no glitches or crashes yet
Initial loading screen may take a very long time with a very slow animation of Ori. Be patient, it will eventually continue after 2-3 minutes. Subsequent runs do not show this problem. In-game feature videos make the game crash here which probably results from an improperly compiled steam runtime (tries to load a non-existing video decoder driver).
My game progress: Complete story walk-through, rare crashes/freezes observed
The game may freeze in a busy-loop during some scripted scenes, the exact problem is yet unknown. Try to progress with vanilla wine if that happens. There's no other chance around that currently.
My game progress: Beginning of Act 9, no crashes observed but one or another graphic/audio glitch, including bad performance/lags (which occur only once per new effect/map/enemy model)
I'm running the game windowed maximized in 4k resolution with around 40 fps on a GTX 1050 Ti. The game needs a warm-up phase before it runs smoothly. Subsequent runs benefit from the pipeline state cache of DXVK, greatly reducing or even eliminating lags during gameplay. If you experience login problems wait for the harddisk to calm down before logging in. Resizing the game window or switching resolution most likely results in a crash. In that case edit the config file in an editor.
There seem to be audio glitches since inclusion of FAudio which results in improperly placed sound sources and/or audio sources disappearing from playback altogether, eventually resulting in a muted game at some point. A restart of the game is required then. Crashes were not observed due to this.
See also: Notes about "allocstalls" above.
My game progress: Somewhere late in the game, only minor audio issues observed (which may be a bit annoying given a nature of this game) and one or two crashes/freezes, nothing game breaking tho
My game progress: I'm not sure, this game is huge. I used to play the original Skyrim 2011 and eventually completed all the DLCs with most side quests and this one is just a different walk-through. The game tends to freeze once in a while which is probably related to DXVK memory allocations.
My installation uses a hand full (or two) of immersion and graphic mods. The Creation Engine tends to partly freeze if subsystems do not work correctly (either in scripted scenes or during loading screens). This problem still exists even with the inclusion of FAudio. Thus, a registry patch is included which forces xaudio2_7 on the game. The scheduler improvements seem to get rid of most audio cracklings and stutters. Another problem may be DXVK memory allocations, in that case reduce the texture pressure by lowering settings.
My game progress: Some DLCs completed, first continent almost completed, probably somewhere around 50% of the game, no glitches or crashes yet
Currently, just unpack the dist.tar.xz into your existing Proton folder.
This version includes DXVK as a winelib but modified to properly work with
the Proton-way of disabling user_settings.py
. This is done by renaming
the .dll.so
files to just .dll
and moving them to the expected location.
Wine seems to have no objections in loading ELF binaries as native DLLs. You
don't have to take care of this, it's built this way out-of-the-box.
To make full use of the scheduler improvements, I recommend running a kernel
with support for SCHED_ISO
. The CK kernel is one such example. You also
need to adjust your pam limits for NICE
and RTPRIO
. In contrast to the
staging patchset this distribution automatically enables and tunes for
available priorities after you adjusted the limits - no need to set
environment variables. The patches were not tested with a non-MuQSS kernel
(those without SCHED_ISO
support), especially session-based task
auto-grouping may have an impact on performance behavior.
The first time you want to use this repository, you have to clone it and initialize the submodules:
git clone https://github.com/kakra/wine-proton.git
cd wine-proton
git submodule update --init
This should be easy... unless not. Let me know if you're having troubles.
This project uses a custom build system to build most dependencies from
scratch without chroot or cross-compile toolchains (except winegcc
). Start
by checking out the git source and submodules. Then run:
# Run some preparation scripts first
pushd vendor/vkd3d && ./autogen.sh && popd
# Configure the project (optional, missing makefiles will be built automatically)
make configure
# Option 1: Build a tarball with bundled DXVK (default)
make dxvk-dist.tar.xz
# Option 2: Build a tarball without bundled DXVK
make dist.tar.xz
# If something went wrong, start over:
make clean
You can use make -j$(nproc) ...
to speed up compilation. The dependencies
between subprojects should be safe.
Updates to build instructions (generated makefiles) are not tracked correctly
in most upstream build systems. Thus, if you change optimization flags, I
recommend doing make clean
followed by make configure
to rebuild from
scratch. Otherwise, you may experience strange issues.
For this project, I decided to use a rebase workflow because it fits me best
for following multiple upstreams: The main upstream will be followed using
rebase
, then I selectively cherry-pick
commits from other upstreams. I
can checkout git worktree of those other projects if I plan to pick bigger
chunks of commits into other branches: Just rebase onto an upstream commit,
copy multiple lines from the editor, then paste those into another rebase.
I usually follow such a workflow to follow up on staging patchsets.
Since the development workflow is based on a rebase pattern, you'd need to add the upstream wine project as a git remote if you intend to rebase parts of the commits:
git remote add winehq git://source.winehq.org/git/wine.git
To follow up on updates, just run the second line. It will pull updates from both my github project and wine upstream. This alone only fetches the commits without applying anything to the source code branch yet.
After updating the remotes, you can run an interactive rebase to do whatever you like to do with the commits, i.e. you could manually filter out all Steam API commits to remove the dependency to Steam:
git remote update
git rebase -i winehq/master
To follow up on updates from my repository, given you named it origin
,
instead use:
git remote update
git rebase origin/rebase/proton_3.16
git submodule update --init --rebase
If you do not need to float your own patches/commits around and did not make changes to the source files, you can simply reset instead:
git remote update
git reset --hard origin/rebase/proton_3.16
git submodule update --init --force
An editor opens: Put a hash sign #
in front of each commit you'd like to
omit. If something doesn't work during rebase and you're not sure how to
proceed, you can abort the rebase:
git rebase --abort
If you screwed up, just run
git reset --hard origin/rebase/proton_3.16
where origin
is my remote - replace with whatever you named it. The default
is origin
if you just cloned directly from my github project to your
computer. This is also a command that you could use to reset your clone to
my latest version but be aware that it will throw away any changes you made.
I keep my own patches floating at the top of the upstream commits so I can easily track them. Before resetting to an upstream branch, you may want to first backup your own branch so you can cherry-pick changes back into upstream:
git branch backup/some-backup-name
Be sure to have all your local changes committed to git before resetting,
because reset --hard
will also throw away uncommitted changes.
To make using this workflow a little better and comfortable, I can recommend
looking into the tig
tool and make yourself familiar with its usage. It's
a small CUI utility to browse git repositories, do cherry-picks, and resolve
conflicts (and probably a lot more).
Also, I recommend looking into git worktree
to create fast worktree copies
sharing the same commit database.
This repository is natively developed using Gentoo Linux. You'll need to install some basic dependencies to start using this:
# Be sure that you're running a multilib system, every desktop profile
# should do, e.g. default/linux/amd64/17.0/desktop:
eselect profile list
# Install the building and development environment:
USE="mp3 sdl opengl vulkan vkd3d" ABI_X86="32 64" emerge -DNua git '>=wine-vanilla-3.16'
You should add the needed useflags to your make.conf
. Because Gentoo is a
source-based distribution, all required headers and libraries are installed
now.
This repository is developed using Gentoo Linux. But due to the popularity of Arch Linux, I'll try listing the steps to get this started on Arch Linux. These steps have been tested in a fresh 64-bit Arch Linux nspawn container:
# Follow the instructions for enabling Arch Linux multilib at
# https://wiki.archlinux.org/index.php/official_repositories, then
# the following command should work:
pacman -Sl multilib
# Install all building essentials:
pacman -Syu base-devel meson
# Install development dependencies:
pacman -Syu glslang opencl-headers
# Install multilib and feature dependencies:
pacman -Syu krb5 libxslt
pacman -Syu lib32-krb5 lib32-libxslt
pacman -Syu gst-plugins-base mpg123 openal sdl2
pacman -Syu lib32-gst-plugins-base lib32-mpg123 lib32-openal lib32-sdl2
pacman -Syu vulkan-icd-loader libxcomposite libxinerama
pacman -Syu lib32-vulkan-icd-loader lib32-libxcomposite lib32-libxinerama
# Install dependencies from AUR:
# (HINT: You may need to set JAVA_HOME to jdk8)
pakku -Syu ffmpeg spirv-tools
pakku -Syu lib32-ffmpeg lib32-spirv-tools
# Install wine development toolchains to easily bootstrap the project:
pacman -Syu wine
HINT: You will need to get some package from AUR, this guide uses pakku to install the following packages:
I'm not familiar with the Arch ecosystem, feel free to suggest a better alternative.
This repository is developed using Gentoo Linux. But due to the popularity of Ubuntu, I'll try listing the steps to get this started on Ubuntu. These steps have been tested in a fresh 64-bit Ubuntu Cosmic nspawn container:
# Install all building essentials:
dpkg --add-architecture i386
apt-get update
apt-get install autoconf build-essential cmake gcc-multilib g++-multilib make meson pkg-config
# Install development dependencies:
apt-get install glslang-tools libavcodec-dev libsdl2-dev libvulkan-dev spirv-tools
apt-get install libavcodec-dev:i386 libvulkan-dev:i386 libsdl2-2.0-0:i386
# Install wine development toolchains to easily bootstrap the project:
apt-get install bison flex wine64-tools
apt-get install libfreetype6-dev xorg-dev
The current state is "not working" because libsdl2-dev is not compatible to a multilib development install in Ubuntu yet, read: You cannot install both architecture packages at the same time. But there's a somewhat hacky work-around:
cd /tmp
apt-get download libsdl2-dev:i386 spirv-tools:i386
dpkg -x libsdl2-dev_*_i386.deb .
dpkg -x spirv-tools_*_i386.deb .
cp -r usr/lib/i386-linux-gnu /usr/local/lib/
Current status:
make dist-faudio
make dist-vkd3d
make configure-wine64
make configure-wine32
make dist-dxvk
winevulkan
If you experience audio issues, try first reverting your pulseaudio changes
if you applied some. Things coming to mind are adjusted pulseaudio fragment
buffers and PULSEAUDIO_LATENCY_MSEC
.
Steam may randomly decide to replace parts of this distribution with its own version of wine. Just unpack the archive again if that happens.
The pre-built binary version was optimized for an i7-3770K. If your CPU is
incompatible with this instruction set, you'll have to compile your own
version. If you see errors about invalid instructions in dmesg
, then this
is what caused the crash.
This is not official Valve work. I take no responsibility for damages affecting your system, saved games, including game server bans due to using modified DLLs. Use at your own risk.