How is the performance for you? I'm getting ~30fps with everything in the lowest setting possible with an Nvidia GTX 770 and 396.54 drivers. Which makes the game unplayable (and comically ugly).

I tried KDE Neon Bionic with the 4.15 kernel and Solus KDE with the same performance problem.

I can confirm that the G27 works perfectly.

The problem with the invisible cars are mine. I set accidentally the number of shown to 1. I think that this game can go to the Whitelist.

@aboutafter I have more FPS in mid settings with a 1050Ti

What could be wrong with my rig then? because when I say lowest setting possible I also mean 1024x768 resolution and resolution scale at 70.

On Windows I got more than 144fps on low settings and 1080p and resolution scale at 100.

Try this

https://github.com/ValveSoftware/Proton/issues/156#issuecomment-419633955

I played a quickrace with 5 opponents in Mid settings at 1920x1080 and got an average of 35-40 FPS. Is not perfect but it stays fairly stable to play (for me). I see videos in Youtube of people saying that the game hasn't a great framerate in Windows. I think that this could be optimized in future during the Early Access

Pressing F8 gives me a lot more FPS (more than double). I can now play at 50-80FPS at 1080p.

Only daytime though. At night the framerate is horrible.

What does exactly F8 button?

I occasionally do not have audio from the engine, but brake squeal/aero noise is still present

What does exactly F8 button?

If you press F2 you can see the hotkeys. I think it says there that F8 makes a screenshot. Why does that cap and uncap the framerate, I have no idea.

I occasionally do not have audio from the engine, but brake squeal/aero noise is still present

Yes, I have the same problem too.

It runs well for me sometimes, but occasionally crashes while loading. Also getting the audio bug.

But in general it seems the game is still pretty buggy by itself, so might be just that.

It's an Early Access game, and it's possible this problems are problems that are present in windows also

System Information

• GPU: GTX 970
• Driver/LLVM version: NVIDIA 396.54
• Kernel version: 4.4.0-135-generic
• Link to full system information report as Gist
• Proton version: 3.7-6 Beta

I confirm:

• [x] that pressing the Play button in the Steam client is sufficient.
• [ ] that runtime config options
  are necessary to run the game.
• [x] that no workarounds other than the mentioned ones are necessary.

Issues

• [x] I haven't experienced any issues.
• [ ] There are no issues left open for this game.
• [ ] Although I consider the gaming experience equal to Windows there are
  remaining issues.

The game stills working great with Steam Play/Proton after the yesterday update (Release 2). You can see a video here:

https://youtu.be/W96AYqUzLq8

Mine stopped working. I only get a black screen at the beginning and I need to reboot the PC because it freezes.

What version of proton you use? I use 3.7.7Beta

3.7-8 Beta now.

Does it work with version 3.7.7?

This game suffers from the UE4 nvapi problem: https://github.com/ValveSoftware/Proton/issues/1374

After 0.3 update the game continues being playable. Important: Multiplayer online also works.
The starting video is not played as always
I'm using 3.16-4 beta with nvida 415.13 beta drivers.

In the last 0.3.5 hotfix ( https://www.assettocorsa.net/forum/index.php?threads/acc-release-0-3-discussion.52898/page-37#post-1011269 ):
"- Fixed possible server issue on linux emulators"

I'm not sure what this means, but we seem to be being taken a little bit into consideration.

It runs well for me sometimes, but occasionally crashes while loading. Also getting the audio bug.

But in general it seems the game is still pretty buggy by itself, so might be just that.

I have this errors yesterday, with 3.16-5Beta and 0.4 release of the game. I don't know if this problem is related to this versions.I see that in race loading screen, the record of the track is always the same (same time, same player), I hadn't noticed this before, but it's been going on since the game was released in Early Access. I don't know if is a Proton problem or Windows users have the same error.
Here is a video of 0.4 EA release with 3.16-5Beta;
https://youtu.be/VVyhJpLJ9NY

One more thing, after record the previous video I updated my GPU drivers and with 415.23 (with transform feedback) i feel a better performance of the game with my poor Nvidia GTX 1050Ti.

Hello again. Finally today I could try the game on Windows. First, like I say in previous posts, there is a video before menu. In multiplayer, the ping is much more lower than in Linux. In Linux you can see pings more higher than 300ms and in Windows, these are normal (lower than 100ms). I think some time ago these were much lower.

With the last release (6) the ping on multiplayer is much more low. In the race loading screen, i don't see the same record always. But the "Fatal error" mini-window message stills happening sometimes. As before, sometimes the music doesn't work, other times you hear everything except the sound of your own engine.
I'm using 3.16-7Beta

Trying the last version of Proton (3.16-8 Beta) the game don't seems to fix the problems described in this post, but I have this crash window when I try to capture the screen with OBS:
https://imgur.com/a/FZiTWiu

I don't know if the problem is related or has nothing to do with OBS

Initial assessment was that this game runs fairly well, but videos failing to play makes it not yet ready to be whitelisted.

This game can't be whitelisted because has some problems with sounds (https://github.com/ValveSoftware/Proton/issues/1420#issuecomment-421112109) and in certain moments shows a popup message and then closes (https://github.com/ValveSoftware/Proton/issues/1420#issuecomment-471203462)

Is not possible to upload a log (32MB only executing the game from start to menu, if you play only one minute, 140MB)

The game suffers the same problems with the last version of Proton (4.2)

Yesterday the game was launched officially, and now it has a lot of new content. The first thing I see is that now are a lot of stutter in game, but obviously is a game problem (there are a lot of windows users that reports this problem). You can see it on this video:
https://youtu.be/UZHq0QuC-K0
But, there is a (old and) big problem. Videos can't be watched, and when you starts a new career the screen goes to black and then is impossible to continue. I try to wait, to push buttons, mouse.... but nothing happens.
The game videos are in wmv format, and can be watched without problems with the system media player. Is there any way to play these videos in Wine? Would it be necessary to install a complement with Winetricks? This Windows user had the same problem, but it fixes it installing a windows update

I might have found the cause for the audio bug. It seems to be in the shader cache which is not properly cleared after exiting the game. The result is that the first launch of the game after install has working audio, thereafter the audio bug appears. In my case this audio bug was the absence of menu audio as well as engine audio.

This is fixed by deleting the shader cache manually before starting the game. It can be found in this directory: steam/steamapps/shadercache. Delete the file with the game appID, "805550".

I am looking into a solution for the video bug.

Thanks a lot! It's great to know a solution for this problem. Vídeo issue is a big problem because you can't start the career mode. I hope in a close future we can play this game like in Windows

The game has updated to 1.0.4 and now I can play career mode. If I press mouse button when the screen goes to black (video intro) it continues and is possible to play. But the stutter makes impossible sometimes to play normally. This stutter was not present before the oficial launch, in the Early access the game worked better for me.

Unfortunately the application consistently crashes when using SteamVR (tested on Ubuntu 19.10 with the Valve Index)

@aeikum Do you require any further information/logs?

System Information

• GPU: RTX 2060
• Driver/LLVM version: NVIDIA 440.82
• Kernel version: 5.3.0-46-generic
• Link to full system information report as Gist
• Proton version: 5.0-6 RC3
• SteamVR version: 1.11.7

I confirm:

• [x] that I have checked whether there are updates for my system available.

• steam-805550.ubuntu1910_steamvr.zip (SteamVR issue)

• steam-805550.ubuntu1910.zip (works as expected)

Reproduction

1. Select the title within your Library using the Steam client and press the Play button
2. Launch Assetto Corsa Competizione Steam VR mode

Hello @mimattr, as a side note, Proton logs compress well and you can drag and drop archives into your comment.

@leillo1975 Regarding the micro stuttering, I have seen as well that these started quite heavily with version 1.0. Though I recently discovered that enabling v-sync in the game mitigated the stuttering quite a bit for me.

Edit:Sorry, please forgot what I wrote above, choosing a different track and the stutter is as worse as it had been. No clue what is going on with this game. Even when my GPU (GTX 1080) isn't running 100% I'm seeing this spikes in frame time so I'm not sure if this stuttering is even GPU related. Could be constant shader compilation, but dunno if this would show like this very frequent micro stutters.

With Proton 4.11-2, when you try to save a wheel config, with assignments of axis and buttons the game crash.
I can't upload the log (52MB)
I uninstalled the game, and reinstalled it, and with the same proton version, when I try to make a new profile at the beginning of the game, when you choose the language, it crashed again.
If I back to 4.2-9, the game works again.

Hello @leillo1975, in general, Proton logs compress well in an archive, can you give that a try?

steam-805550.zip

@leillo1975 @kisak-valve The startup crash when creating a profile is a known regression in msctf. I read that the next Proton 4.11 version will contain the fix for it (https://github.com/ValveSoftware/Proton/issues/2978#issuecomment-521631126).
In the meantime you could use winetricks msctf as a work-around (please don't forget to set your prefix accordingly). It is possible that this causes the crash when saving a wheel config too.

@leillo1975 @kisak-valve The startup crash when creating a profile is a known regression in msctf. I read that the next Proton 4.11 version will contain the fix for it (#2978 (comment)).
In the meantime you could use winetricks msctf as a work-around (please don't forget to set your prefix accordingly). It is possible that this causes the crash when saving a wheel config too.

...and if trying to type in the in-game chat too

Fixed in the new Proton version (4.11-3)

With the msctf issue resolved I've investigated the remaining two issues with this game I had. Now it runs pretty much perfectly for me.

Video playback

Unreal Engine 4, which is used underneath, uses Windows Media Foundation for playing in-game movies. ACC wants to play MP4 (h264/acc) and WMV videos (wmv3/wmapro). Thus missing video playback is related to https://github.com/ValveSoftware/Proton/issues/1464

I got the playback working with these steps:

• Copy the following native files into the system32 folder of the ACC wine prefix: colorcnv.dll, mf.dll, mferror.dll, mfreadwrite.dll, msmpeg2adec.dll, msmpeg2vdec.dll, resampledmo.dll, sqmapi.dll, mfplat.dll, mfps.dll, mfplay.dll, wmvdecod.dll, wmadmod.dll
• Media Foundation needs registry settings, these should be installed using regedit into the ACC wine prefix.
• From above files the following needs to be registered using regsvr32 in the ACC wine prefix: mfplay.dll, mfps.dll, wmadmod.dll, wmvdecod.dll, msmpeg2vdec.dll, msmpeg2adec.dll, colorcnv.dll, resampledmo.dll
• Make sure that wine picks up the native versions of these file, e.g. by using environment variable: WINEDLLOVERRIDES=mf,mferror,mfreadwrite,msmpeg2adec,msmpeg2vdec,sqmapi,mfplat,mfps,mfplay,wmvdecod,wmadmod=n

These steps should be sufficient for successful playback of most videos. It is _not_ sufficient for the intro though. I figured that playback is fine (confirmed by UE4 logging), but video is hidden or invisible. It seems that the video size is the issue here. Once I resized the intro videos to "normal sizes" they showed up too. Thus:

• Resize the following videos in .steam/steam/steamapps/common/Assetto Corsa Competizione/AC2/Content/Movies (or similar) :UE4MovingLogo4K.mp4, Intro_Kunos_505.mp4, ACC_GameIntro_16-9.mp4 and TestIntro.mp4. I've used ffmpeg for doing so: ffmpeg -i <in>.mp4 -vf scale=1920:-1 <out>.mp4

Frame time spikes/stuttering

Currently a patch is needed on top of Proton to get rid of heavy frame time spikes, especially visible in online session. See https://github.com/ValveSoftware/Proton/issues/1420#issuecomment-639084670
Here is a custom Proton build that has this patch applied on Proton 5.0-8: https://www.dropbox.com/s/dz1kk9i22buz8fj/proton-5.0-8-acc-0001-ntdll-perform-fsync-in-client.tar.xz?dl=0

ACC is quite GPU and especially CPU intensive. The game has an in-game HUD. See https://www.assettocorsa.net/forum/index.php?threads/can-somebody-pls-explain-me.59540/. The O value (% occupancy for the physics calculations) might give an impression of the CPU usage. Similar like on Windows, lowering the number of opponents might help when your CPU can't keep up.
This posting should give some indication which GPU related settings should be used with care: https://www.assettocorsa.net/forum/index.php?threads/biggest-settings-impact-on-gpu.59535/ and, .

Happy racing!

The game updated to 1.0.8 and now , when you hit start, the screen goes to black and then crash to Desktop. I try to execute with Proton 4.2 and redownloading the game, but the problem persists.

Hello @leillo1975, please add PROTON_LOG=1 %command% to the game's launch options and drag and drop the generated $HOME/steam-$APPID.log into the comment box.

@leillo1975 @kisak-valve Same here, though this might be a game issue that affects Windows too, see https://www.assettocorsa.net/forum/index.php?threads/an-unreal-process-has-crashed-after-1-0-8-update.60152/

Hello @leillo1975, please add PROTON_LOG=1 %command% to the game's launch options and drag and drop the generated $HOME/steam-$APPID.log into the comment box.

steam-805550-.zip

After today's update (1.0.9), the game works again. I think that the game works a bit smoother than in previous versions.

I've slightly updated above instructions for version 1.1. The game now uses a wmv3/wmapro intro video which required some attention. Also stuttering seems much less with version 1.1.

With the msctf issue resolved I've investigated the remaining two issues with this game I had. Now it runs pretty much perfectly for me.

Video playback

Unreal Engine 4, which is used underneath, uses Windows Media Foundation for playing in-game movies. ACC wants to play MP4 (h264/acc) and WMV videos (wmv3/wmapro). Thus missing video playback is related to #1464

I got the playback working with these steps:

* Copy the following native files into the system32 folder of the ACC wine prefix: `colorcnv.dll`, `mf.dll`, `mferror.dll`, `mfreadwrite.dll`, `msmpeg2adec.dll`, `msmpeg2vdec.dll`, `resampledmo.dll`, `sqmapi.dll`, `mfplat.dll`, `mfps.dll`, `mfplay.dll`, `wmvdecod.dll`, `wmadmod.dll`

* Media Foundation needs registry settings, these should be installed using `regedit` into the ACC wine prefix.

* From above files the following needs to be registered using `regsvr32` in the ACC wine prefix: `mfplay.dll`, `mfps.dll`, `wmadmod.dll`, `wmvdecod.dll`, `msmpeg2vdec.dll`, `msmpeg2adec.dll`, `colorcnv.dll`, `resampledmo.dll`

* Make sure that wine picks up the native versions of these file, e.g. by using environment variable: `WINEDLLOVERRIDES=colorcnv,mf,mferror,mfreadwrite,msmpeg2adec,msmpeg2vdec,sqmapi,mfplat,mfps,mfplay,wmvdecod,wmadmod=n`

These steps should be sufficient for successful playback of most videos. It is _not_ sufficient for the intro though. I figured that playback is fine (confirmed by UE4 logging), but video is hidden or invisible. It seems that the video size is the issue here. Once I resized the intro videos to "normal sizes" they showed up too. Thus:

* Resize the following videos in `.steam/steam/steamapps/common/Assetto Corsa Competizione/AC2/Content/Movies` (or similar) :`UE4MovingLogo4K.mp4`, `ACC_GameIntro_16-9.mp4` and `TestIntro.mp4`. I've used ffmpeg for doing so: `ffmpeg -i <in>.mp4 -vf scale=1920:-1 <out>.mp4`

Frame time spikes/stuttering

ACC is quite GPU intensive when all settings are max'ed out. That said my impression is that the stuttering is caused by CPU limitations. Even with lowest graphics settings the game will max out a CPU core due to physics and AI (I guess). With version 1.1 the stuttering is nearly gone, if not, lowering the number of opponents might help.

The game has an in-game HUD. See https://www.assettocorsa.net/forum/index.php?threads/can-somebody-pls-explain-me.59540/. As long as the O value (% occupancy for the physics calculations) stays at zero everything should be fine.

Additionally I'm still capping fps to 50 and adjust the graphics settings so that GPU usage is mostly slightly below 100%. This posting should give some indication which GPU related settings should be used with care: https://www.assettocorsa.net/forum/index.php?threads/biggest-settings-impact-on-gpu.59535/

Happy racing!

I hope someone from Proton devs see your post and takes note from the video playback problem to include the solution in the Proton's next version

Hello @leillo1975, please note that there's ongoing work to bring up support for the Media Foundation framework in Wine. There isn't going to be a quick fix because it needs to be implemented from scratch and after that licensing issues with codecs need to be figured out.

There are some ways to workaround the issue, but requires having a 64 bit Windows 7 install to grab some files from because there isn't a legal redistributable installer for the framework available from Microsoft.

On a side note, opentrack master got support for ptroton, head tracking with it works now beautifully together with ACC.
https://github.com/opentrack/opentrack

Asseto Corsa: Competizione FFB overload on G920

Issue transferred from https://github.com/ValveSoftware/Proton/issues/3246.
@flukejones posted on 2019-11-22T10:36:00:

System Information

• GPU: RTX2060
• Driver/LLVM version: Nvidia 440.31
• Kernel version: 5.4.0-rc8-1.g97aef18-default (openSUSE Tumbleweed)
• System information report Gist:
• Proton version: 4.11-8

I confirm:

• [X] that I haven't found an existing compatibility report for this game.
• [X] that I have checked whether there are updates for my system available.

Symptoms

Force Feedback appears to work. But then the device FFB queue becomes overloaded, causing either irregular FFB or no FFB.

dmesg

[ 1627.828016] logitech-hidpp-device 0003:046D:C262.0014: Force feedback command queue contains 73140 commands, causing substantial delays!
[ 1627.842136] logitech-hidpp-device 0003:046D:C262.0014: Force feedback command queue contains 73160 commands, causing substantial delays!
[ 1627.843229] logitech-hidpp-device 0003:046D:C262.0014: Force feedback command queue contains 73160 commands, causing substantial delays!
<Trimmed by moderator>

The game otherwise seems to work well with good performance - except for movies not playing.

Reproduction

Play game.

Proton Log

steam-805550.zip

Further information to the above. While playing the game it seems to keep mostly on top of FFB and there seems to be a wide range of effects.

But as soon as the game is paused the FFB command queue grows in to the stratosphere and keeps going.

Additionally, once FFB is turned off in game the command queue starts to shrink. Installed Pop!_OS 19.10 and experienced the same.

Huh... So the queue stops being used once the game exits, which means it stops being emptied? Which means that in another driving game, it's using the built up queue of effects, draining the effects from Asseto Corsa.

I found that this game has a lot of stuttering, especially in multiplayer games, or when you ride against many cars. In certain moments the games shows a message on the top-left (CPU use > 99%), and the frametimes graph of the DXVK_HUD shows a lot of stutter. I recorded a video to show you this problem:
https://youtu.be/cEoahOxIWqc

As you can see in the "htop" window, the the CPU are not at 99% (perhaps 60%). There are a lot of CPU performance lost, and is probably that if the game use the entire CPU, this stutter would be much less. I think that this is not normal.

I made a Blender Benchmark and all the cores were set at 100% in "htop" without problems.

I played 2 multiplayer races on Windows in the same PC without any issues and CPU overload messages. I think that Proton can't use all the CPU in this game. The problem is the same with versions 5.0, 4.11 and 4.2

My CPU is a Intel i7-3770. You can see a GIST of my system here:
https://gist.github.com/leillo1975/db654fd0c71ce0baf57c1cca5bef3525

I know this kind of behavior, see https://github.com/doitsujin/dxvk/issues/1161 though in my case I really had a CPU core maxed out when the top-left message appeared.
Fortunately (at least for me) the games runs much much better here since recent updates. Pretty disappointing that it still runs so bad on your machine.
The game still maxes out a CPU core here, but apparently leaves enough room that the frame times spikes are rare on my machine. That said, I never found a switch or settings that eliminated the spikes for good. Sometimes I think it depends on which CPU core the game lands :)
I7-6850K and NVIDIA GTX 1080 here. Reading on the ACC Forums the game seem to depend heavily on the CPU, I guess this is even more important on Linux.

PS: You might try https://github.com/jp7677/dxvk-nvapi
This gives me 1 or max. 2 fps extra, may be you gain somewhat more.

I copy/paste my message on your @doitsujin dxvk issue, but I think that this problem is not related to DXVK

I copy/paste my message on your @doitsujin dxvk issue, but I think that this problem is not related to DXVK

I'm also convinced that this is not related to DXVK. According to the ACC forum there are also a lot of Windows users with frame time spikes: https://www.assettocorsa.net/forum/index.php?forums/acc-troubleshooting.72/

The strange thing is that the game reports a CPU usage > 99% and the OS only reports less than 60%. It's as if Proton doesn't use the full power of the CPU

The strange thing is that the game reports a CPU usage > 99% and the OS only reports less than 60%. It's as if Proton doesn't use the full power of the CPU

Yes, that is pretty weird. I just tested ACC and htop on my machine, here htop showed me a CPU core at nearly 100%. Are you sure that there was nothing else that stressed your machine, maybe IO instead of CPU?

Edit: Do you see the same behavior in single player races? I guess I should mention that I keep to single player races.

I copy/paste my message on your @doitsujin dxvk issue, but I think that this problem is not related to DXVK

I'm also convinced that this is not related to DXVK. According to the ACC forum there are also a lot of Windows users with frame time spikes: https://www.assettocorsa.net/forum/index.php?forums/acc-troubleshooting.72/

https://www.assettocorsa.net/forum/index.php?threads/large-intermittent-stutters-with-high-end-pc.62505/

Edit: Do you see the same behavior in single player races? I guess I should mention that I keep to single player races.

On single player races there are less stuttering, but when you add more cars this effect increases

Interesting. What is htop showing with less or more cars in single player
races for you?

On Sun, 9 Feb 2020 at 00:30, leillo1975 notifications@github.com wrote:

Edit: Do you see the same behavior in single player races? I guess I
should mention that I keep to single player races.

On single player races there are less stuttering, but when you add more
cars this effect increases

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/1420?email_source=notifications&email_token=AEDL5XORFBQNWIF5SO4BWYDRB457VA5CNFSM4FUYQ7U2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELF6GGY#issuecomment-583787291,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEDL5XIC2OAON34HVU67LH3RB457VANCNFSM4FUYQ7UQ
.

Edit: Do you see the same behavior in single player races? I guess I should mention that I keep to single player races.

On single player races there are less stuttering, but when you add more cars this effect increases

I've just tested a few multiplayer games. Stuttering is indeed worse there, though not always (seems to get better over time) and not as bad as in your recording. I've had running htop at the same time, similar with single player games I had a CPU core at nearly 100% all the time.

I make another test disabling HyperThreading on BIOS. Now I have only 4 cores working. As you can see in following the video, this cores are working at 75-80% and the game reports 99% . I think that Proton don't use all the CPU potential, at least in this game:
https://youtu.be/2CXBhQOsFig

Interesting. What is htop showing with less or more cars in single player races for you?

This video shows CPU use on Single Player race against 7 opponents. As you can see there are much less stuttering:
https://youtu.be/ZLRpOEp3h5s

Sorry for the driving in all these videos, I have the steering wheel at the side of the table so I can type comfortably with the keyboard reporting these tests

EDITED: Sorry, I posted the multiplayer w/o HT video. Now is corrected

I think it must be something related with the net layer in Wine/Proton. Something similar affects rFactor2, in single player, the game runs fine, with a lot of cars in the race. But when you try multiplayer races, the game is much more slow, not in graphics display, but in the race, is like go on slow motion, and the CPU use is also higher than in single player.

I think it must be something related with the net layer in Wine/Proton. Something similar affects rFactor2, in single player, the game runs fine, with a lot of cars in the race. But when you try multiplayer races, the game is much more slow, not in graphics display, but in the race, is like go on slow motion, and the CPU use is also higher than in single player.

This is the problem of rFactor2 ( https://github.com/ValveSoftware/Proton/issues/245 ) that @alexbrrsclnt reports:
https://youtu.be/cz1mE1QpcKE

FWIW, I've added a tweak to ffbtools in berarma/ffbtools#17 that fixes the force feedback problems people have been having with this game (at least on the G27/G920 wheels).

Today the game was updated to 1.4 version and now it don't works. Before the menu , it crash to desktop. Please take a look

Just gave it a go with 1.4 and latest proton, and it works nicely for me. Can you post a log?

Here it goes:
steam-805550.zip

```28416.743:00e4:00e8:trace:loaddll:load_so_dll Loaded L"C:\windows\system32\XAudio2_7.dll" at 0x7f3534140000: builtin
LogConsoleManager: Warning: Setting the console variable 'r.VSync' with 'SetByGameSetting' was ignored as it is lower priority than the previous 'SetByProjectSetting'. Value remains '0'
LogStreaming: Error: Couldn't find file for package /Script/SourceControl requested by async loading code. NameToLoad: /Script/SourceControl
LogStreaming: Error: Found 1 dependent packages...
LogStreaming: Error: /Game/GUI/Shared/WDG_InteractiveFooterButton
LogKsPhysics: Error: _ITERATOR_DEBUG_LEVEL is 0, no range checks
LogKsOnlineServices: Display: TcpClient trying to connect (stage 5)
LogKsOnlineServices: Warning: OnlineService's connection state 5 changed to 0
LogKsOnlineServices: Display: Connecting to 809a.assettocorsa.ne, 809b.assettocorsa.ne:809
LogKsPhysics: Error: TCP socket setTimeout error detected 10009

LogInit: Display: Game Engine Initialized.
LogInit: Display: Starting Game.
info: Presenter: Actual swap chain properties:
info: Format: VK_FORMAT_B8G8R8A8_UNORM
info: Present mode: VK_PRESENT_MODE_IMMEDIATE_KHR
info: Buffer size: 1920x1080
info: Image count: 2
info: Exclusive FS: 1
28448.814:00e4:00e8:fixme:dxgi:dxgi_output_GetDisplayModeList iface 0x3f1f2f0, format DXGI_FORMAT_R8G8B8A8_UNORM, flags 0, mode_count 0x5fd600, modes (nil) partial stub!
28448.814:00e4:00e8:fixme:dxgi:dxgi_output_GetDisplayModeList iface 0x3f1f2f0, format DXGI_FORMAT_R8G8B8A8_UNORM, flags 0, mode_count 0x5fd600, modes 0x7f3486d84300 partial stub!
info: Presenter: Actual swap chain properties:
info: Format: VK_FORMAT_B8G8R8A8_UNORM
info: Present mode: VK_PRESENT_MODE_FIFO_KHR
info: Buffer size: 1920x1080
info: Image count: 3
info: Exclusive FS: 1
info: Setting display mode: 1920x1080@60
LogD3D11RHI: Error: agsDriverExtensionsDX11_SetDepthBounds(1,0.000000, 1.000000) returned error code 2. **PLEASE UPDATE YOUR VIDEO DRIVERS***
LogKsOnlineServices: Display: Trying to (re)connect to KSON backend
LogKsOnlineServices: Warning: OnlineService's connection state 0 changed to 1
LogKsOnlineServices: Display: KSON backend connected
LogSlate: Warning: FontCache flush requested. Reason: Culture for localization was changed
LogSlate: Warning: FontCache flush requested. Reason: Culture for localization was changed
LogAudio: Error: ~FXAudioDeviceProperties: XAudio2->Release() error: Unhandled error code 1
info: Restoring display mode: 1920x1080@60
```

Not really sure what's going on, maybe it doesn't like that it couldn't go online?

I don't know. This is the last game log, not the steam log:
AC2.log

I'm also now failing with the 1.4 update. @ah- what proton version are you on? What kernel? What video card? any tweaks? Resolution?

LogConsoleManager: Warning: Setting the console variable 'r.VSync' with 'SetByGameSetting' was ignored as it is lower priority than the previous 'SetByProjectSetting'. Value remains '0'
LogStreaming: Error: Couldn't find file for package /Script/SourceControl requested by async loading code. NameToLoad: /Script/SourceControl
LogStreaming: Error: Found 1 dependent packages...
LogStreaming: Error:   /Game/GUI/Shared/WDG_InteractiveFooterButton
LogKsPhysics: Error: _ITERATOR_DEBUG_LEVEL is 0, no range checks
LogKsOnlineServices: Display: TcpClient trying to connect (stage 5)
LogKsOnlineServices: Warning: OnlineService's connection state 5 changed to 0
LogKsOnlineServices: Display: Connecting to 809a.assettocorsa.ne, 809b.assettocorsa.ne:809
LogKsPhysics: Error: TCP socket setTimeout error detected 10009 

LogInit: Display: Game Engine Initialized.
LogInit: Display: Starting Game.
info:  Presenter: Actual swap chain properties:
info:    Format:       VK_FORMAT_B8G8R8A8_UNORM
info:    Present mode: VK_PRESENT_MODE_IMMEDIATE_KHR
info:    Buffer size:  1920x1080
info:    Image count:  2
info:    Exclusive FS: 1
28448.814:00e4:00e8:fixme:dxgi:dxgi_output_GetDisplayModeList iface 0x3f1f2f0, format DXGI_FORMAT_R8G8B8A8_UNORM, flags 0, mode_count 0x5fd600, modes (nil) partial stub!
28448.814:00e4:00e8:fixme:dxgi:dxgi_output_GetDisplayModeList iface 0x3f1f2f0, format DXGI_FORMAT_R8G8B8A8_UNORM, flags 0, mode_count 0x5fd600, modes 0x7f3486d84300 partial stub!
info:  Presenter: Actual swap chain properties:
info:    Format:       VK_FORMAT_B8G8R8A8_UNORM
info:    Present mode: VK_PRESENT_MODE_FIFO_KHR
info:    Buffer size:  1920x1080
info:    Image count:  3
info:    Exclusive FS: 1
info:  Setting display mode: 1920x1080@60
LogD3D11RHI: Error: agsDriverExtensionsDX11_SetDepthBounds(1,0.000000, 1.000000) returned error code 2. **********PLEASE UPDATE YOUR VIDEO DRIVERS*********
LogKsOnlineServices: Display: Trying to (re)connect to KSON backend
LogKsOnlineServices: Warning: OnlineService's connection state 0 changed to 1
LogKsOnlineServices: Display: KSON backend connected
LogSlate: Warning: FontCache flush requested. Reason: Culture for localization was changed
LogSlate: Warning: FontCache flush requested. Reason: Culture for localization was changed
LogAudio: Error: ~FXAudioDeviceProperties: XAudio2->Release() error: Unhandled error code 1
info:  Restoring display mode: 1920x1080@60

Not really sure what's going on, maybe it doesn't like that it couldn't go online?

Is this log from a working game? If yes, then that helps me out in my debugging greatly.

@ah- If yours is working, a full set of log files would help me out with fixing this :)

Sure, here you go. The above was from @leillo1975 s failed log, just with the seh noise removed.

Mine's here, I think all the details are in the log itself: steam-805550.log.gz. Just launched the game, went into the main menu and exited.

@ah- : You're the only one for whom this is working... Are you by chance lauching in VR mode?

Also, sorry for all the questions, but would you mind running again and grabbing a log with the DXVK log level set to trace? @ah- Thanks for your help. I have to get mine fixed before Sunday's race.

The game terminates here too while playing the UE4 logo. I have tried a clean prefix, that shows me the language selection screen, but then still terminates. It's not a crash, it just exits. The only somewhat suspect lines in the game log are I guess

[2020.05.14-18.56.58:791][169]Closing by request
[2020.05.14-18.56.58:791][169]LogWindows: FPlatformMisc::RequestExit(0)

No idea what's the meaning behind it.
Edit: Interesting note, the exit happens not always at the same time, sometime 'm able to select a language, sometimes it exists before.

Looking at the log files, it looks like it dies when it has a TCP connection timeout, which is an error I've seen before. It says it's trying to connect to the following DNS locations:

• 809a.assettocorsa.ne
• 809b.assettocorsa.ne

Running dig for me against those doesn't resolve anything. @ah- what do those resolve to for you? I'll add an /etc/hosts entry locally and see if that fixes it to confirm.

Strangely, 809a.assettocorsa.net resolves for me, and looking up the winsock error that occurs (10009), it means Bad File Number, which to me indicates a name resolution failure.

@mcoffin Don't know if it's the problem, but your log contains these entries, while the log from @ah- does not:

steam-805550.log:314839:28454.084:00e4:00e8:warn:seh:OutputDebugStringA "[2020.05.14-17.20.02:868][ 45]LogTextLocalizationResource: LocRes '../../../Engine/Content/Localization/Engine/es-ES/Engine.locres' could not be opened for reading!\r\n" steam-805550.log:315093:28454.085:00e4:00e8:warn:seh:OutputDebugStringA "[2020.05.14-17.20.02:870][ 45]LogTextLocalizationResource: LocRes '../../../Engine/Plugins/Online/OnlineSubsystemSteam/Content/Localization/OnlineSubsystemSteam/es-ES/OnlineSubsystemSteam.locres' could not be opened for reading!\r\n" steam-805550.log:315347:28454.086:00e4:00e8:warn:seh:OutputDebugStringA "[2020.05.14-17.20.02:871][ 45]LogTextLocalizationResource: LocRes '../../../Engine/Plugins/Online/OnlineSubsystem/Content/Localization/OnlineSubsystem/es-ES/OnlineSubsystem.locres' could not be opened for reading!\r\n" steam-805550.log:315601:28454.087:00e4:00e8:warn:seh:OutputDebugStringA "[2020.05.14-17.20.02:872][ 45]LogTextLocalizationResource: LocRes '../../../Engine/Plugins/Online/OnlineSubsystemUtils/Content/Localization/OnlineSubsystemUtils/es-ES/OnlineSubsystemUtils.locres' could not be opened for reading!\r\n" steam-805550.log:315855:28454.088:00e4:00e8:warn:seh:OutputDebugStringA "[2020.05.14-17.20.02:873][ 45]LogTextLocalizationResource: LocRes '../../../AC2/Content/Localization/Game/es/Game.locres' could not be opened for reading!\r\n"

Maybe look into those file locations, and/or try changing your language to en-US instead of es-ES?

```~ ❯❯❯ ping 809a.assettocorsa.net
PING 809a.assettocorsa.net (144.76.81.131) 56(84) bytes of data.
^C
--- 809a.assettocorsa.net ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3024ms

~ ❯❯❯ ping 809b.assettocorsa.net ✘ 1
PING 809b.assettocorsa.net (64.188.22.202) 56(84) bytes of data.
64 bytes from 64.188.22.202.static.quadranet.com (64.188.22.202): icmp_seq=1 ttl=121 time=14.8 ms
64 bytes from 64.188.22.202.static.quadranet.com (64.188.22.202): icmp_seq=2 ttl=121 time=14.8 ms
^C
--- 809b.assettocorsa.net ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 14.787/14.816/14.846/0.029 ms
```

@aeikum I haven't posted my logs, but since you're helping I'll attach mine here.

steam-805550.log.gz

@ah- are you by fchance using systemd-resolved? Or are you using something else? Interestingly, without using @1.1.1.1, dig times out for me on the assettocorsa.ne urls

Just normal dns via my ISP, DNS 1: 212.69.40.23.

Log with dxvk debug, full launch options PROTON_LOG=1 DXVK_HUD=full WINEFSYNC_SPINCOUNT=100 DXVK_LOG_LEVEL=debug %command%:
steam-805550.log.gz

@ah- Why do you have that WINEFSYNC_SPINCOUNT option set?

Just an old leftover, tested without it now and works just the same.

@ah- but are you using systemd-resolved or resolvd or what for DNS management locally?

@ah- Just checking, you are really on version 1.4?

@jp7677 I think he is since he has this log line

4167.921:00d4:00d8:warn:seh:OutputDebugStringA "[2020.05.14-18.36.57:142][  0]LogTemp: Project Version: 1.4.0\r\n"

Yep I'm sure it's version 1.4, it shows it in the UI as well. I think I'm using NetworkManager for dns management? It's just default arch with a normal gnome desktop.

The only other thing I can think of is I'm running the mainline nvidia driver, not vulkan beta. But it's quite more likely that this is dns/network related, no luck with just adding these two to /etc/hosts?

So, I've noticed these lines in @ah- logs, but NOT in mine (grep for 99Check to see the line right before where they should be.

AH- logs

4158.945:00d4:00d8:warn:seh:OutputDebugStringA "[2020.05.14-18.36.48:166][  0]LogKsPhysics: 99Check ok with S76561197993476496\r\n"
4158.946:00d4:00d8:warn:seh:OutputDebugStringA "[2020.05.14-18.36.48:166][  0]LogKsOnlineServices: Display: TcpClient trying to connect (stage 5)\r\n"
LogKsOnlineServices: Display: TcpClient trying to connect (stage 5)
4158.963:00d4:00d8:warn:seh:OutputDebugStringA "[2020.05.14-18.36.48:184][  0]LogKsOnlineServices: Warning: OnlineService's connection state 5 changed to 0\r\n"
LogKsOnlineServices: Warning: OnlineService's connection state 5 changed to 0
4158.964:00d4:00d8:warn:seh:OutputDebugStringA "[2020.05.14-18.36.48:185][  0]LogKsOnlineServices: Display: Connecting to 809a.assettocorsa.ne, 809b.assettocorsa.ne:809\r\n"
LogKsOnlineServices: Display: Connecting to 809a.assettocorsa.ne, 809b.assettocorsa.ne:809
4158.965:00d4:00d8:warn:seh:OutputDebugStringA "[2020.05.14-18.36.48:185][  0]LogKsGamePlatform: Sending kson connection request with account lastUpdated: 948612704\r\n"
4158.965:00d4:00d8:warn:seh:OutputDebugStringA "[2020.05.14-18.36.48:186][  0]LogKsPhysics: Error: TCP socket setTimeout error detected 10009 \n\r\n"
LogKsPhysics: Error: TCP socket setTimeout error detected 10009

My Logs

417.853:00e8:00ec:warn:seh:OutputDebugStringA "[2020.05.14-19.30.39:949][  0]LogKsPhysics: 99Check ok with S76561198056164727\r\n"
417.853:00e8:00ec:warn:seh:OutputDebugStringA "[2020.05.14-19.30.39:949][  0]LogKsPhysics: Error: TCP socket setTimeout error detected 10009 \n\r\n"
LogKsPhysics: Error: TCP socket setTimeout error detected 10009

My logs for this stage:

LogKsOnlineServices: Display: TcpClient trying to connect (stage 5)
LogKsOnlineServices: Warning: OnlineService's connection state 5 changed to 0
LogKsOnlineServices: Display: Connecting to 809a.assettocorsa.ne, 809b.assettocorsa.ne:809
LogKsPhysics: Error: TCP socket setTimeout error detected 10009 
NvAPI_D3D_GetObjectHandleForResource: Not implemented
NvAPI_D3D_SetResourceHint: Not implemented
LogInit: Display: Game Engine Initialized.
LogInit: Display: Starting Game.
NvAPI_D3D11_SetDepthBoundsTest: Succeeded
LogKsOnlineServices: Display: Trying to (re)connect to KSON backend
LogKsOnlineServices: Warning: OnlineService's connection state 0 changed to 1
LogKsOnlineServices: Display: KSON backend connected

(Please ignore the NVAPI logs)

Just for fun I've disconnected my network, still the same exit. (Though pretty sure the logs were slightly different in that case.). Thus not sure if this is network related ...

Someone need something from me (logs, tests)? I tried to make a clean prefix and the game exits after show the language selection.

@leillo1975 @jp7677 @ah- What CPUs does everyone have here?

I have a i7 3770, GTX-1060-6GB (440), 16GB, and I use Ubuntu 20.04

Nothing special, i7-6850K, 1080GTX, Fedora 32, Nvidida 440.82.

@ah- Would you mind zipping up your whole c:\users\steamuser\My Documents\Assetto Corsa Competizione folder and pasting it here so I can try with your EXACT settings?

Assetto Corsa Competizione.zip

@leillo1975 thanks, but I'm really looking for @ah- 's setup since his is the working one

ac.zip
Had to skip the MoTec dir or the zip got too big to upload to gh.

Also it's a threadripper 2950x in case it matters.

@ah- Thanks. Would you mind entring a practice session to make sure htat's working for you as well, and post a log of that? I'm working on this right now.

Thanks for all your help. People like you are a godsend for fixing these problems

I just did a desperate attempt with a fresh prefix, no launch options and the latest proton from https://github.com/GloriousEggroll/proton-ge-custom/releases, but still the same behavior.
@mcoffin Are you able to enter the game now?

I just did a desperate attempt with a fresh prefix, no launch options and the latest proton from https://github.com/GloriousEggroll/proton-ge-custom/releases, but still the same behavior.
@mcoffin Are you able to enter the game now?

Negative.

As another interesting note, while I'm looking at other stuff, could someone who's having issues try changing their timezone to GMT (offset +0)? I noticed that @ah- is using the GMT timezone. It shoudln't matter, but it might... I guess? @jp7677 @leillo1975

Log from one lap of a special event:
steam-805550.log.gz

@ah-, would you mind to temporary rename your prefix and then trying to start the game? This creates a new prefix and might give a clue in which direction to look for?

@mcoffin Changing the timezone to Iceland made no difference here.
Edit: I tried UK as well ;)

I'm in the UK, but I hope that makes no difference.

New prefix still works, log:
steam-805550.log.gz

The only other thing I can think of is that I hadn't played for at least a couple weeks before trying 1.4.

Thanks for trying. Well, I guess then that it has nothing to do with in-game settings.

Dammit. I literally can't see what's wrong... it's like the window is getting destroyed unnecessarily

I was able to get to the language selection screen, select english, then it crashed immediately afterwards by removing my entire My Documents/Assetto Corsa Competizione directory (after making a backup). @jp7677 can you confirm this behavior at all?

Yes, same here. There is no crash btw. The game just exits by itself.

@ah- When you close the game, are you closing it via your window manager, or by going through the menu, or by alt-F4'ing or what? I'm trying to debug the "Closing on request" message that we're seeing when the game decides to close

Via the menu in the game.

@jp7677 how exactly are you launching the game? I take it from an earlier message that @ah- is launching via steam with the command line he posted above

Just the normal green play button in Steam. I have some launch options
(game mode, wine overrides for video playback) but also clearing them made
no difference.

On Thu, 14 May 2020 at 23:18, Matt Coffin notifications@github.com wrote:

@jp7677 https://github.com/jp7677 how exactly are you launching the
game? I take it from an earlier message that @ah- https://github.com/ah-
is launching via steam with the command line he posted above

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/1420#issuecomment-628891745,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEDL5XNGT2XTWUQARYGME2DRRRNZXANCNFSM4FUYQ7UQ
.

@jp7677 mind sharing your overrides for video playback?

See further above in this thread (I’m currently not in front of my
machine), I had created a bigger posting in the past describing what was
needed for video playback. Note that it involves more than adjusting the
launch option.

On Thu, 14 May 2020 at 23:25, Matt Coffin notifications@github.com wrote:

@jp7677 https://github.com/jp7677 mind sharing your overrides for video
playback?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/1420#issuecomment-628894970,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEDL5XPY5EYWHO35WCVUN73RRROV3ANCNFSM4FUYQ7UQ
.

I can confirm this likely isn't a windowing/fullscreen issue, as the exact same behavior is observed on Wayland

Does the game work for any of you in version 1.4?

@ah- claims it's working for him

@ah- is the video playback working for you, or no?

Ugh, this is so frustrating, especially since someone actually has it working.

Update: if you alt-F4 or kill the window with your window manager, then you do not get the Closing by request log message, meaning that the game knows it's terminating. It's almost as if it thinks that the "Exit" button is being clicked.

Blind guess, but what if there was a phantom gamepad/joystick input sending a back-type command? @ah-, do you happen to play with mouse and keyboard? At this point it wouldn't hurt to test if the issue can be avoided by unplugging all non-essential peripherals.

@kisak-valve I've done that already (only mouse + keyboard left plugged in), and no change. Still game exits on it's own.

From his logs, @ah- is playing with a controller... but I haven't found a single other person able to make it run so far.

I disconected my wheel and webcam and nothing changed

This is quite frustrating, since the game is obviously making itself exit since that message doesn't appear unless you have this problem or manually exit via the menus

Just tried a whole bunch of things, and none of them broke ACC for me, it just keeps working. Using steam-native, going offline, disconnecting all my controllers, using fluxbox instead of gnome. No idea what's going on for you. My installation is pretty old though, I might have some old symlinks for gnutls versions etc. lying around, but I really can't imagine that those are what makes this work.

Video playback isn't working for me, I just get a black window and need to click with the mouse to skip to the menu.

Ok, so at least that's sane. Do you have any DLL overrides for that prefix (check in winecfg with PATH and WINEPREFIX set appropriately)

I'm going to absolutely lose my shit trying to fix this. I have no idea what's different for @ah-

Anyone figure out anything on this? My league race is coming up :(

@ah- If you have time tomorrow to sit down with me and try to figure this out, I'd greatly appreciate it. Discord/IRC/whatever; you name it!

Since I'm in a time crunch, I'll add a $50 bug bounty to this for anyone that fixes it, or provides me with the information that enables a fix.

Unreal Engine 4 has its own logging system. When adding the following to [prefix- folder]/805550/pfx/drive_c/users/steamuser/Local Settings/Application Data/AC2/Saved/Config/WindowsNoEditor/Engine.ini:

[Core.Log]
global=VeryVerbose

I get much more info in the 805550/pfx/drive_c/users/steamuser/Local Settings/Application Data/AC2/Saved/Logs/AC2.log file.

Directly before exiting is says now:

[2020.05.15-05.24.33:043][163]LogPrimitiveComponent: VeryVerbose: Driver_Player2->Driver_Head Performing overlaps!
[2020.05.15-05.07.38:219][198]LogScriptCore: Verbose: CallFunctionByNameWithArguments: Name not found ''
[2020.05.15-05.07.38:219][198]LogScriptCore: Verbose: CallFunctionByNameWithArguments: Name not found ''
[2020.05.15-05.07.38:219][198]Closing by request

No idea if this has anything to do with the request for closing though...

Gave up on VeryVerbose after a few minutes, but here's a Verbose log:
AC2.log.gz

same error for me with release 1.4, prev version work perfectly.

I just got version 1.4.1, this version is starting fine here!

It works again, great. I hope the help to fix the Stuttering on Multiplayer races. I left a message on their support forums. I think that you must support it leaving a response, so they can see that there are more than one of us playing on Linux:
https://www.assettocorsa.net/forum/index.php?threads/lots-of-stuttering-on-online-races.64414/

Hi @mcoffin, since you seem to race online in a more professional way with ACC on Linux, do you actually face frame time spikes like @leillo1975 is describing or like me having described here https://github.com/doitsujin/dxvk/issues/1161 (It is no longer that worse here on my system, but I still get these kind of frame time spikes)?
If not, could you share some specs of your system and configuration? I still highly suspect CPU usage to be the issue, but would love to hear some more thoughts on that topic.

Edit: May be you could join the discussion @leillo1975 opened on the Kunos forums, that's may be better place since we might get some thoughts from other people too? I don't know how well "mentioning" works on the Kunos forums, hence I started here.

I don't know how well "mentioning" works on the Kunos forums, hence I started here.

It works like here. You only has to use "@username" to mention

Work on 1.4.1

Work on 1.4.1

I can confirm that this is once again 100% good to go with 1.4.1 and 1.4.2. Thanks to Kunos for the amazing support!

Hi. Well, performance for me is not as good as you guys are describing. I get 32 instead of 113 on windows. Also, framerate in menu is cut to 30 from 108 every time I get back from being on track. I have gtx 970 with exact same settings on both OSs. Can anyone help? Also tried vulkan dev drivers from nvidia 440.66.15-1, where I get error Error: agsDriverExtensionsDX11_SetDepthBounds(1,0.000000, 1.000000) returned error code 2. **********PLEASE UPDATE YOUR VIDEO DRIVERS*********. during launching sequence. Funnily enough, it proceeds if you have game window minimized during this period. Also, game crashes when entering circuit selection menu with Proton-5.8-GE-2-MF which fixes videos. Any ideas? I'm trying to make it run correctly until freeweekend, so I can buy it later knowing it will be viable to play. @leillo1975 Could you help?

Also, game crashes when entering circuit selection menu with Proton-5.8-GE-2-MF which fixes videos.

Probably this Proton version tries to decode videos and it can't . Use the official version and whe the screen remains in black push a button to skip to menu.

@leillo1975 for clarification, GE Proton can decode videos - intro videos work just fine. When selecting tracks it crashes. And there are no videos. I use standard proton for now.

I'm more concerned by the general performance. Is the behavior the same for you? I mean 20% of windows performance in hotlap mode? And decreasing performance in menu?

Hi @Furious7c8 I'll try to comment your questions one by one:
1) Fps in menus: There is a setting that (thankfully) restricts fps in menus to 30 fps, I guess you just have this off in Windows ;)
2) Fps in-game: do you get that much of a difference with the same settings? I don't have a Windows OS to compare, but that difference sounds kind-of huge. That said an GTX 970 might be somewhat limited. Games on Linux with DXVK really need more VRAM than on Windows with DX. Maybe you are limited there. From my experience the same recommendation apply than for Windows. E.g. mirror quality can tank your fps.
3) SetDepthBoundsTest is a method that in not part of DX11, but belongs to either AMD-AGS or NV-API. Unreal Engine can use this which results in slightly more fps (between 1% and 2%). You might want to try https://github.com/doitsujin/dxvk-ags or https://github.com/jp7677/dxvk-nvapi but it's some work to set this up with minimal gain. It's perfectly fine to ignore this.
4) The track videos are of a different format than the ones in the intro and contain no audio track. See here for the details https://github.com/ValveSoftware/Proton/issues/1420#issuecomment-526511312 . The Media Foundation work is still heavily ongoing, just give it some more time ;)

