-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[partially solved] DCS World Beta with OpenXR not quite working yet #26
Comments
Last updated: 18th Oct 2023 I now got the standalone, non-steam DCS World Open Beta running with VR with OpenXR + Monado and an HP Reverb G2, without Steam and without OpenComposite, as follows:
Voila, you should now be able to start DCS.exe with VR enabled! If you run into problems of DCS.exe still starting without VR or even crashing, then you might want to set the following extra environment variables for useful debug information: In Lutris right-click on "DCS World Open Beta", select "Configure"->"System options"->"Environment variables" and add: Key: "WINEDEBUG", value: "+loaddll,+openxr". Which will give extra information if wineopenxr.dll is found and loaded fine and wher wineopenxr.dll might run into issues. And add: Key: "XR_LOADER_DEBUG", value: "all". Which gives extra debugging information with the "OpenXR-Loader" prefix from DCS.exe. The OpenXR-Loader source code can also be found here: https://github.com/KhronosGroup/OpenXR-SDK A hardware support table for Monado can be found here: https://monado.freedesktop.org/#supported-hardware. The instructions above should work fine for several "Windows Mixed Reality" based headsets, as well as several others. The SteamVR (beta?) now supposedly also supports OpenXR, but that will probably not work with WMR based headsets, as the WMR software currently does not run through Wine? |
Thank you for this very detailed info! Apologies if this isn't the right place for this, but this is a niche within a niche within a niche... I am using a Quest Pro headset, which is not supported by Monado, and must instead use ALVR and SteamVR for everything on Linux, due in part to having no displayport. So, using a modified version of the steps above, I'm finally able to get DCS to launch in VR and hook into the headset and begin visualization, but it only renders the first few frames then visually freezes, but the music continues playing. I get a SteamVR crash dump in /tmp/dumps but no hints as to what went wrong as far as I can discern. I think what is likely my problem is getting the correct list of Vulkan device and instance extensions. Not being able to use Monado, step 4.6 does not work for me, but I modified a python script from the python Vulkan API to produce the list of extensions. It is ultimately for an SDL2 example instance, so I'm not sure if the list of extensions is correct for the context of VR, and the number of device extensions is very large, possibly too many. Running hello_xr produces a list of extensions beginning in Interestingly, the Steam edition does launch and run in VR, but something is wrong with the tracking, causing a nauseating shaking during gameplay that can be momentarily stopped by repeatedly recentering the view. I tried looking into the wineprefix created by the Steam edition for hints on running standalone in VR, but the list of extensions is not saved in the registry. The above steps appear to be the most accurate and detailed available, and it seems we're very close to a general solution for running DCS in VR on Linux, which is exciting! |
Hi @KunstDerFuge. To get the Vulkan extensions with hello_xr you'll either need to run "hello_xr -g Vulkan2". "-g Vulkan" does not display the Vulkan extensions. For me this looks like this for example:
However this list is a merger of what the OpenXR runtime requests (in my case Monado) and what the hello_xr application itself requests. The patch I've added to hello_xr, linked in 4.6) helps to distinguish these two. Then you'll get the following output:
And I think what's listed in "requested by runtime" is what you'll need to add. I'm very curious what your ALVR+SteamVR runtime would list there. Would be great if you could paste that here. As far as I can tell your Python script does not use OpenXR and will therefore be missing the Vulkan extensions needed/requested by your OpenXR runtime. And this is the crucial part, as that's what DXVK is currently unable to figure out on its own. Your python script will only get the Vulkan extensions this specific python application wants. And DXVK will only be able to get the extensions this DXVK application needs. And the weird Wine/Proton registry hack is supposed to provide the OpenXR runtime specific extensions to DXVK. Next, all this should only be a subset of all the Vulkan extensions your hardware + software stack can provide. For me this is the long list that can be found here, for instance: https://vulkan.gpuinfo.org/displayreport.php?id=21610. You can find out your full list and optionally upload it to this public database via this application: https://github.com/SaschaWillems/VulkanCapsViewer Btw. ALVR provides an OpenXR runtime, right? Because the registry keys I mentioned are for OpenXR. I think OpenVR needs different registry keys.
If you get a crash core dump, it might be helpful if you could run "gdb " over it, and then type "bt" to maybe at least get a call trace. Hope all this helps. Otherwise feel free to join on the Matrix chat at https://matrix.to/#/#dcs-on-linux:matrix.org. |
Thank you again @T-X! I still can't get past this step, but it's starting to become more clear why. My hello_xr does not produce any log output that looks like this, even with the --verbose flag, but does seem to work otherwise including visualization in the headset. I am using the hello_xr provided by openxr version 1.0.27-1 on Manjaro. My log output looks like this:
I believe so. I assumed I was using OpenXR this whole time, and I'd definitely like to be if not, but actually it'd never occurred to me that I might not. Now that I look into it, I see .vrpath files in my steam folders. I'm not really sure how to check which one a specific application is using.
Ohh, so that's why DCS Steam Edition ran without making the expected keys in the registry... And maybe why it performed poorly. I will investigate the crash dumps with gdb, which should be insightful. |
That's why I mentioned that I had added a patch to hello_xr ;-). You'd need get the hello_xr sources, apply that patch linked under 4.6) and then recompile it. Hm, but strange that you don't see Vulkan extensions listed with the vanilla, unpatched "hello_xr --verbose -g Vulkan2". Does not seem to be there in the output you pasted. I'm using libopenxr-utils / openxr-sdk-source 1.0.20~dfsg1-1+b2 from Debian Sid.
For any application run through Steam, Steam will set up those registry keys. I think for both OpenVR and OpenXR. The instructions I had added are for the non-Steam, standalone version, in my case run through Lutris. Where I would have no Steam to setup the registry keys for me.
Add the environment variable XR_LOADER_DEBUG=all. Then DCS.exe should output some "OpenXR-Loader" messages on its console output. And some OpenVR mentions otherwise. On Steam you might need to add the PROTON_LOG variable to get the application's console output. See: https://github.com/ValveSoftware/Proton/wiki/Proton-FAQ#how-to-enable-proton-logs But if you are using the DCS Open Beta and have added "--force_enable_VR --force_OpenXR" to the DCS.exe as mentioned in 2.1) then in theory it should use OpenXR, I think. And according to your hello_xr output OpenXR seems to be available. Hm, maybe grepping through "~/.steam/steam/logs/" for "OpenVR" and "OpenXR" might reveal which one is used? |
Really strange, even compiled from your patched version, hello_xr outputs the same thing, never calling your |
Thanks for the thorough write-up, I was able to get DCS/2.9.4.53549 running with OpenXR support using Monado. However, with my specific configuration (Debian, Linux 6.7.9, nvidia-driver 535.161.08, Nvidia 3070 Ti and HP Reverb G2); monado-service at this point will continuously report an infinitely increasing frame delay. This is also reproducible with monado-service virtual HMD, so for now I'm assuming it's a problem with one or more of the following; Since you had it running, and I've seen from other posts the only difference is GPU hardware and drivers, I'm strongly suspecting a driver bug (or in conjunction with DXVK), and have also submitted a ticket to Nvidia customer support, and linking to this github issue. I also intend on raising an issue with DXVK once I figure out how to debug the issue deeper than wine and DXVK debug logs, which don't show anything more relevant than the aforementioned device lost errors. |
@jwshea thanks for the feedback! Two issues I'm sometimes having are the following, not quite sure if maybe one of them is the same or similar to yours?
This sounds like it might be the second case? You don't get anymore sensor updates (accel./gyro/cameras/...) in the monado-service GUI, while the GUI itself did not freeze? |
@T-X thanks for your reply.
I haven't tried SLAM yet, since basalt-for-monado fails to build on my system (Debian sid); what latest commit of basalt-for-monado have you been able to build? It could still be causing problems which lead to the driver crashing.
I'd also tried this, and it buys more time until the driver crash, enough to start an instant mission, but the driver seems to crash before all the textures have displayed, e.g. missing cockpit textures on right eye view
Perhaps the debian package version doesn't support the debug gui, what's the commit of monado you've built from? Note: I'm seeing GPU errors from the driver; Xid 13 (Graphics Engine Exception), and Xid 32 (Invalid or corrupted push buffer stream); with the latter being more likely to be a driver error than an application error. |
If you're talking about the version in the official Debian repositories: They're very outdated and Monado devs didn't seem interested in updating it. I'd highly recommend rebuilding from the source. The versions I've been using lately, for a while now:
Monado needs to be built with "cmake -DCMAKE_BUILD_TYPE=Debug .." to enable the debug GUI and then you should be able to use "XRT_DEBUG_GUI=1" with the monado-service.
Right, I also stumbled over this in recent builds. It's this issue, I guess? https://gitlab.freedesktop.org/mateosss/basalt/-/issues/10 Here are my full, verbose Monado build notes, including the diff I applied to Pangolin: |
Thanks again, I was able to get basalt to build, and SLAM working fine with hello_xr However it's looking more like an Nvidia driver bug now, journal logs for posterity:
dcs.log
|
tl;dr: Things will eventually move to OpenXR but OpenVR might work better for now. In theory DCS World Beta has OpenXR support. This ticket is to track progress of DCS World OpenXR support on Linux.
Summary / Overview "OpenVR vs. OpenXR"
For VR for DCS World there are in theory two APIs that can be used: OpenVR or OpenXR. And two different providers for these APIs: SteamVR or Monado.
Pros/Cons of OpenVR:
(+) stable in SteamVR, supported in there for a long time
(-) going to be deprecated in favour of OpenXR
(-) not natively supported by Monado, needs OpenOVR for translation (see below)
(-) Windows Mixed Reality based headsets won't work on SteamVR as is, need the SteamVR-Monado plugin (see below)
Pros/Cons of OpenXR
(+) new, modern standard, will replace OpenVR
(+) well supported on many Linux distribution via Monado
(-) unstable/experimental in SteamVR?
(-) hacks in Proton's OpenXR implementation for SteamVR, creating issues for Proton+Monado
Support Matrix SteamVR vs. Monado:
(1) Support in SteamVR for OpenXR is rather new and seems / might still be a bit buggy.
(2) There is OpenOVR to provide a translation layer from OpenVR to OpenXR, people have used it (sort of) successfully with DCS World here. Unfortunately OpenOVR is not part of many Linux distributions and will likely need manual build + installation.
(3) There is no OpenXR support in plain Wine, only Proton has OpenXR support. There are hacks in Proton's implementation for SteamVR support, which unfortunately breaks easy usage of OpenXR via Monado
(4) Another issue is that some headsets are not supported in SteamVR as is. This affects all headsets that were implemented through Windows Mixed Reality, which (afaik) does not run on Linux. This affects the HP Reverb G2 for instance. However there is the SteamVR-Monado plugin to work around this: https://monado.freedesktop.org/steamvr.html. Note that for the SteamVR-Monado plugin you will not run monado-service in the background though, monado-service is incompatible to SteamVR.
(5): For the Reverb G2 Monado as is only implements 3D movements, without 6D / inside-out / positional tracking. For that some work is done in Monado's Basalt fork, which needs to be built and installed manually: https://gitlab.freedesktop.org/mateosss/basalt#basalt-for-monado
Support Matrix for DCS World:
(6) To enable OpenXR in DCS World Beta the following arguments need to be added as noted in the DCS Forum here:
--force_enable_VR --force_OpenXR
. And Proton instead of Wine needs to be used, as noted in (3) above. However, this still results in the following error:Error [GENERAL | | OpenXR-Loader] : RuntimeManifestFile::FindManifestFiles - failed to find active runtime file in registry
With Monado installed and monado-service running fine on Debian Sid from the according Debian packages (and verified via "hello_xr" from the libopenxr-utils package that monado-service and my HP Reverb G2 mostly (except positional tracking) works). And Monado was configured as the user's OpenXR provider via this symlink:
Note: Monado should be used by default when installed, without needing to touch or create this symlink. However SteamVR might overwrite it. If the ~/.config/openxr/1/active_runtime.json symlink points to
~/.steam/debian-installation/steamapps/common/SteamVR/steamxr_linux64_patched.json
instead, then SteamVR will be the OpenXR provider instead.And the standalone, non-steam DCS World Beta is installed and run via Lutris, with the lutris-GE-proton7-39-x86_64 runner I get the following error message from Proton's OpenXR-Loader:
The issue seems to be that Proton's OpenXR implementation expects certain registry keys to be set: ValveSoftware/Proton#6038
The text was updated successfully, but these errors were encountered: