fsync issues

[Plagman]

If you can reproduce a crash or performance regression with Proton 4.11 that consistently goes away with PROTON_NO_FSYNC=1, please post it here.

[ghost]

Sekiro doesn't load into game for me, but does with PROTON_NO_FSYNC=1.

[Whitetyphon]

I can add to what @z0z0z said, as Sekiro didn't work for me either.

The game worked fine in the main menu of the game and plays the opening cutscene, but after the cutscene when trying to load into the game, the game freezes. This was when starting a new game

When loading from a save file the progress bar gets to approx 3- to 5% completed and then freezes

PROTON_NO_FSYNC=1 makes the issue go away.

Should add that I used:

1. Manjaro Linux
2. Linux-fsync-5.2.1 as a arch repository pre-built package (Found in this repo pinned as a comment under the aur for fsync)

[Oschowa]

I also tested Sekiro, and while i can load into the game fine, after about 1 minute of running aroud the area close to the "Ashina Castle" Sculptor Idol, the game hung with sound still playing.
I ran strace -p $sekiro_pid and got the following output:
futex(0x22efd0, 0x1f /* FUTEX_??? */, 1, NULL, NULL, 0) = ?

Arch Linux
Kernel 5.2.5 fsync patched

[Vash63]

I'm still able to reproduce the issue where specific cutscenes (probably about 1/5 or 1/10) have dialogue that plays out of order in AC Odyssey with fsync enabled. I say 'still' as esync has this bug as well, so it's not a regression from esync, but it is a regression compared to having both esync and fsync disabled.

[ofarukaydin]

Guild wars 2 crashes after 1min.
steam-15106949398107521024.log
Arch linux

[Xinayder]

My 144Hz DisplayPort monitor is not being detected with the linux-fsync kernel package from AUR.

EDIT: here's my journalctl log file: https://gist.github.com/RockyTV/07f0f29f3c0a17a355b8929cafcb3a86

[Askannz]

Prey 2017 has a perf regression with Fsync enabled.

Without Fsync (PROTON_NO_FSYNC=1) :

With Fsync :

This is at 1080p with all settings to minimum, to ensure a CPU-bound scenario. GPU usage sits around 80%.

Specs :
i7-7700HQ, GTX 1060 6GB with driver 418.52.18, kernel 5.2.4 patched with Fsync and PDS scheduler.

[libcg]

GTA IV has problems with fsync. The game loads, when I walk to get outside the apartment it freezes and doesn't seem to recover. PROTON_NO_FSYNC=1 makes the problem go away even though I still see fsync: up and running. in the logs...

Specs:

• linux 5.3rc2 with fsync patch, mesa aco 5c6077221dd (same issue with LLVM)
• Ryzen 1700X, R9 Fury

[Bumbadawg]

@Plagman : just a big <3 thank you, Quake Champions went from 90fps to 160fps ingame, and 140fps in menu to 230fps; this is amazing!

[Plagman]

@Plagman : just a big <3 thank you, Quake Champions went from 90fps to 160fps ingame, and 140fps in menu to 230fps; this is amazing!

That's pretty impressive; do you know if it's just Proton 4.11 doing that, or fsync specifically? What does the perf look like when setting PROTON_NO_FSYNC=1 on 4.11?

[Plagman]

I've tested it on my end and it seems to be Proton 4.11, not fsync, yielding the perf improvements, which matches my initial expectations.

[jmbegley82]

Tried Metal Gear Solid V: The Phantom Pain (v1.50), using kernel 5.0.0-20-mfutex #21~18.04.1+1valve1+mfutex2-Ubuntu and Photon 4.11-1. The game hangs after a couple minutes and needs to be killed (although it does seem to perform better up until that point). Setting launch option PROTON_NO_FSYNC=1 restored the game performance to roughly what it was with Proton 4.2 and no longer hangs (at least after 30 minutes). Last line of strace during hang is "futex(0x22efe0, 0x1f /* FUTEX_??? */, 1, NULL, NULL, 0strace: Process 10877 detached" (although I may be using strace incorrectly) Using AMD FX-6300, Nvidia GTX 960, binary driver version 430.40, Ubuntu 18.04.2 LTS

[ghost]

PROTON_NO_FSYNC=1 fixes crashes in TEKKEN 7 that occur usually around stage load, before and after clearing out any cached shaders

[Bumbadawg]

(you may hide this as off-topic after reading)

I've tested it on my end and it seems to be Proton 4.11, not fsync, yielding the perf improvements, which matches my initial expectations.

@Plagman , indeed, this update bypassed my rational thinking and all safeguards skipped to hype the futex.
I also confirm the perf boost mostly came from 4.2 -> 4.11 as you mentionned and not fsync only.

Here are the perfs in Quake Champions main menu, maxed out, on 125% resolution:

fsync	linux 5	linux 4.15
ON	170	160
OFF	160	160

I didn't measure ingame accurately but i'd say the gain is about +5~20% with
Fsync ON when playing heavy scenegraphs (long distance / heavy draw calls).
It's now viable for an i5 4670k.
Before 4.11, i had to disable the esync patch because it caused so much input lag/stuttering.
Now it's smooth with that futex trick.

Again, a huge thanks for your contribution (and the team), pushing from Proton, the kernel propositions, and in general making gaming on Linux a robust and perennial alternative to closed-markets companies OS 👍

PS: the 4.11 update convinced me to buy Shadow of the Tomb Raider before Feral native release hehe.

[telans]

/* Off Topic */

I know this is an issue thread, but I thought I'd just give my results with Borderlands GOTY Enhanced (might upate later for other games).

I did crash once when leaving fsync enabled, however I am not sure if that was a one-off or even related to fsync at all.

Software	Version
Nvidia-vulkan	418.52.18
DXVK	1.3.1-git - doitsujin/dxvk@02d9221
Kernel	5.2.5-arch1-1-fsync

Game	fsync On / Off	FPS
Borderlands GOTY Enhanced	Off	122 fps
Borderlands GOTY Enhanced	On	130 fps

FPS recorded sitting at main menu, with maximum graphics options at 1080p, plus a custom Reshade config.

Question:
Perhaps fsync: up and running. could be displayed in the Steam Console too? Generating a 20-30 Mb log file every time I want to check if fsync is actually running isn't very handy.

[Ases]

Kingdom Come: Deliverance freezes at loading screen, but works OK with the PROTON_NO_FSYNC=1 env variable

The Proton log don't show anything suspicious to my eyes.

Software	Version
Distro	Ubuntu 18.04
Kernel	5.0.0-20-mfutex
Driver	NVIDIA 418.52.18
Proton	1564004442 proton-4.11-1b
DXVK	v1.3-3-g6f1b252f
SteamGameId	379430

EDIT: No longer freezes with Proton: 1566846741 proton-4.11-3

[jarrard]

fsync should only be a factor if you have a kernel supporting it. I tried building the arch fsync one but even tho it installed, it had a boot error so gave up on it (took 3hrs to build),.

[telans]

@jarrard You can add the valveaur repo & signing key, much quicker. You could post here what the error is anyways?

[jarrard]

Well I'm running manjaro and they have some custom configurations that cause running your own kernel a issue.
I'm actually going to switch to Pop_OS now and give that a go, there should be a ubuntu compat fsync kernel around somewhere. Arch was great and all but since antergos went bye bye I kinda lost interest a bit (yes I know someone resurrected the project under a new name but I don't want to go down that route again).

[mozo78]

The best move is to use vanilla Arch.

[jarrard]

yes tho that's all off topic now.

I'll try and get fsync for pop_OS and give it a test run sometime.

[Ases]

I'm actually going to switch to Pop_OS now and give that a go, there should be a ubuntu compat fsync kernel around somewhere.

@jarrard You can use the linux-mfutex-valve from valve-experimental ppa, that's what I'm using

[fls2018]

Fsync with No Man's Sky hangs.

steam-275850.log

[skeevy420]

Well I'm running manjaro and they have some custom configurations that cause running your own kernel a issue.

Without trying to stray further off-topic, Manjaro uses some modules from the AUR and if you're using any of those modules you just need to make sure you have those same AUR packages installed when using custom kernels.

Just posting that because I'm using Manjaro with an fsync enabled kernel provided by Tk-Glitch and that's the main thing I have to do to run custom kernels regardless of where they come from.

[jomarocas]

all games crash for me after make continue i put this command in user settings, any problems related with this functionality? for me this PROTON_NO_FSYNC=1 crash all assassin creed except the 2. games, like origin before continue, unity crash before continue, revelations this game freeze, 2 working good disable vsync in game, all the games are disable vsync

[telans]

PROTON_NO_FSYNC=1 Shouldn't be crashing any games that didn't crash beforehand. This might just be an artifact of upgrading from Proton 4.11 to Proton 4.2, rather than an issue caused by any fsync kernel patches. You could easily verify this by reverted back to Proton 4.2 and testing your games

[10ked]

Ok running slackware current with a patched kernel (linux-5.2.5) with fsync up and running Dark souls remastered locks up randomly and i have to switch to virtual terminal and reboot. With PROTON_NO_FSYNC=1 the game runs ok with no lock ups. Yes this is reproducible. Let me know
if you need more info

[Mushoz]

@kakra I am using the kernel from the AUR as instructed by Valve themselves: https://steamcommunity.com/app/221410/discussions/0/3158631000006906163/