@jp7677 Thanks for answer.

1. I'm aware of this setting. As stated, settings are tripplechecked to be identical. FPS in menu are 109 fps -> I go to track -> exit track to menu -> I have 30 fps. Definitely something is broken.
2. With quite big experience I agree that's too big of a difference. In example I have 15 % decrease in performance across all Proton games I have. I think it's worth fighting for as it is not simple overhead. Something is definitely broken.
3. Will check that.
4. I see... But I haven't seen any video regarding tracks, not even on windows.

1: Ah, now I understand what you mean. I think that I have seen this behavior too, but (if it is/was what you are describing) just may be 5 times totally (with more than 100 hours in the game). Since it happened so rarely I just restarted and forgot about it. Now idea what it could be (no more VRAM available? May be the DXVK HUD could give you some hints?)
2: Yeah, please let me know if you found a way or certain setting that mitigates the behavior you are seeing.

1. Well, that's strange ;). I'm seeing the track videos on Linux, though after quite some tinkering as described in the post (much) further up.

I think that the worst problem that this game have is not videos or video performance. The multiplayer online stuttering is the main problem to fix, because the best of this game is this feature, and the linux users can't compete with other player in the same conditions. I don't know if Valve/Codeweavers devs are aware of this.... @aeikum I don't know if your work are related to Wine/Proton network , but if not, can you show the problem to the right dev? There are a similar problem with rFactor 2. Perhaps something on Wine/Proton needs to take a look.

