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

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)

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

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.

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

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

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.

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

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

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.

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

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

(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:

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 :+1:

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

/* 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.

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.

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.

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

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),.

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

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

The best move is to use vanilla Arch.

yes tho that's all off topic now.

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

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

Fsync with No Man's Sky hangs.

steam-275850.log

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.

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

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

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

i wonder where is the problem? in wine or kernel?

i wonder where is the problem? in wine or kernel?

apparently is in the kernel, i have ubuntu 18.04, and kernel 5.0.0-23 and the games start to failing, only certani games but i dont know why the kernel but i think only for free sync of amd but i dont know in special in tecnical details

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

Yeah thanks for link, however I don't think there is much point moving off the -21 kernel if fsync kernel is confirmed crashing already.
I've had a huge headache last week with HDD failures and lost data and my internet and mobile breaking all at the same time, I really don't want to spend a week now debugging fsync...

Kernel crashes? I've not experienced anything like that, and I've used fsync with quite a few games

https://github.com/ValveSoftware/Proton/issues/2927

Could be related, I dunno

I don't believe that's related to fsync whatsoever

Anyways i tried to attach a proton log file and github does not seem to want to let me.
it complains about file size. I have one if a way can be found to upload it. Dark souls remastered
locks up it does not crash ok.

steam-570940.log
Here is a smaller log file. I hope it helps, because like i said before the game hangs it does not crash
and i have to switch to a virtual terminal and reboot.

[off topic]
@10ked head -c 10M steam-$ID.log > skimmed.log to reduce the log size.

Crysis (64-bit DX10 version). With Fsync enabled the splash screens are very,very,very slow to progress with choppy audio, I managed to get through about 4 splash screens and then it appeared to hang. This seems to be exactly the same with Esync.

Works fine with Fsync & Esync disabled.

steam-17300.log

System Specs

Thief Experienced 2 app hangs, when doing benchmarks comparisons between Fsync/Esync/Disabled. Both crashes were with Fsync enabled. I managed a few runs without crashes, so it doesn't happen every single time.

steam-239160-crash1-reduced.log
steam-239160-crash2-reduced.log

I can upload the full size logs if needed, as they were several hundred MB each.

System Specs

Rocket League on Proton crashes consistently for me about every other match.
Using PROTON_NO_FSYNC=1 fixes the issue.

skimmed.log

specs

I'd like to point out that if you have the linux-fsync kernel, you must disable fsync or esync for the game to work. Right now, if you don't disable one of them, your game will crash.

Definitely something Valve should take a look at, either disabling esync or fsync by default, as these two options don't get along together.

They work together with some games, I haven't encountered a problem with either of them yet.

They work together with some games, I haven't encountered a problem with either of them yet.

GTA V crashes with both enabled, and as reported above, so does Rocket League.

They work together with some games, I haven't encountered a problem with either of them yet.

GTA V crashes with both enabled, and as reported above, so does Rocket League.

I was playing GTA V with fsync on earlier, as I'm getting ready to do a benchmark comparison.. Didn't experience any crashes. I'm using the Rockstar Social Club version of the game. I didn't run the game for very long though.

Update: I have experienced 1 crash so far when benchmarking. I'm not sure about debug logging in wine yet, so haven't had chance to replicate.

Hi,

just tried Homefront the Revolution and it hangs during loading with fsync enabled (the loading circle is moving on and on..). Disabling Fsync fixes the issue. Strace -p shows the following:

strace -p 6925
strace: Process 6925 attached
futex(0x22cc80, 0x1f /* FUTEX_??? */, 1, NULL, NULL, 0^Cstrace: Process 6925 detached
<detached ...>

Many thanks !
Christian

I just realized, when playing Beat Saber with custom song mod, the custom songs aren't loading properly. It works from time to time, e.g. when waiting for a while, but mostly the songs aren't loading. PROTON_NO_FSYNC=1 as additional launch parameter gets rid of the problem.
Otherwise Beat Saber runs fine.

Game: No Man's Sky (version 2.0 BEYOND update)
https://www.nomanssky.com/beyond-update/

System Information

Distribution: Arch Linux x86_64
Kernel: Linux 5.2.8-arch1-1-fsync (from the Valve AUR)
GFX: GTX 970 - using nvidia-dkms 430.40-4 drivers

Proton Version: 4.11-2

Issue

With the new No Man's Sky beyond update (released today), the game fails to launch completely, instead, it gets stuck on Running with no game client visible. See below

A fresh compatdata has been made to test this, however, made no difference.

Workaround

PROTON_NO_FSYNC=1 %command% used in the launch options for the game allows the game to start without fail every time.

lsb-release package is also needed for Steam to launch on Arch with the fsync kernel.

Patched kernel 5.2 (with one additional needed patch cherry-picked from 5.3): https://github.com/kakra/linux/commits/rebase-5.2/steam-patches

Problem: "Middleearth: Shadow of War" freezes a lot during gameplay with fsync on, otherwise it runs fine for hours.

Distribution: Gentoo Linux
Kernel: Linux 5.2.8 with CK and Fsync patches, MuQSS enabled
GFX: NVIDIA Geforce GTX 1660 Ti AMP 6GB, drivers 418.52.18 and 435.17
Proton: 4.11-2

Tomb Raider 2013 has a performance regression, it is very visible when graphics settings are set to Low:
Fsync On (FPS Avg/Max/Min):
211,0/238,0/165,3
GPU usage reported by DXVK ~50%

Fsync Off (Avg/Max/Min):
295,8/346,6/223,6
GPU ~80%

Highest settings preset:
Fsync On (Avg/Max/Min):
84,6/116,8/64,3
GPU 100%

Fsync Off (Avg/Max/Min):
85,0/101,6/68,0
GPU 100%

Specs:
Radeon 580/Ryzen 1700/Ubuntu 19.04
kernel 5.2.8 + fsync patches
AMD RADV/ACO POLARIS10, DRM 3.32.0, 5.2.8, LLVM 8.0.0
Driver: 19.1.99
Vulkan: 1.1.107
DXVK v 1.3.2-4-g0b21ef18

Ryse Son of Rome hangs when loading a mission when fsync is in use. Disabling fsync solves the issue.

Get to the orange door (627610) crashes after 1mn with FSYNC on.
steam-627610.log

I confirm 4.11-3 removed the fsync freeze on Kingdom come: Deliverance and Get to the Orange door.

With Proton: 1566846741 proton-4.11-3

• Kingdom come: Deliverance: :heavy_check_mark: can load the game correctly
• No Man's Sky: :heavy_check_mark: can load the game correctly
• The Witcher 3: :heavy_check_mark: previously was hanging every 30 minutes or so for me with fsync enabled, today I played 4 hours without any problem.

So with Proton 4.11-3 I don't need the PROTON_NO_FSYNC=1 anymore :+1:

GRID ( appid 12750 ) doesn't boot with fsync. Despite client says it is running. PROTON_NO_FSYNC=1 makes it boot.

The Witcher 3 doesn't boot with WINEFSYNC_SPINCOUNT=100 but works normally without it. Played like 10 minutes.

It is not immediately apparent to me what values to try when it comes to WINEFSYNC_SPINCOUNT. I would assume the default value is 0 ref https://github.com/ValveSoftware/wine/commit/ecfa1989fe9bd940a7d8b0529eca0766b7aecb47#diff-f502c91784369393bb56dd1a9c2c929d

So, when "100" is recommended for "more performance", does that mean "200" is "even more performance"? Is "20" something to try if games does not start with "100" set, but you want more performance than not setting anything?

Having options is nice... Having too many options makes my head spin...

Well, when I read the commit note, I was reading it as "can/may improve performance", it's not a recommendation. Why would not make it the default otherwise? Also, "more" does not always make "more". You can also put some salt into your meal but putting twice as much doesn't make it taste twice as good.

I think that this can be tuned currently only means it is open for testing different values and post the results to get some statistical set of tested values. It may change into an on/off switch later when a good value has been found.

I've got game crashes with Guild wars 2 with fsync patched kernel and wine. Game generated logs here:
https://gist.github.com/Mel34/c7d79bdf5b04c3d379af7d0300adbb98
https://gist.github.com/Mel34/7fb4fcef503ef0805ae8e3a75b8b128e
FWIW I'm also using mesa-aco-git

Edit: as of proton 4.11.4 crashes are gone.
Performance wise it's equal to ESYNC

As of 4.11-5:

Witcher 3 does work with spincount variable now.

GRID ( appid 12750) boots now with fsync but hangs at main menu.

5.2.14-arch1-1-fsync (valveaur), i7-7700k, GTX-1080ti, Nvidia 435.24.02 (vulkan beta)
, Proton 4.11-5
"Sekiro: Shadows Die Twice" freezes frequently with fsync. What's weirder is that it does not appear to launch at all with PROTON_NO_FSYNC=1 while using the fsync-enabled kernel. When I switch back to 5.2.14.arch2-1, the game launches and runs fine.

I did some further testing and found that I could eliminate the freezing by experimenting with the WINEFSYNC_SPINCOUNT variable. I originally had tested with it set to 100. I tried again without that variable set and saw the same outcome (freezing). I increased it to 500 and made it a little further than normal, albeit with some stuttering. However, it still eventually froze. I increased it to 1000. This time, I could not get the game to freeze, but there was still occasional stuttering. I increased it to 2000 and now Sekiro seems to work perfectly.

Additionally, I had similar results with Grand Theft Auto V. That game wasn't freezing as often as Sekiro was, but I would still get freezing often enough to make it a pain to play the game. After bumping up the spin count to 500, I don't see any freezing anymore, although there is some minor stuttering. I did not test higher values with GTA V. Also, like Sekiro, GTA V does not launch with the PROTON_NO_FSYNC=1 option while using the fsync-enabled kernel.

Guild wars2 with WINEFSYNC_SPINCOUNT freeze the launcher.
The game works without WINEFSYNC_SPINCOUNT. the values i've tried are 1,100,1000,2000.
the game just freeze when the launcher is trying to check for updates.

It seems like the issue I have where games do not launch when I set PROTON_NO_FSYNC=1 is probably not related to fsync. The issue is not reproducible when launching games with proton from the command line. It is only reproducible when launching games from Steam.

Also, I attempted to reproduce the issue with Guild Wars 2, but was unsuccessful. I downloaded the installer from their website and launched it with proton from the command line. Once everything was installed, I started the launcher with WINEFSYNC_SPINCOUNT at 100 and 2000, but did not encounter any freezing in the launcher. However, my client is already up to date at the time of me trying this, so maybe it only impacts users when a new update is available.

Dark Souls 3 hangs/freeze with FSYNC (how to reproduce: load a save/start a new game)
I can hear audio but the game is frozed, PROTON_NO_FSYNC=1 fixes that.
Proton version: 4.11-6

system info:
https://gist.github.com/kassindornelles/039c4f8d1dd559563391513637803716

Risk of Rain 2 stutters massively (completely freezing the game for up to 10 seconds) when aiming the grenade skill of the character "MUL-T".

The freezes also happen with WineD3D, though it's harder to see since everything but the UI is black.

The bug goes away if either PROTON_NO_FSYNC=1 or WINEFSYNC_SPINCOUNT=100 are set.

System info :
Archlinux
Kernel 5.3.1-6.1-tkg-pds with fsync
i7-7700HQ
GTX1060 with driver 435.21

Crash N Sane Trilogy freezes on the first cutscene in Crash 3: Warped when fsync is enabled, the audio is still played but the video freezes and no buttons respond

The Evil Within 2 freezes with fsync. Setting WINEFSYNC_SPINCOUNT did not help. Only PROTON_NO_FSYNC=1

Proton: 4.11-7
kernel: 5.3.5
Distribution: ArchLinux
GPU: NVidia, driver 435.21

Bioshock Remastered freezes during the load screen when selecting new game unless fsync is disabled. I was able to get it working with very high WINEFSYNC_SPINCOUNT values, but the framerate was significantly lower compared to disabling fsync (although still higher than my monitor's refresh rate)

Darksiders 2 Deathinitive Edition ( 388410 ) hangs with fsync

steam-388410.log

GRID ( 12750 ) hangs with fsync

steam-12750.log

Earth Defense Force 5 ( 1007040 ) hangs on the mission loading screen with fsync enabled.

steam-1007040.log

Do issues that arrise when setting WINEFSYNC_SPINCOUNT belong here?

If so, The Outer Worlds fails to load when any value for that is set.

@kisak-valve i'm not running the game using Steam, i own the game only on Uplay but i would like to provide useful logs since the game is on Steam too.

If you run it using Proton you can still use the logging environment variable, though I'm not sure what filename it'll use.

I can't reproduce this as constantly, as when the game launches, there are other random issues with it, but I think it's worth noting. Using wine 4.15 + fsync patches and linux 5.3.7 + fsync patches, when starting Battlefield V, the game would freeze on the first loading screen often. When turning fsync off, this specific freeze goes away.

Please note, Battlefield V even without fsync often has other issues launching properly ( process just closing instantly, no game window appearing etc.)

Just in case, here's a log of a freeze. There's nothing there, sadly.

@FaithLV i don't have those issues with fsync enabled wine 4.17 and fsync enabled kernel 5.3. But as soon as i try to use bf v without wine virtual desktop, the things you mention happen. Game window showing up in a smaller res and then vanishing when trying to go fullscreen.

@pingubot Sounds similar. My issue might display differently due to using i3.

Disco Elysium with esync causes an fd exhaustion. ~Applying https://aur.archlinux.org/cgit/aur.git/tree/futex-wait-multiple-5.2.1.patch?h=linux-fsync on top of Fedora's kernel-5.3.8-200.fc30 fixes the issue~. The game runs quite poorly with PROTON_NO_ESYNC=1.

There is a regression though: The game no longer cleanly exits. The game cleanly exits with PROTON_NO_FSYNC=1
Edit: The game actually crashes with fsync after a short period. It lasts longer than with esync but not a lot.

Proton 4.11-7
fsync freezes Dark Souls III(374320) and Crash N Sane Trilogy(731490) solution - disable fsync
Proton 4.11-8, kernel 5.3.0-9.1-liquorix-amd64
The games don't freeze anymore

I just tested Bioshock Remastered again on 4.11.8 and I noticed a couple noteworthy differences compared to 4.11-7.

Now I can start a new game without the game completely freezing up. However, now attempting to save the game causes it to freeze. It is very possible that if I let it wait long enough the save game will still work. It's worth pointing out that many textures appear to be very low resolution. This is also true when using esync instead of fsync, but is not true when they are both disabled or when using very large WINEFSYNC_SPINCOUNT values (ie. 32768). With lower values like 20k, the high resolution textures load, but it takes them a second (ie. you see the low res textures first and then they are replaced with higher res textures). Furthermore, very high spin count values also enable me to save my game, although it does appear to hang for a few seconds every time. This is particularly noteworthy because this hang during save-game did not occur before (ie. using 4.11-7) with the same spincount value.

after about 1 minute of running aroud the area close to the "Ashina Castle" Sculptor Idol, the game hung with sound still playing

This might be #3387 ? The same dsound breakage / freeze can be caused by fsync instead of esync, I guess, since both speed up WaitForSingleObject.

Total War Three Kingdoms

Total War Three Kingdoms must run in PROTON_NO_FSYNC=1. Otherwise it will hang in game logo. But it is a native Linux game do not need proton. I don't know why that happend.

i just want to update my comment about Watch Dogs hanging with FSYNC
it is fixed now, game works fine with it enabled with no hangs at all.

Both issues don't happen without fsync/esync.

Company of Heroes 2 - SteamID 231430

The game launches fine, but when you for example start the campaign the game hangs/freezes after the loading screen after "Press any key to continue". Attached are 2 logs and the diff of both. One of the logs is a copy right before the freeze and the other one when it froze. (I killed the game exe after a few seconds) This also seems to happens with esync when looking at protonDB.
"WINEDEBUG": "+timestamp,+pid,+tid,+seh,+debugstr,+loaddll,+server,+fsync,+esync"
CoH2_fsync.zip

Battlefield 1942 - not on Steam

I used an old CD copy, because Origin doesn't seem to like me at all right now.
The main menu music disappears after a few seconds and button mouseover sounds loop for some reason. This also happens with esync.
WINEDEBUG=+fsync,+server
Battlefield 1942_+fsync,+server.log.zip

I can provide more logs with different debug channels if needed.

On Bioshock: Remastered there is a problem with textures and models that required the PROTON_NO_ESYNC to be enabled. In case of fsync compatible kernel, it has to be disabled so the game can load assets correctly:

PROTON_NO_ESYNC=1 PROTON_NO_FSYNC=1 %command%

I need both parameters for the game to run nicely

5.6.6-zen1-1-zen

@aeikum @Plagman off-topic question, do you plan to put fsync and fs{hack,bypass} to staging?

@soredake They're welcome to take it if they want it.

PES 2019 has sound stutter in loading screens with fsync enabled among other performance hiccups.
PROTON_NO_FSYNC=1 solves that reproducible.
Proton 5.0-7

Off Topic: Have there been any tests with the BMQ Scheduler for Valve's Kernel build? From personal experience it seems to be the best for gaming so far as it solves a lot of stutter issues for me.

@puxplaying That could be related to https://bugs.winehq.org/show_bug.cgi?id=30639 . The dsound mix thread is unable to process the different sound streams fast enough, so it's using 100% of one CPU core and holds the "buffer_list_lock" exclusively almost 100% of the time. There is only one short moment in every iteration where it releases the lock to synchronize with something else. That synchronization usually is pretty slow (through wineserver), so the game main thread gets some time to use the buffer_list_lock and add sound streams to dsound. Thanks to fsync, the synchronization is pretty damn fast, so the main thread only has a very short time to use the buffer_list_lock. When the main thread wants to add a bunch of sound streams (buffers) at the same time, there can be a few hundred ms delay for each one while waiting for the mix thread to release the buffer_list_lock again.

The "real fix" appears to be some speedup of the mix thread algorithm, as discussed in that issue at winehq.

Is fsync only available in Proton 4.11, or do the newer versions (like 5.0-8) also have this feature?

@Mushoz newer versions have Fsync like Proton 5.0-8

@nutta-git are you absolutely sure? The reason why I am asking, is that I do get this line when launching Dark Souls 3 on Proton 4.11-13:

Jun 07 10:43:50 Jaap-Desktop steam.desktop[26227]: fsync: up and running.

But when I switch to Proton 5.0-8 that line is absent from my logs. So either the logging was changed, or fsync isn't working under the Proton 5.0 series.

Later Proton versions may need an updated kernel patch because the syscall number changed.

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

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?

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.

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

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

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.

https://github.com/ValveSoftware/Proton/issues/492#issuecomment-671123250

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?

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.

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

The function was removed from the kernel https://github.com/torvalds/linux/commit/9180bd467f9abdb44afde650d07e3b9dd66d837c.

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

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.

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.

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. :-)

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.

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

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.

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

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

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.

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.

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.

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?

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.

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