Surely they wouldn't be recommending a kernel with an outdated fsync patch? Furthermore, if I look into the .patch file for fsync, I can see this:

Subject: [PATCH] Squashed futex-wait-multiple patchset onto stable release
 v5.2.1

Includes opcode 31 patch for testing with proton-4.11+

Which seems to imply it does have the new numbering for the opcode for newer proton releases. Unless this has changed yet again?

[SveSop]

Surely they wouldn't be recommending a kernel with an outdated fsync patch? Furthermore, if I look into the .patch file for fsync, I can see this:

I do not know if they use updated patches or not on AUR, but i built wine from the proton tree here: https://github.com/ValveSoftware/Proton currently @ 76dd491.
I also use a 5.7 kernel with fsync patches from here: https://github.com/sirlucjan/kernel-patches/tree/master/5.7/futex-patches-sep

Result:
fsync: up and running.

I noticed a post on the AUR that said:

lod commented on 2020-05-31 16:35

Is there a reason why the patch got never updated to v3?

Dunno if that is referring to the update to fsync patches in mention?

[kisak-valve]

Hello @SveSop, that kernel patch set doesn't look like it's intended to be used with Proton based on the opcode. I'm currently using https://gitlab.collabora.com/tonyk/linux/commits/futex-proton-v3 with a couple kernels from 5.4,5.6.

https://github.com/sirlucjan/kernel-patches/blob/master/5.7/futex-patches/0001-futex-patches.patch has a chance of working as well.

[SveSop]

https://github.com/sirlucjan/kernel-patches/blob/master/5.7/futex-patches/0001-futex-patches.patch has a chance of working as well.

The link i posted and the patch here is the same. The folder named -sep means "separated". The difference is just that the last one is a all-in-one patch.

[kisak-valve]

My eyes must have tricked me half a day ago. I thought I read opcode 13 instead of the expected opcode 31 which is used for pre-merge testing of futex wait multiple and Proton.

[M-Reimer]

Is actually still someone working on getting the fsync kernel patch upstreamed?

[Leopard1907]

Hi , i've noticed a couple of unwanted behaviours with Fsync on Yakuza 0.

Basically; if you have fsync on, you can't save game and game hangs when exiting from app. With esync only , both saving game works and you're able to quit from app properly.

Here are the logs:

steam-638970-esync-can save.log.tar.gz

steam-638970-fsync-cantsave-hangswhenquittingthegame.log.tar.gz

[Leopard1907]

Looks like fsync regressed with Proton 5.0.9 at least for Yakuza 0. 4.11-13 works fine and doesn't hang when closing the game.

#492 (comment)

[wwmm]

The patch futex-wait-multiple-5.2.1.patch does not apply to kernel 5.9. Does anyone know a working fsync patch for this kernel?

[SveSop]

The patch futex-wait-multiple-5.2.1.patch does not apply to kernel 5.9. Does anyone know a working fsync patch for this kernel?

https://github.com/sirlucjan/kernel-patches/tree/master/5.9/futex-patches-sep

Have not tested it tho.

[wwmm]

https://github.com/sirlucjan/kernel-patches/tree/master/5.9/futex-patches-sep

@SveSop it does not compile:

kernel/futex.c: In function ‘futex_wait_multiple_setup’:
kernel/futex.c:2734:5: error: implicit declaration of function ‘put_futex_key’; did you mean ‘get_futex_key’? [-Werror=implicit-function-declaration]
 2734 |     put_futex_key(&qs[i].key);
      |     ^~~~~~~~~~~~~
      |     get_futex_key

[wwmm]

The function was removed from the kernel torvalds/linux@9180bd4.

[SveSop]

Oh.. I see its currently removed from the git i posted.

Then i am out of ideas i'm afraid.

EDIT: https://github.com/Frogging-Family/linux-tkg/blob/master/linux59-tkg/linux59-tkg-patches/0007-v5.9-fsync.patch perhaps?

Dont have time testing a compile myself...

[wwmm]

EDIT: https://github.com/Frogging-Family/linux-tkg/blob/master/linux59-tkg/linux59-tkg-patches/0007-v5.9-fsync.patch perhaps?

Only now I saw your edit. That works. The downside is that it is not an updated fsync patch for the newer kernel. It is bringing back the function removed by the kernel developers so that the current fsync patch compiles.

[SveSop]

Ok. I did not check it out that deeply, but that makes sense.

The kernel fsync branch has not been updated since it was submitted, other than enthusiast rebases.. and like TKG does by fixing so it can be compiled. I don't know the kernel plan in the future for that, nor for Proton, since fsync relies on the eventfd-sync patches in staging.