@jp7677 My last comment for a while.

1. This happens everytime so it's unacceptable. I checked vram useage and it is not any different than on windows. Not an issue imho.
2. I have tried various flags from dxvk and different proton versions but to no avail.
3. DXVK-nvapi did not help with in anyway (preventing error from appearing). Pretty sure I did all necessary steps.

I have also compared behavior with windows. On Win there are 84 threads created and cpu usage is never at 100%. A lot of threads occupy the cpu in some meaningful way and everything seems ok. On Linux however I see same behavior as you described before, where one thread is pegging the cpu thread to 100% while the rest of... wait for it... 160 threads created by the game are idle in general. What is also 100%, is my confidence that there is a problem with thread synchronization somehow. I hoped to find some of the known flags in dxvk or wine to alter the behavior at least, to see some promise. One thing I haven't tried is fsync enabled kernel, but right now I don't have much hope. Have anyone tried?

@leillo1975 I have checked online (not going to track honestly) to check the stuttering you described. As the performance results are so inconsistent I have once managed to have above 90 FPS. Then I have noticed no stutters. TBH I believe that (if we are not talking about shader compilation "fixed" by fosilize) than the source of stutters is the same as the poor performance in general.

I believe it would be hard to find a tool to investigate this threads behavior, am I right?

@Furious7c8 Thanks for your detailed descriptions. Yeah, my bet would also be that wine has difficulties to handle threads/thread-synchronization the way ACC uses it. I've tried an f-sync kernel once or twice but didn't see much difference here. I guess it is surely the case, but e-sync is up and running correctly on you machine?
Bottom line I guess is that you really need a beefy system to play this games somewhat OK-ish on Linux (i7-6850K/GTX1080 on Fedora 32 here).

