Open Meister1593 opened 1 year ago
The unity_beta branch launches fine on my system, albeit with wonky haptics, offsets, and bindings (which probably aren't Linux-specific issues):
In logs there is mentions of missing extension like
XR_KHR_D3D12_enable
That warning is superfluous, as Beat Saber will default to D3D11 unless the API is explicitly forced. Edit: It seems the unity_alpha branch defaulted to D3D12, but they switched back to D3D11 for unity_beta. For me, the game still loads with -force-d3d12
, but without VR support due to the aforementioned missing extension.
The stable branch also seems to be broken to add to this, it launches but not in VR or without detecting the headset and controllers. The beta just crashes like in the initial report.
Replying to https://github.com/ValveSoftware/Proton/issues/6638#issuecomment-1542829271
stable works for me mesa 23.0.3 kernel 6.2.11-300.fc38.x86_64 proton 8.0-2
Replying to https://github.com/ValveSoftware/Proton/issues/6638#issuecomment-1542829271
Same here, launches but doesn't output to the index hmd. Could be because of the recent OpenXR update?
RTX 3090 kernet 6.2.11 GEproton8.2 (tried experimental too)
Using the SteamVR beta causes the NVIDIA driver to hang temporarily and throw these error messages:
May 11 18:30:52 neptune kernel: NVRM: Xid (PCI:0000:06:00): 32, pid=52359, name=Beat Saber.exe, Channel ID 000000de intr0 00040000 May 11 18:30:52 neptune kernel: NVRM: Xid (PCI:0000:06:00): 32, pid=52359, name=Beat Saber.exe, Channel ID 000000de intr0 00040000 May 11 18:30:54 neptune kernel: nvidia-modeset: ERROR: GPU:0: Idling display engine timed out: 0x0000c67e:6:0:1060 May 11 18:30:56 neptune kernel: nvidia-modeset: ERROR: GPU:0: Idling display engine timed out: 0x0000c67e:6:0:1060 May 11 18:30:58 neptune kernel: nvidia-modeset: ERROR: GPU:0: Idling display engine timed out: 0x0000c67e:6:0:1060
In addition, SteamVR no longer outputs any game after this error occurs. Game is also stuck on a permanent black screen and never completely launches. This may be a Wayland-exclusive problem though.
RTX 3080 Mesa 23.0.3-1 Kernal 6.3.1-arch1-1 Proton Experimental
@Parapass
This may be a Wayland-exclusive problem though.
nope, i'm on xserver, also doesn't launch since the last engine update
as a temporary workaround, go to the game settings, beta versions, select legacy build, it would work. no idea how long the old build would stay there though
I think this has something to do with OpenXR, since the same error happens on BONELAB.
I'm having the same issue.
Graphics System: Xorg GPU: RTX 3090 GPU driver: nvidia proprietary driver 535.113.1.0 Kernal 6.5.6-zen2-1-zen Proton Experimental (8.0-104), older proton versions cause steam vr to crash on game start or the game gets stuck on a black frame.
I am consistently crashing on SteamVR beta 2.1.9, Proton experimental, and Beat Saber version legacy1.29.1. Downgrading to proton 8.0-4 fixes the issue. Just staying in the main menu doesn't crash, but navigating the menu or playing crashed within ~3 minutes.
I also have various mods installed.
This log entry gets spammed on the problematic proton version:
[CRITICAL @ 12:34:57 | UnityEngine] NullReferenceException: Object reference not set to an instance of an object
[CRITICAL @ 12:34:57 | UnityEngine] Valve.VR.CVRSystem.PollNextEvent (Valve.VR.VREvent_t& pEvent, System.UInt32 uncbVREvent) (at <5868de6629974f01886115908ff93cc2>:0)
[CRITICAL @ 12:34:57 | UnityEngine] OpenVRHelper.Update () (at <e01c36b4cfa8495b82e4c53668601dc2>:0)
After the crash, beatsaber crashes immediately after restarting, restarting steamvr just gets it back to crashing within 3 minutes.
Hello @RedlineTriad, please add PROTON_LOG=1 %command%
to the game's launch options, reproduce the crash, and attach the generated $HOME/steam-$APPID.log to this issue report as a file. (Proton logs compress well if needed.)
@kisak-valve I just changed the proton version to proton experimental, played for a few minutes, crashed, and this is the file: steam-620980.log.gz
So very reproducible for me.
@RedlineTriad Does this issue happen with the mods uninstalled that you mentioned?
@RedlineTriad For some reason I was seeing this crash while testing yesterday, and then it disappeared and now I can no longer recreate it on Experimental. Could you try experimental again, and if you are still seeing the crash could you capture a log of the crash by adding PROTON_LOG=+steam,+steamclient,+vrclient,+openxr %command% to the game launch options?
@RedlineTriad For some reason I was seeing this crash while testing yesterday, and then it disappeared and now I can no longer recreate it on Experimental. Could you try experimental again, and if you are still seeing the crash could you capture a log of the crash by adding PROTON_LOG=+steam,+steamclient,+vrclient,+openxr %command% to the game launch options?
Somebody check if heisenberg is still in his grave, I smell a heisenbug.
So I think the reason you aren't able to reproduce it anymore might be because you are playing with debug options.
@RedlineTriad You are partially correct - it did stop appearing when I enabled logging, but then after I turned logging off again it was still very hard to reproduce ...which is typical of a race condition of course 😭 Perhaps something was running in the background and changing my computer timing just enough.
It is unfortunate that you couldn't capture a log though. Since it seems to be happening more consistently for you than for us (now I've had someone else try on a third machine with similar results to me, although it took them even longer than me to get a crash) I was hopeful that even with logging you would be able to capture something. I will keep looking into this ... in the meantime - could you play with that logging enabled and maybe you will get lucky? Worst case, it just avoids the crashing and so the game will at least be playable :D
@alasky17
It is unfortunate that you couldn't capture a log though. Since it seems to be happening more consistently for you than for us
PROTON_LOG=1
seems to work while crashing (see above).
Can you link me some documentation of what makes this different?
PROTON_LOG=+steam,+steamclient,+vrclient,+openxr %command%
If so I could check how much I can enable and still get the crash.
Also, which of this might be the most important to collect.
@RedlineTriad Thank you for taking the time to dig into this. We've been making massive changes to lsteamclient and vr, so it seems relatively likely that this is a "real regression" rather than just a bug that was there all along (either in our code or game code) that we are just hitting more frequently now. PROTON_LOG=1 includes our general "default" logging channels ... I don't think there is any documentation on this, but if you look at the top of your log file created with the variable, you can see the "WINEDEBUG" line which will list all of the channels that are being set.
The easiest way to reduce the logging load is to use user_settings.py instead of PROTON_LOG. To do this: 1) Go to your Proton folder, for experimental would be ~/.steam/steam/steamapps/common/Proton - Experimental 2) cp user_settings.sample.py user_settings.py (Proton looks for the user_settings.py filename to exist in the Proton folder) 3) Edit this file to mess with the logging options.
In order to further attempt to confirm if this regression is coming from the suspected set of changes, I have a couple of builds that I think are "last good" and "first bad". If you have the time, it would be great if you could confirm this for me since you are producing the failure so much more consistently than I was during my testing. Could you test the two builds in this folder - https://www.codeweavers.com/xfer/alasky/beat-saber-crash/ (lock code is "saber") and see if either or both cause the crash? To test the builds easily: 1) Create ~/.steam/steam/compatibilitytools.d if you don't have a folder there already 2) Drop both build tarballs in that folder 3) Untar them 4) Reboot Steam 5) The builds will now show up in the dropdown menu of Proton builds to choose from for a game. You can get rid of them by removing the untarred build folders and rebooting Steam again.
@alasky17 Sorry for the long wait, life got a bit busy. Decided to bisect your two builds first:
Command: None
Version: experimental-bleeding-edge-8.0-63848-20231116-pb35cd1-w61198d-dd998de-v7b2ea8
Command: None
Version: experimental-bleeding-edge-8.0-63895-20231116-p5d3865-w61198d-dd998de-v5deb87
Attempt No. | Setup | Playtime | Crash | Comment |
---|---|---|---|---|
1. | A | 5m | No | |
2. | B | 1m | Yes | |
Steam VR Restart | ||||
3. | A | 4m | No | |
4. | A? | 6m | No | Thought I already changed version, and never closed window so not sure if applied. |
5. | A | 4m | No | Closed property window and tried again |
6. | B | 2m | Yes |
Will try the different logging stuff when I have time, if you want me to bisect more version feel free to link them. Though if possible in order so I can start with failing ones (it's faster to test those) or binary search.
@RedlineTriad Thank you! This confirms that the commit series I suspected is indeed the likely culprit here. Unfortunately, it is a cluster of changes that is particularly nasty to bisect within. Maybe you will get lucky and manage to catch a log of the crash -- I think that is likely to be a lot more productive than an attempted bisect where many of the commits won't build or won't launch the game (which is what happened when I tried to bisect some earlier portion of this work :/) .
@alasky17 Here the proton logs with as many of the 4 options as I could get using Proton Experimental: steam-620980.log.gz This was made using the following options:
user_settings = {
"PROTON_LOG": "1",
"WINEDEBUG": "+steam,+steamclient,+openxr",
}
Adding +vrclient
made it not crash anymore, so I had to remove it.
Also, since it runs into the crash handler at the end you might need to ignore that part of the logs, decided to let it crash completely without doing anything myself to taint the data as little as possible.
Hope this helps, and I am available if any further testing is needed.
Hi @RedlineTriad, I added a change to the "bleeding-edge" beta branch of Proton Experimental, trying to fix the crash (though we weren't able to reproduce it). Would you mind testing if it helps?
Hi @RedlineTriad, I added a change to the "bleeding-edge" beta branch of Proton Experimental, trying to fix the crash (though we weren't able to reproduce it). Would you mind testing if it helps?
Testing 2 times with bleeding-edge branch and proton experimental and no crash, once with "stable" proton experimental and crashed.
Thanks for fixing this!
Could you link the fix? Super curious what caused such a weird failure mode.
Fix is https://github.com/ValveSoftware/Proton/commit/cdd2db6da2e16120d4bdefce37d3d7b5da1026aa, the issue is probably that we were not respecting the provided event struct length anymore and were copying the entire even structure, even if the client had allocated a smaller one. Not completely sure why it didn't cause consistent crashes.
Is there any update to this? I want to try the fix and see if it solves the issue on my system. Running NixOS 24.05 with Nvidia on KDE Plasma 6.0.2+Wayland
@NovaViper The fix mentioned above shipped with Proton 9.0. However, in recent testing the game had issues with the legacy branch after an update to the legacy branch. I'm not sure if you would run into those issues, so you are welcome to try the game yourself and see. I would recommend trying the legacy branch of the game.
@alasky17 I actually can run the legacy branch of the game (1.29.1, the pre-unity version). The version I can't run is the all of the 1.30 builds and beyond; since those feature the unity engine change. I tried several different Proton versions and none of them seem to fix the instant crashing issue I'm experiencing. The only version that works is the legacy 1.29.1 version of the game.
Alright, with the new Proton Experimental, the legacy branch is no longer needed :)
However, with my Valve Index the right eye seems to be rendered too far left, because of that Beat Saber is unplayable. This only happens in Beat Saber.
@bblacher Hello! Can you get an output of your system information and upload it please? You can find it in Help -> System Information in Steam. You can copy paste the output, save it as a file and upload it here.
Additionally, can you grab a log of the issue? You can add a launch option to the game to create a log. Open up the Properties of the game, and under Launch options add PROTON_LOG=+steam,+vrclient,+openxr,+vulkan,+win,+x11drv %command%
please. It will create a log file in your home directory. Please upload that log file here.
Are you opening the game via Steam, or within a SteamVR environment?
Sure!
Here is my system information.
Here is a log of the issue with the requested options. - this is using the current Beat Saber version (v1.36.2)
I am opening the game from within SteamVR home as I've found launching from Steam Desktop unreliable in the past. (Not only with Beat Saber, with many VR games, but that's another issue :))
Thank you so much for your work on Proton, it really makes gaming on Linux a delight :) @AJuujarvi
@bblacher I should have asked before asking for a log, is the eye funkiness specifically with Beat Saber current, or with the legacy1.29.1_unity_ver2019.4.28f1 Beta Branch? Or both? And which one is the log from?
The issue only appears on Beat Saber current (v1.36.2 as of writing), when downgrading to legacy1.29.1_unity_ver2019.4.28f1, the issue disappears. The log appended to my previous comment is from Beat Saber current, I've edited my comment to reflect that.
Here is a log from the legacy branch, I don't know if this will be helpful in any way but it won't hurt to have it posted as well. :)
Also, something I noticed when launching the current version of the game is that the issue only appears when the loading of the main menu is complete. The first "splash screen" that says "Beat Saber" "Oculus Games" and something else is rendered correctly.
I got the same (or similar) issue: left eye seems to be working fine but right eye looks kind of "warped" and misplaced. I'm running the "regular" Beat Saber version 1.36.2 with Proton Experimental. Logfile using the options: steam-620980.log
My issue was fixed today with this version update of Proton Experimental: https://github.com/ValveSoftware/Proton/wiki/Changelog/_compare/ff410f560fa87dab971889b644418b7285892dc7...496e06506f90187cc788c7f80dc1dd3bde82fe9f
I got the same (or similar) issue: left eye seems to be working fine but right eye looks kind of "warped" and misplaced. I'm running the "regular" Beat Saber version 1.36.2 with Proton Experimental. Logfile using the options: steam-620980.log
I'm using a very similar setup with more or less the same issue as you. I did some more testing and it seems that the right eye can handle positional displacement just fine, but rotational movement is wildly skewed, and really hurts my eye and I rotate around. This is with my left eye closed.
For me the issue reappeared with Beatsaber version 1.37.1 (I'm using Proton Experimental) on Beta version "1.34.2_legacy" it still works fine
The right eye warp issue seems to come and go away at random. When it happens it can persist for hours even with restarts of the desktop or the computer or changing the settings, and sometimes changing the render resolution per eye and restarting SteamVR can make it go away (as happened in today's debugging of the issue on my end). It does happen with Beat Saber versions that used to retroactively work fine.
I can't pin point the exact version of SteamVR when this started breaking, however I can tell this only affects Beat Saber in particular. Other games such as VRChat seem to render fine.
Someone explained to me the theory that this may actually be some correction built into SteamVR that is supposed to know when a game is projecting VR in a specific way, and sometimes it may fail to trigger now? Not sure how much weight there is to that.
Compatibility Report
System Information
I confirm:
steam-620980.log
Symptoms
Can't launch it on newest version that uses OpenXR instead of OpenVR. It shows logo for a split second and closes.
Bonelab on latest beta (openxr powered game) under proton works fine.
Reproduction
Always.
Additional notes
In logs there is mentions of missing extension like
XR_KHR_D3D12_enable
, which is not implemented by Proton at the moment, which is probably the reason it can't start. Tried to run with-force-vulkan
but it crashes with InitialiseGraphicsEngine error (probably wasn't built with vulkan support)