Current wine newer than 5.10 does NOT enable esync, and as such, fscync does not work. I know TKG has done a lot of "hacking" by reverting and whatnot to get this to work on some newer wine versions, but it is still not "the right way" i guess.

https://github.com/wine-staging/wine-staging/blob/master/patches/eventfd_synchronization/definition#L9
Eventfd (and working fsync) was disabled 30 may.

[kakra]

esync should be totally separate from fsync: Both patchsets add hooks to mostly the same locations as far as I remember but use different primitives for synchronization. They do not depend on each other. But official Proton 5.13 contains both patchsets, so there's a new version of both patchsets available.

So what you really meant is not that fsync isn't available because esync isn't, but esync and fsync depend mostly on the same patching contexts, thus if one doesn't apply, the other probably neither will for the same reasons. What makes both patchsets depend on each other is that they share a lot of patch contexts, and fsync is usually applied after esync. But you can remove esync and keep fsync and quite easily fix the conflicts.

Also, your link is outdated - yay! That's good news. :-)

[Pillgar]

I've been trying fsync on Star Wars - The Old Republic with Proton v5.13-4 (even tried it in Lutris with their own wine versions), and though I do notice smoother game play (less stutters, better average FPS), the game does hang/freeze up when loading into a flash point (the actual loading screen gets about 3/4 completed and freezes) or cut scenes inside the flash points. This could be coincidence, but it only happens during a flash point with other online players. Solo stuff, it never happens.

I do feel the performance, with it enabled, is almost identical to Windows. I'm very impressed with this!!!!!

P.S. I noticed the logs are still saying fsync is up and running with PROTON_NO_FSYNC=1.

[mibli]

#4690 – in Endzone - A World Apart, PROTON_NO_FSYNC=1 seems to reduce or solve hangup issues.

[Riesi]

Checked Battlefield 1942 with Proton Experimental and the sound issue seems fixed.
Company of Heroes 2 (the 32bit legacy edition in the betas tab) is still not working with fsync.

Thanks.

[jarrard]

Kernels 5.13-4, 5.13-5 bugged fsync for some setups. Haven't have any issues with -6 so far.

[kakra]

Kernels 5.13-4, 5.13-5 bugged fsync for some setups. Haven't have any issues with -6 so far.

This kernel versioning is distribution specific, it's not identical to the upstream version. So you should at least also tell your distribution along with the kernel version. Except you actually mean 5.13.4, 5.13.5, ...

[jarrard]

Kernels 5.13-4, 5.13-5 bugged fsync for some setups. Haven't have any issues with -6 so far.

This kernel versioning is distribution specific, it's not identical to the upstream version. So you should at least also tell your distribution along with the kernel version. Except you actually mean 5.13.4, 5.13.5, ...

Yes I meant on ARCH, forgot to mention.

[nariox]

I want to report that LEGO City Undercover (#1961) crashes on cutscenes with FSYNC enabled. It works "fine" with ESYNC (and without).

I said "fine" because the game crashes often (even on Windows), but I can consistently cause the game to crash on cutscenes with FSYNC on.

[NTMan]

Finally, the kernel 5.16-rc0 reached me. And now I can test mainlined fsync patches. I see that all games started to produce 3-4 times less FPS. All games! Yes, the load on the CPU has decreased too, but I do not agree to pay such a price for it.

Type of API	Game screen with FPS	htop CPU load
esync
fsync

All measurements were made without rebooting by specifying the key PROTON_NO_FSYNC=1 %command% when starting the game.

Do you need more proofs or is that enough to start investigating the problem?

[thaewrapt]

Don't know if this issue is still valid for 6.3, but I've found this on Proton-GE-6.21 release notes and can confirm that games with at least a newer Ubisoft Connect launcher are affected and in my case the game (Flashback [245730] using the latest Ubisoft Connect depot recently added to selected Ubisoft games) was running okay only when PROTON_NO_FSYNC=1 %command% is used:

Fsync has been disabled on all Uplay titles -- it causes Uplay to hang on "Looking for patches" when initiationg a new prefix. Esync works fine.

[Yeshey]

I can add to what @z0z0z said, as Sekiro didn't work for me either.

The game worked fine in the main menu of the game and plays the opening cutscene, but after the cutscene when trying to load into the game, the game freezes. This was when starting a new game

When loading from a save file the progress bar gets to approx 3- to 5% completed and then freezes

PROTON_NO_FSYNC=1 makes the issue go away.

Should add that I used:

1. Manjaro Linux
2. Linux-fsync-5.2.1 as a arch repository pre-built package (Found in this repo pinned as a comment under the aur for fsync)

Adding the launch option PROTON_NO_FSYNC=1 %command% hasn't fixed the crash after the first cutcene.

System is nixOS testes with native steam and flatpak steam kernel 5.15.114