0001-ntdll-Perform-fsync-in-client.txt

The attached patch should help with stuttering in multiplayer.

Oh really really cool, thanks a lot! Now It’s time to get my proton build
environment up and running again. Do I need an f-sync enabled kernel to
effectively use this?

On Thu, 4 Jun 2020 at 19:40, gofman notifications@github.com wrote:

0001-ntdll-Perform-fsync-in-client.txt
https://github.com/ValveSoftware/Proton/files/4731792/0001-ntdll-Perform-fsync-in-client.txt

The attached patch should help with stuttering in multiplayer.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/1420#issuecomment-639002790,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEDL5XMLO5U5TG4XWBATTZLRU7MBRANCNFSM4FUYQ7UQ
.

No, the issue and the fix are not sync-related, it worked fine for me even without esync (I don't think this game depends much on that).

0001-ntdll-Perform-fsync-in-client.txt

The attached patch should help with stuttering in multiplayer.

Where and how is this patch applied?

I hope the patch will make its way into the next Proton release. You would need to build Proton from source to use it. I put it here just in case anyone is willing to do that and try it before.

Here is a bit better version of the patch.
0001-ntdll-Perform-fsync-in-client.txt

@gofman I've applied your patch on top of proton-5.0-next and indeed, the heavy frame time spikes, especially in multi player sessions, are gone. Really really cool, once again thanks a lot for looking into this. It would really be cool if this patch goes into proton/upstream wine.

@leillo1975 If you know how to use a custom proton build, you can download and try my build here
https://www.dropbox.com/s/dz1kk9i22buz8fj/proton-5.0-8-acc-0001-ntdll-perform-fsync-in-client.tar.xz?dl=0

Edit: Updated link for Proton-5.0-8+patch

@gofman I've tried the patch in rFactor 2 in hopes that it would help there but it didn't. I don't have ACC to try. It seems related to the heavy use of the network. This is the issue in case you're interested to take a look: https://github.com/ValveSoftware/Proton/issues/245#issuecomment-606511619

@berama

I've tried the patch in rFactor 2 in hopes that it would help there but it didn't. I don't have ACC to try. It seems related to the heavy use of the network. This is the issue in case you're interested to take a look: #245 (comment)

I will try to look into this in some coming days. Is there any sure way how can I observe the problem in game, without trying to keep in up with the other players? Ideally (for the sake of easier information gathering), maybe you know any observable effect without even moving anywhere from the pit?

Can you please collect the log from a slow multiplayer session if possible (probably not too long as log may grow big) recorded with WINEDEBUG=+pid,+timestamp,+loaddll,+process,+thread,+winsock,+seh? And attach it to the Wine bug report (it may be huge but they are zipped very well): https://bugs.winehq.org/show_bug.cgi?id=48668.

Really, really great!!!
https://youtu.be/YDYoGotwzlM

Thanks a lot, @gofman

I have just checked where my performance problems are originating from. It turns out, that on windows with DXVK the behavior is basically the same ( about 10 FPS more, probably by removing wine overhead). So, sadly, I don't believe I'm able to do anything about it unless @doitsujin will check it out. Also, mine 970 is pegged on VRAM on windows, which probably attributes to low performance ( last 500 Mb being very slow drama from couple years ago).

The Wine patch is now upstreamed into Wine with some adjustments:
https://github.com/wine-mirror/wine/commit/3078f10d43d834b0498358fe0accb565191b7020

Fingers crossed that it will also find its way into the next Proton version.

Really great! Thanks again @gofman

@jp7677 - Looks like this got resolved already, but I'll answer the question regardless.

I do experience some spikes, but only when new cars connect. This isn't a problem for league racing, though, as it will only interrupt qualifying.

There is a new kind of stutter introduced in the latest patch, that happens when the game tries to load up custom liveries, but that happens on Windows as well, so just note that that case will be a red herring when testing that the patch is working.

I hope the patch will make its way into the next Proton release. You would need to build Proton from source to use it. I put it here just in case anyone is willing to do that and try it before.

Here is a bit better version of the patch.
0001-ntdll-Perform-fsync-in-client.txt

@GloriousEggroll , can you include this fix on your next Proton-GE?

For your testing pleasure: http://www.mediafire.com/file/7zc3875pe8koyoh/proton-5.0-9-rf2-acc.7z

Both latest ACC and rF2 patches are applied to the latest Proton 5.0-9.

My ACC binary changed in a silent patch today, and we're crashing on startup now for me :(

never mind I'm actually an idiot. my launcher script crashes when the wheel isn't plugged in, because I'm a dunce.

Proton-5.9-GE-ST works out of the box, with videos and the last patches:
https://github.com/GloriousEggroll/proton-ge-custom/releases/tag/5.9-GE-4-ST

@leillo1975 Your were linking to https://github.com/wine-staging/wine-staging/commit/8402c959617111ac13a2025c3eb7c7156a2520f8 in the "Proton 5.0-10 RC testing" issue, what changes with this commit for ACC?

The patch fixes stuttering on multiplayer races. There are also a rFactor2 patch that fixes online issues

Are you sure?
The multiplayer stuttering was fixed with https://github.com/wine-mirror/wine/commit/3078f10d43d834b0498358fe0accb565191b7020 , that's the first link you posted in the "Proton 5.0-10 RC testing" issue. My question was about the second link you posted for ACC.

@leillo1975 I have looked again at that Wine-Staging patch link you had posted. I guess you just blindly copied this link from the Proton-5.9-4-GE-ST release notes? I kind of doubt that it has any effects on ACC. This patch is for ACL (Access Control Lists) support. I would suggest to remove that link from your list of links in the "Proton 5.0-10 RC testing" issue to avoid any confusion.

@GloriousEggroll Could you please clarify if this patch https://github.com/wine-staging/wine-staging/commit/8402c959617111ac13a2025c3eb7c7156a2520f8 as mentioned in https://github.com/GloriousEggroll/proton-ge-custom/releases/tag/5.9-GE-4-ST really does affect Assetto Corsa Competizione (ACC)? As fair as I'm seeing, this patch is about Access Control Lists (ACL) support.

this was the ac patch:
https://github.com/wine-mirror/wine/commit/3078f10d43d834b0498358fe0accb565191b7020

If you notice, the first part of the patch changes the ACLs required in the if statement:

if (!ret && (type == FD_TYPE_FILE || type == FD_TYPE_DIR))

This breaks Origin, because the ACL staging patch incorrectly was assigning the wrong ACLs when origin was run. So, to correct that, you need the updated ACL patch from staging.

There's actually another fix for this further upstream that needs to be backported which fixes the issue in vanilla wine in addition to staging. (I'm the one who discussed this with Paul, the author of the patch when it was fixed.):

https://github.com/wine-mirror/wine/commit/01143089f08c662a75f5af47fc2a8a3f8ae2afd6#diff-9d5b3420303a159fb3342fbfd812b20f

Paul Gofman06/23/2020
Ok, it is actually oldest Staging patchset server-Stored_ACLs occasionally turns normal files into FILE_FD_CHAR in server if the files have security descriptor. Origin does not flush character devices of course, there are just security descriptors for normal files.
We should probably fix that, file type affects more than triggering regression in my recent patch.
set_file_sd() in server/file.c has the assignment that effectivly cleares _REG / _DIR attribute on file mode, so later the file is treated as FD_TYPE_CHAR
Not like we don't want the flushes for character devices working, just having that to affect Origin looked very weird.
I think I will fix that

Paul Gofman06/23/2020
Pushed update. Now the issue with Origin should be double fixed.

I hope the patch will make its way into the next Proton release. You would need to build Proton from source to use it. I put it here just in case anyone is willing to do that and try it before.

Here is a bit better version of the patch.
0001-ntdll-Perform-fsync-in-client.txt

I talk about this patch. @gofman could explain this things better , including the rfactor2 multplayer patch.
This changes are included in one of the last Wine versions

I hope the patch will make its way into the next Proton release. You would need to build Proton from source to use it. I put it here just in case anyone is willing to do that and try it before.
Here is a bit better version of the patch.
0001-ntdll-Perform-fsync-in-client.txt

I talk about this patch. @gofman could explain this things better , including the rfactor2 multplayer patch.
This changes are included in one of the last Wine versions

Both these patches are in upstream Wine and should appear in the next Proton rebase (that is, major update based on newer Wine version).

I think comment https://github.com/ValveSoftware/Proton/issues/1420#issuecomment-664136646 by @GloriousEggroll basically explains where the rumours about ACL patchset come from.

server-Stored_ACLs Staging patchset is not needed neither for Assetto Corsa nor for Origin to work.

Yet Wine Staging and @GloriousEggroll's GE build (which is based on Staging) have this patch and the combination of it with upstreamed 0001-ntdll-Perform-fsync-in-client.txt caused regression in Origin. That regression was double fixed by https://github.com/wine-mirror/wine/commit/01143089f08c662a75f5af47fc2a8a3f8ae2afd6#diff-9d5b3420303a159fb3342fbfd812b20f in mainstream and by https://github.com/wine-staging/wine-staging/commit/8402c959617111ac13a2025c3eb7c7156a2520f8 in Staging.

@GloriousEggroll @gofman Thanks a lot for the detailed clarification, no questions left!
Thanks @leillo1975 for editing your comment in the "Proton 5.0-10 RC testing" issue!

Hello all, my Valve Index came in today!

So far, I can tell it's close, but VR support for this title is still in fact broken due to a NULL-pointer access somewhere. I'll start digging since Project Cars 2 (also UE4 I believe) is working, and hopefully I can find out what's going on, but for others interested in debugging, here is the game and proton log from an attempt to run it in SteamVR mode.

AC2.log
steam-805550.log

New info on VR mode, it seems that IVRCompositor::Submit is getting called with a texture that has a NULL handle somewhere, as texture->handle == NULL in the above case, causing the 0x0 pointer dereference. (confirmed with custom vrclient_x64 logging)

Now, I just spent about 5 hours trying to attach a debugger to this damned game and break on ivrcompositor_submit, but for the absolute life of me I can't make it work. If I start the game OUTSIDE of steam, it complains about steam not being running. If I start it from steam, then the debugger can't attach. I won't be working on it for a little bit, as I almost completely lost my shit spending that much time on such a simple thing (starting with a debugger).

Hi @mcoffin thanks a lot for your effort. I don’t own an Index, but I’m getting more and more interested, so I’m closely following your progress here ;)
As far as I read Project Cars 2 isn’t built on UE4 but on there own engine, so this might not be the best reference. About your findings, not sure how to proceed. I guess you have found the source code here https://github.com/ValveSoftware/Proton/blob/proton_5.0/vrclient_x64/vrclient_x64/vrclient_main.c#L894 may be wise to directly ask someone here for a direction.

Ok boys, new info (again) - cc: @jp7677

I added a hack to ivrcompositor_submit to make it not segfault when a NULL texture handle is passed it (it just falls through to the "Invalid texture handle" code that already existed).

With this workaround, the game now launches in VR, and you can see things in 3d, but, it looks like all of the invalid textures correspond to the overlay that the game is supposed to be displaying (the menu), which doesn't show up whatsoever.

Regardless, I at least finally got to see something happen, even if it's not all that useful.

Unfortunately, the VR here seems to suffer from the same synchronous rendering lag between the eyes that PC2 does :( so there's likely performance issues on top of this even once we get the menu overlay sorted out.

WRT to pcars2, I thought they were the same since it also shows the UE-typical LogHMD lines when started in VR mode. @jp7677

On second look, it looks like IVROverlay::SetOverlayTexture doesn't have any of the logic from IVRCompositor::Submit to perform the dxvk vs wined3d conversion... maybe that's the issue?

@mcoffin Cool progress! Could you try it once with Wine3D instead of DXVK, maybe that gives some clues to narrow it further down.
Regarding PC2, I might be very wrong with my statement, I don't own the game, I just read on the all-knowing Internet that they used there own engine (Madness Engine).

@jp7677 lol we posted at the same time.

as far as wined3d goes, it just gives me a permanent black screen (full screen) in the HMD.

I didn't look in to it too closely, though, as I've had nothing but issues with WineD3D on D3D10+. It took me AGES to get ArmA III running well (then dxvk came out like a year later lol)

@jp7677 also if you know a good way to actually get a debugger running in this game, I have some super hacky ways, but none of them is perfect, and I'd KILL to be able to just have breakpoints on all d3d11, dxgi, vrclient, and openvr functions. Trying to correlate timestamps between apitrace, DXVK, proton, etc. is killing me

if I launch using winedbg, it exits because it can't connect to steam. I can't launch winedbg with steam's launch options because stdin/stdout are fucked. Attaching later kinda works, but only half of the libraries actually get their debug symbols loaded, the disassembler doesn't work at all, printed register values are spotty at best, and vrclient shows up as non-debuggable, though I confirmed that it has debug info included. (I rarely get pissy at code but I almost punched my monitor spending hours just trying to get a working debugger setup. So frustrating).

Also, super big bummer that Kunos doesn't allow for vulkan support. Wouldn't take much except porting the HLSL shaders, but the only reason -vulkan doesn't work on the command line is that they don't include the UE4 "cooked" resources (whatever that means).

Yes, using Wine3D for ACC for real is no option, I just meant it for troubleshooting this issue, may be the texture->handle isn't null with Wine3D.

But may be you are already quite close with your thoughts about SetOverlayTexture...

Regarding debugging, unfortunately not.. except using old-school console writelines :(

I mean, I've never seen a VR menu that has this style work on Linux (the one where it's just the game screen stuffed in.... I'll bet you anything that it's managed with IVROverlay, and the lack of vk<->d3d implementation hacks there is the issue. I'll dig deeper tomorrow, but I almost lost my shit again today working on this, so I'm done with it for the night... I'm gonna actually go do some racing before I have to do 4hrs on Paul Ricard in the morning...

Side note: having a DHCP-enabled video open in firefox, on a second monitor, driven by a different GPU, using PRIME to transfer frames to the main GPU, then composited, displayed and sent back seems to crash this game on any shader compile...

Now, that's 100% workaroundable, but a kinda interesting tidbit I ran in to while trying to watch netflix while debugging this. (happens on Hulu + purchased content on YouTube as well... Yay drm)

Thanks a lot for your effort till now and good luck with the race! ;)

@jp7677 do you know what language vrclient is trying to emulate? I've never seen that kind of ABI before. Is that trying to be like C#?

@mcoffin as far as I know, the vrclient is a bridge to multiple versions of the OpenVR client. Most of the files are generated by https://github.com/ValveSoftware/Proton/blob/proton_5.0/vrclient_x64/gen.sh and thus https://github.com/ValveSoftware/Proton/blob/proton_5.0/vrclient_x64/gen_wrapper.py

@jp7677 The menus are now showing up, and VR working!!!! I'm about to try to get in a game and see if that works. There's still some performance issues (just like as seen in pCars), so there's definitely some work to be done on that side, or possibly with my settings.

mcoffin/Proton@acc

EDIT: The patches are definitely not ready for upstream submission, as they're a mess, I just got it working, and it only supports the DXVK case right now. When I really submit them, I'll refactor the DXVK/WineD3D/Vulkan texture translation cases out in to their own code base so there's less code duplication, and support the non-DXVK cases.

Who would have thought that it was this close to working?

@mcoffin oh nice, really really cool progress!

Performance issues now resolved as well - Just don't use the legacy rendering mode (use the new one (async) in SteamVR settings (application-specific)).

There is now only one issue I can find - there's a few tracking hiccups, but that seems to be the fault of SteamVR in high-cpu load scenarios, rather than the fault of Proton/ACC

Anyone else getting random freezes in this game? For me, sometimes the game gets stuck. The sound goes on, but the image doesn't change and I've to kill the game. In dmesg i get this:

[432570.790754] NVRM: GPU at PCI:0000:01:00: GPU-756c0726-1313-410f-39b6-ed71283e1126
[432570.790758] NVRM: GPU Board Serial Number: 
[432570.790760] NVRM: Xid (PCI:0000:01:00): 13, pid=399, Graphics Exception: EXTRA_MACRO_DATA
[432570.790766] NVRM: Xid (PCI:0000:01:00): 13, pid=399, Graphics Exception: ESR 0x404490=0x80000002
[432570.790901] NVRM: Xid (PCI:0000:01:00): 13, pid=513968, Graphics Exception: ChID 0067, Class 0000c197, Offset 00002394, Data 00000000

Acc log ends with lots of messages like this:

[2020.08.23-19.03.35:965][125]LogD3D11RHI: Timed out while waiting for GPU to catch up. (0.5 s)

Any ideas?
Some system information: gentoo, proton-5.09, nvidia-drivers-450.57-r1, GTX-1060

Hmm... that sounds like an incompatibility with the NVIDIA proprietary drivers (unfortunately).

If you're in VR, I've heard there's issues with async reprojection and NVIDIA cards, so if you disable it, it may start to work, but I'd imagine the performance would be nigh unlivable.

Aside from that, what's your kernel version?

I have a second rig with a 2070S I could try later today to see if I encounter the same issue.

I've noticed that the game does NOT deal well with socket timeouts, so network connection timeouts sometimes crash the game for me, so that could be a factor too, though I doubt it given the dmesg lines you showed.

@gotzl is your card overclocked at all? What resolution are you trying to run the game at? some cursory searching found that this error is sometimes indicative of a dying card, or one that's being pushed a little too hard.

It's freezing for me as well. It usually freezes while the game is loading, ie before the main menu, but it will sometimes freeze later. When it freezes later, it's usually immediately after I click a button on a menu, although it sometimes seems to just freeze randomly. If I'm driving when it freezes, it continues to play the same audio on loop and the graphics don't change, but I know the physics are still simulated because my wheel's force feedback changes.

Crash while loading:
steam-805550.log.zip

Crash while racing:
steam-805550.log.racing.zip

Crash after clicking load setup button:
steam-805550.log.button.zip

$ uname -r
5.7.12-arch1-1

$ pacman -Q mesa
mesa 20.1.5-1

I have a Vega 64 and don't see any similarities with @gotzl's log so maybe this is a separate problem...

It's freezing for me as well. It usually freezes while the game is loading, ie before the main menu, but it will sometimes freeze later. When it freezes later, it's usually immediately after I click a button on a menu, although it sometimes seems to just freeze randomly. If I'm driving when it freezes, it continues to play the same audio on loop and the graphics don't change, but I know the physics are still simulated because my wheel's force feedback changes.

Crash while loading:
steam-805550.log.zip

Crash while racing:
steam-805550.log.racing.zip

Crash after clicking load setup button:
steam-805550.log.button.zip

$ uname -r
5.7.12-arch1-1

$ pacman -Q mesa
mesa 20.1.5-1

I have a Vega 64 and don't see any similarities with @gotzl's log so maybe this is a separate problem...

Yep. I have the same issues as you, but I don't think it's related to @gotzl's issue. I've noticed that having any of the following in the background will make the hangs that you and I are experiencing much more likely:

• Video content playing in firefox
• HDCP content of any kind on X11
• An application which is actively rendering with DRI_PRIME
• Discord being open
• Zoom being running (even closed in the tray)

Looks like basically any activity on a secondary monitor can cause some weird stuff there.

I'm assuming you're seeing the corrupted size vs. previous size in your logs as well during these crashes? You sound like you're getting the same thing as me, though I'm dealing with it by avoiding the above and just re-launching until it works.

EDIT: After further inspection, it seems like these crashes always occur during any kind of shader load or compilation. @sambazley are you using fsync or esync at all? What are your shader caching settings for mesa and Steam?

EDIT 2: Based on when you see the issue, disabling esync might at least help you out, though it'll make the game stutter a few times on the first lap if the shaders are not cached

EDIT 3: The crash while driving (the dinput stub log), obviously doesn't apply to the message in EDIT 2

I'm assuming you're seeing the corrupted size vs. previous size in your logs as well during these crashes?

Sorry, I'm not sure what this means.

are you using fsync or esync at all

I'm using the default user_settings.py ("PROTON_NO_ESYNC": "1" is commented out) and I'm using the standard Arch kernel, so I guess that means I'm using esync?

What are your shader caching settings for mesa and Steam?

Steam shader caching is enabled. I've tried clearing the cache for this game, but it doesn't help.

disabling esync might at least help you out

Just tried it and it still froze.

Edit:
I see what you mean by the corrupted size vs. previous size error. Got any idea what it means?

Hi @mcoffin may be it is an idea to open a draft pull request with you modification for VR to make Proton devs aware of what is needed? You can obviously still improve your PR with force push if you find the time. It would really be cool if VR works out of the box with a future Proton version.

Hi @mcoffin may be it is an idea to open a draft pull request with you modification for VR to make Proton devs aware of what is needed? You can obviously still improve your PR with force push if you find the time. It would really be cool if VR works out of the box with a future Proton version.

If you're just worried about my time investment, I've got it 90% of the way ready for the PR now, just have to handle the vkd3d case (vulkan/d3d11 done), and I'll be ready to submit. No sense offering up half-baked functionality, but I get what you're saying if it was going to take me a lot longer.

Hi @mcoffin may be it is an idea to open a draft pull request with you modification for VR to make Proton devs aware of what is needed? You can obviously still improve your PR with force push if you find the time. It would really be cool if VR works out of the box with a future Proton version.

If you're just worried about my time investment, I've got it 90% of the way ready for the PR now, just have to handle the vkd3d case (vulkan/d3d11 done), and I'll be ready to submit. No sense offering up half-baked functionality, but I get what you're saying if it was going to take me a lot longer.

Thanks for the heads up! I hadn’t seen any activity in your fork and got indeed a bit worried that you hadn’t found time to finish your PR and/or would mis the timing for an upcoming Proton update (whenever that happens). Anyway, thanks a lot for your work and looking forward to it! Very cool!

Interesting note on the "corrupted size..." error: I upgraded to a Threadripper 3960X today, and couldn't launch the game for the life of me, but launching it with less cores proves more successful, so this is likely a race condition! Hooray for new info.

~@mcoffin regarding your Threadripper issue, do you use the mfplat dll’s from a Windows installation for having the in-game videos working?~

Edit: Scratch what I wrote earlier, I had mixed unrelated things.

~@mcoffin regarding your Threadripper issue, do you use the mfplat dll’s from a Windows installation for having the in-game videos working?~

Edit: Scratch what I wrote earlier, I had mixed unrelated things.

I tried it forever ago, but scrapped the whole thing because it didn't work and I didn't want to introduce more complexity when I was already getting these other sporadic crashes.

Hey guys, I tracked down the "corrupted size" error to a bug in Mesa. Using the lastest master should suffice :)

For anyone tracking this, the ffbtools PR mentioned above has been superseded by a better throttling system, in berarma/ffbtools#19 and berarma/ffbtools#20.

@mcoffin Do you have a compiled version of your patched vcrclient somewhere to download?

I don't really like distributing binaries since it's a bad habit for people to run things blindly, so I don't like encouraging it for those that don't know what they're doing, but since this is taking so long and those involved appear to not be those kinds of people, I put my build up. Please people don't rack up my AWS bill :laughing:

• proton-5.0-10_acc-vr.tar.xz
• proton-5.0-10_acc-vr.tar.xz.sig

cc: @jp7677

EDIT: note that the actual name of it is like acc-vr_5.0-9-local according to toolmanifest.vdf or something like that since that was my branch name locally, and I built this particular tarball from within that gnarly proton build VM

Second side note, if you're running a kernel with timeline syncobj support, and mesa>=20.2.0, then make sure you use SteamVR<1.15. SteamVR 1.15 uses timeline syncobjs to sync vroverlay submits, and it causes some relatively major jittering with the menus since they're implemented as IVROverlays. I'm not sure yet which component the problem is in yet (mesa, amdgpu, steamvr, or proton). Initial signs point to mesa since the functionality is pretty new, and a performance cap shows a ton of calls to clock_gettime from both the game and vrcompositor, indicating that there's a busy-wait somewhere that's chugging

On a side note - it looks like the semi-frequent interleaved reprojection dropoffs are not the fault of Proton or ACC, but rather SteamVR, mesa, or amdgpu, as the behavior is observable even in Valve's hellovr_vulkan demo. So that's.... news of some kind haha

Hello @mcoffin, please open an issue report on the SteamVR-for-Linux for the jittering you're seeing since that sounds like a new quirk.

@kisak-valve Will do. I'll do a good write-up later tonight, but i have it pretty narrowed-down. The "jittery" behavior began happening when mesa>=20.2.0 landed timeline syncobj support even on SteamVR 1.14.x, but only for the vrdashboard overlays (the one when you hit the system button on the index controllers... sorry if my terminology is off). After SteamVR>=1.15, this same behavior migrated to IVROverlay overlays from the game as well. I'll include that in the final writeup as well, but that's a pretty narrow version range to see what behavior from the system overlays was copied to the other ones in the 1.15 release, so I thought I'd mention it now before the full writeup in case you're already mucking about in there and could find the fix just from that narrow version range.

EDIT: actually, before I go telling the SteamVR guys that something is broken, let me throw a 2070S in my rig and test with the NVIDIA driver :vomiting_face: (if they have timeline syncobj support that is). If they do and it isn't busted, then the issue is most certainly with mesa or amdgpu itself. It'll be a PITA to set up since I've never had an NVIDIA card in this machine, but worth the time as a debugging step

Update: mesa version change appears to have been a poorly-timed red herring. With mesa-20.1.4 (from before the timeline syncobj changes), and SteamVR=1.15.2, the issue is still present.

Unfortunately, since Steam won't let you install arbitrary versions of SteamVR, I can't bisect this any further, so we'll have to just wait on the bug report :disappointed: .

EDIT: Ok, I just tested all premutations of old/new mesa and 1.15.2/1.14.16. I must have just had a SteamVR update one time when I didn't notice, and that's why I chased down the mesa path. The issue was 100% introduced in SteamVR 1.15, so this'll be the last update on this thread, though if you're running this game, you'll want to stay on 1.14.X. I'll file a bug report over on ValveSoftware/SteamVR-for-Linux.

@mcoffin thanks a lot for providing a compiled proton version. Yeah, I fully agree with distributing binaries is not the best idea, though I had wiped my Proton build environment a while ago and hadn’t found the time to set it up again :(

I got my Index now and having everything up and running, I gave your vrclient a try. Thanks to your additions I can enter the game/menu and sometimes even reach the actual game, but unfortunately at some point in the first few minutes the game freezes or SteamVR/vrcompositor crashes (stack trace points to the nvidia driver, dmesg says XID 13 which indicates an application error). Other apps I tried in SteamVR (eg Elite dangerous or DCS) do run just fine, so I don’t think that my setup is generally broken. I’ve tested with both SteamVR stable/beta, also the latest stable nvidia 450/455 drivers and a fresh prefix.
I don’t think that those crashes are related to your changes. I’ll dig further, but I already wanted to share what I’m seeing. Would be cool if another nvidia user could confirm (or hopefully deny) what I’m seeing.

@jp7677 I can try my GF's 2070 super at some point if I get around to setting it up with my rig (this box hasn't had NVIDIA drivers on it before, so there's a lot of reconfig I'd have to do.

If you post proton/dmesg/journalctl logs, I can take a look, though, and see if I think it's related.

What version of SteamVR are you on?

@mcoffin Yeah, no worries if you don't find the time. The vrcompositor crash is 100% reproducible here when starting ACC. I hope that your patch makes it into the next Proton release and then I can add a good issue report at SteamVR with an easy reproduction recipe. The only interesting bits I guess are these dmesg lines when vrcompositor crashes.

[11897.915514] NVRM: Xid (PCI:0000:02:00): 13, pid=617873408, Graphics Exception: Class 0x0 Subchannel 0x0 Mismatch
[11897.915517] NVRM: Xid (PCI:0000:02:00): 13, pid=617873408, Graphics Exception: ESR 0x4041b0=0x80000
[11897.915519] NVRM: Xid (PCI:0000:02:00): 13, pid=617873408, Graphics Exception: ESR 0x404000=0x80000002
[11897.915828] NVRM: Xid (PCI:0000:02:00): 13, pid=57164, Graphics Exception: ChID 0064, Class 0000c197, Offset 00000f80, Data 00000000

Proton log (including vrclient channel) or DXVK logs show nothing suspect. I'm seeing this with both Steam VR stable and beta. Switching between nvidia 450 or 455 driver versions made no difference either.

Edit: I've already created an issue at SteamVR (https://github.com/ValveSoftware/SteamVR-for-Linux/issues/397) and also send an e-mail to linux-bugs [at] nvidia.com referring to that issue.

Edit: moved to StemVR issue

@gotzl thanks a lot for confirming the crashes I’m seeing. Your sequence looks very similar if not the same. Sometimes it crashes here quite early in the ACC lobby, sometimes I’m able to start an actual game and I’m able so see a few frames in-game. I seem to remember seeing the message box you described once or twice, but most times the picture just freezes (though headtracking indeed still works until SteamVR wants to be restarted. Actually I’m not sure which process crashes first, or better which process causes the XIDs.
Could you also add your thoughts to the SteamVR issue since I linked that one in my email to linux-bugs at nvidia?

PS: Does apitrace works with VR? If we could generate a trace and it confirms the xids, it might be easier to track this down.

I tried to take an D3D11 apitrace. Taking a trace actually worked (including the crash), but replaying it works just fine without any XID's errors. That said, the replay shows only the desktop window, not what had been presented in the headset. The menu e.g. isn't visible in the trace, but I can at least briefly see the actual game (first few frames of a practice session in the car). Anyway, that trace is I guess completely useless.

@jp7677 I also did test it, I have similar hardware but an Arch system. Same conclusions from me. Sometimes it crashes in the lobby, but it will always crash when entering the game. The in-race crash looks very similar to what happens in Project Cars 2. Well, they use the same engine.

Hello. The stuttering found when playing online multiplayer in Assetto Corsa Competizione is hopefully fixed in the 5.13-1 release.

This weekend I will spend a lot of time testing and testing games.... ACC will be the first

Hello. The stuttering found when playing online multiplayer in Assetto Corsa Competizione is hopefully fixed in the 5.13-1 release.

Just a note for others here - there's still a stutter when a player joins a game that's using a custom livery that you have not seen in-game yet, but this stutter is observed on Windows as well, and a known issue with the way the game loads custom liveries. It has to completely pause it's rendering thread while it reads the textures and uploads them to VRAM, so that particular stutter (not the one that is fixed in 5.13-1), isn't proton/wine related. Just thought I'd clear that up in case someone comes in saying it's not fixed completely.

Someone could try VR with Proton 5.13-2RC ?

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

@leillo1975 I already did that :), see https://github.com/ValveSoftware/Proton/pull/4163#issuecomment-724238497
In short, VR is fixed for me on Nvidia with this upcoming Proton version!
(The nvidia driver still misses the requirements for async reprojection for a perfect experience, but that is unrelated to Proton)

Someone could try VR with Proton 5.13-2RC ?

@leillo1975 Can confirm the same result as @jp7677, VR is now working with Proton 5.13-2 RC3 and SteamVR 1.15.7

Many thanks again to @mcoffin for this contribution!

System Information

• GPU: RTX 2060
• Driver/LLVM version: NVIDIA 455.38
• Distro version: Ubuntu 20.04 LTS
• Link to full system information report as Gist
• Proton version: 5.13-2 RC3
• SteamVR version: 1.15.7

I confirm:

• [x] that pressing the Play button in the Steam client is sufficient.

Issues

• [x] I haven't experienced any issues.
• [x] There are no issues left open for this game.

Yep, works for me too now. Great work guys!