TheZoq2 / dcs_on_linux

Instructions for running DCS World on linux. Mostly extracted from https://github.com/ValveSoftware/Proton/issues/1722
77 stars 4 forks source link

[partially solved] DCS World Beta with OpenXR not quite working yet #26

Open T-X opened 1 year ago

T-X commented 1 year ago

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:

OpenVR OpenXR
SteamVR (4) yes yes (1)
Monado (5) no (2) yes (3)

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

DCS World Stable DCS World Beta
OpenVR yes yes
OpenXR no yes (6)

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

$ ln -s /usr/share/openxr/1/openxr_monado.json ~/.config/openxr/1/active_runtime.json
$ cat ~/.config/openxr/1/active_runtime.json
{
    "file_format_version": "1.0.0",
    "runtime": {
        "library_path": "../../../lib/libopenxr_monado.so"
    }
}

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:

...
Error [GENERAL |  | OpenXR-Loader] : RuntimeManifestFile::FindManifestFiles - failed to find active runtime file in registry
Error [GENERAL | xrEnumerateInstanceExtensionProperties | OpenXR-Loader] : RuntimeInterface::LoadRuntimes - unknown error
Error [GENERAL | xrEnumerateInstanceExtensionProperties | OpenXR-Loader] : RuntimeInterface::LoadRuntimes - failed to load a runtime
Error [GENERAL | xrEnumerateInstanceExtensionProperties | OpenXR-Loader] : Failed to find default runtime with RuntimeInterface::LoadRuntime()
Error [GENERAL | xrEnumerateInstanceExtensionProperties | OpenXR-Loader] : Failed querying extension properties
Error [GENERAL |  | OpenXR-Loader] : RuntimeManifestFile::FindManifestFiles - failed to find active runtime file in registry
Error [GENERAL | xrEnumerateInstanceExtensionProperties | OpenXR-Loader] : RuntimeInterface::LoadRuntimes - unknown error
Error [GENERAL | xrEnumerateInstanceExtensionProperties | OpenXR-Loader] : RuntimeInterface::LoadRuntimes - failed to load a runtime
Error [GENERAL | xrEnumerateInstanceExtensionProperties | OpenXR-Loader] : Failed to find default runtime with RuntimeInterface::LoadRuntime()
Error [GENERAL | xrEnumerateInstanceExtensionProperties | OpenXR-Loader] : Failed querying extension properties
...

The issue seems to be that Proton's OpenXR implementation expects certain registry keys to be set: https://github.com/ValveSoftware/Proton/issues/6038

T-X commented 1 year ago

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:

0) Connect your VR headset. 1) Monado setup 1.1) Install Monado. Debian had working, precompiled packages for me -> $ apt-get update && apt-get install monado-service monado-cli monado-gui . Otherwise you can find the source-code and instructions here: https://gitlab.freedesktop.org/monado/monado 1.2) Start "monado-service" on a terminal. Ideally with "$ XRT_LOG=debug IPC_LOG=info monado-service", to be able to see when an OpenXR application connects to or disconnects from it. (later, when everything works and if you use systemd then you can just have it enabled on demand by via systemd socket activation, by enabling "$ systemctl --user start monado.socket") 1.2) Test a minimal OpenXR application on Linux, check Monado's debug output to verify that it is used (and not SteamVR's OpenXR implementation). Recommendation: hello_xr from the "libopenxr-utils" package on Debian, or its source code can be found here: https://github.com/KhronosGroup/OpenXR-SDK-Source 1.3) Note 1: For the Reverb G2 not everything is implemented and still WIP in Monado yet. No hand controller support yet and only 3DoF head tracking no 6DoF positional tracking yet (needs installation + recompilation with Monado-Basalt for the camera assisted "inside-out" position tracking - but skipping this it's not strictly necessary for first VR experiences with DCS World) 1.4) Note 2: SteamVR might try to take authority of being the default OpenXR runtime. If that happens to you, you can reconfigure this by creating or updating the symlink in ~/.config/openxr/1/active_runtime.json to point to "/usr/share/openxr/1/openxr_monado.json", which should be provided by libopenxr1-monado. Or an OpenXR application can set the environment variable "XR_RUNTIME_JSON" which has a higher priority than this symlink. 2) Install DCS World Open Beta via the Lutris installer script "Standalone Open Beta version" from here: https://lutris.net/games/dcs-world/ 2.1) Either change to the multithreaded version, which prioritizes OpenXR over OpenVR at the moment (while single-threaded prioritizes OpenVR over OpenXR): In Lutris right-click on "DCS World Open Beta" -> "Configure" -> "Game options" -> Executable, then select "~/Games/dcs-world-open-beta/drive_c/Program Files/Eagle Dynamics/DCS World OpenBeta/bin-mt/DCS.exe". Or for the single-threaded version add: "--force_enable_VR --force_OpenXR" to "Game options" -> Arguments. 3) Download & Install the Wine "Glorious Eggroll" version (a protonified Wine version + some extra patches): 3.1) Download wine-lutris-GE-Proton7-43-x86_64.tar.xz from here: https://github.com/GloriousEggroll/wine-ge-custom/releases/tag/GE-Proton7-43 3.2) Unpack it to ~/.local/share/lutris/runners/wine/lutris-GE-Proton7-43-x86_64/ 3.3) In Lutris, right-click on your installed "DCS World Open Beta" and go to "Configure"->"Runner options"->"Wine version". A new option with "lutris-GE-Proton7-43-x86_64" should be available. Select it. 4) Check if DCS tries to use OpenXR: The console output of DCS.exe should show multiple lines like "Warning [GENERAL | | OpenXR-Loader] ..." - but won't be able to use it yet. And check that DCS works fine without VR. 5) Download and install Wineopenxr: 5.1) Download Proton-GE with a matching version, for instance "GE-Proton7-43.tar.gz " from here: https://github.com/GloriousEggroll/proton-ge-custom/releases/tag/GE-Proton7-43 5.2) Unpack it (if you use Steam, too, you can also unpack it to ~/.steam/steam/compatibilitytools.d/, if you want to be able to use this Proton version in Steam as well) 5.3) Create the directory openxr in ~/Games/dcs-world-open-beta/drive_c/ 5.4) Copy ./GE-Proton7-43/files/share/default_pfx/drive_c/openxr/wineopenxr64.json to ~/Games/dcs-world-open-beta/drive_c/openxr/wineopenxr64.json 5.5) Copy ./GE-Proton7-43/files/lib64/wine/x86_64-unix/wineopenxr.dll.so to ~/Games/dcs-world-open-beta/drive_c/windows/system32/wineopenxr.dll (note: use the Linux ELF file from "...x86_64-unix/wineopenxr.dll.so", "...x86_64-windows/wineopenxr.dll" did not work for me). 5.6) Find the Vulkan instance and device extensions which the OpenXR runtime, in our case Monado, needs: Start "$ hello_xr -v -g Vulkan2" and write down the extensions you see below "LOG in xrCreateVulkanInstanceKHR: Creation of VkInstance:" and "LOG in xrGetVulkanGraphicsDeviceKHR: Creation of VkDevice:" They start with either "VKKHR" or "VKEXT". (My current understanding is that these would be both the extensions requested by the XR runtime and by the hello_xr application itself and potentially more than necessary. The extensions listed after this patch under "requested by runtime" might be more correct? 5.6.1) Warning: These extensions are operating system / software + hardware specific, so the lazy approach of just copying these values from someone else is very likely incorrect! 5.7) Open the Wine registry in Lutris by selecting "DCS World Open Beta" and then at the bottom clicking on the triangle next to the wine glass, then selecting "Wine registry". Navigate to HKEY_CURRENT_USER\\Software\\Wine\\" and create a new key "VR". 5.8) InHKEY_CURRENT_USER\Software\Wine\VRcreate a new "DWORD Value" named "state". Set it to 1. 5.9) InHKEY_CURRENT_USER\Software\Wine\VRcreate a new "String Value" named "openxr_vulkan_instance_extensions". Set to the Vulkan instance extensions found in 4.6, separated by spaces. 5.10) InHKEY_CURRENT_USER\Software\Wine\VR` create a new "String Value" named "openxr_vulkan_device_extensions". Set to the Vulkan device extensions found in 4.6, separated by spaces. 5.11) Close the wine registry

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?

KunstDerFuge commented 1 year ago

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 helloxr produces a list of extensions beginning in `XR, notVK_`, so appears to be using a different API.

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!

T-X commented 1 year ago

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:

$ hello_xr -g Vulkan2
...
LOG in xrCreateVulkanInstanceKHR: Creation of VkInstance:
    result: VK_SUCCESS
    vulkanInstance: 0x5589194c1980
    extensions:
        VK_KHR_external_fence_capabilities
        VK_KHR_external_memory_capabilities
        VK_KHR_external_semaphore_capabilities
        VK_KHR_get_physical_device_properties2
        VK_EXT_debug_report
...
LOG in xrGetVulkanGraphicsDeviceKHR: Creation of VkDevice:
    result: VK_SUCCESS
    vulkanDevice: 0x56344dbcde10
    vulkanInstance: 0x56344d891980
    external_fence_fd: true
    external_semaphore_fd: true
    timelineSemaphore: true
    extensions:
        VK_KHR_dedicated_allocation
        VK_KHR_external_fence
        VK_KHR_external_memory
        VK_KHR_external_semaphore
        VK_KHR_get_memory_requirements2
        VK_KHR_external_memory_fd
        VK_KHR_external_semaphore_fd
        VK_KHR_external_fence_fd
        VK_KHR_image_format_list
        VK_KHR_timeline_semaphore
...

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:

$ hello_xr --verbose -g Vulkan
...
[x][Verbose] Vulkan Interface Extensions, requested by runtime: (4) 
[x][Verbose]    Name=VK_KHR_external_fence_capabilities
[x][Verbose]    Name=VK_KHR_external_memory_capabilities
[x][Verbose]    Name=VK_KHR_external_semaphore_capabilities
[x][Verbose]    Name=VK_KHR_get_physical_device_properties2
[x][Verbose] Vulkan Interface Extensions, requested by application: (1) 
[x][Verbose]    Name=VK_EXT_debug_utils
...
[x][Verbose] Vulkan Device Extensions, requested by runtime: (8) 
[x][Verbose]    Name=VK_KHR_dedicated_allocation
[x][Verbose]    Name=VK_KHR_external_fence
[x][Verbose]    Name=VK_KHR_external_memory
[x][Verbose]    Name=VK_KHR_external_semaphore
[x][Verbose]    Name=VK_KHR_get_memory_requirements2
[x][Verbose]    Name=VK_KHR_external_memory_fd
[x][Verbose]    Name=VK_KHR_external_semaphore_fd
[x][Verbose]    Name=VK_KHR_external_fence_fd
[x][Verbose] Vulkan Device Extensions, requested by application: (0)
...

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.


I get a SteamVR crash dump in /tmp/dumps but no hints as to what went wrong as far as I can discern.

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.

KunstDerFuge commented 1 year ago

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:

$ hello_xr --verbose -g Vulkan2

[05:54:01.186][Info   ] Press any key to shutdown...
[05:54:01.188][Verbose] Available Extensions: (20)
[05:54:01.188][Verbose]   Name=XR_KHR_vulkan_enable SpecVersion=8
[05:54:01.188][Verbose]   Name=XR_KHR_vulkan_enable2 SpecVersion=2
[05:54:01.188][Verbose]   Name=XR_KHR_opengl_enable SpecVersion=10
[05:54:01.188][Verbose]   Name=XR_KHR_binding_modification SpecVersion=1
[05:54:01.188][Verbose]   Name=XR_KHR_composition_layer_depth SpecVersion=6
[05:54:01.188][Verbose]   Name=XR_KHR_visibility_mask SpecVersion=2
[05:54:01.188][Verbose]   Name=XR_EXT_active_action_set_priority SpecVersion=1
[05:54:01.188][Verbose]   Name=XR_EXT_dpad_binding SpecVersion=1
[05:54:01.188][Verbose]   Name=XR_EXT_frame_composition_report SpecVersion=4
[05:54:01.188][Verbose]   Name=XR_EXT_hand_tracking SpecVersion=4
[05:54:01.188][Verbose]   Name=XR_EXT_hand_joints_motion_range SpecVersion=1
[05:54:01.188][Verbose]   Name=XR_EXT_hp_mixed_reality_controller SpecVersion=1
[05:54:01.188][Verbose]   Name=XR_EXT_palm_pose SpecVersion=2
[05:54:01.188][Verbose]   Name=XR_FB_display_refresh_rate SpecVersion=1
[05:54:01.188][Verbose]   Name=XR_HTC_vive_cosmos_controller_interaction SpecVersion=1
[05:54:01.188][Verbose]   Name=XR_HTC_vive_focus3_controller_interaction SpecVersion=2
[05:54:01.188][Verbose]   Name=XR_MND_headless SpecVersion=2
[05:54:01.188][Verbose]   Name=XR_VALVE_analog_threshold SpecVersion=2
[05:54:01.188][Verbose]   Name=XR_HTCX_vive_tracker_interaction SpecVersion=2
[05:54:01.188][Verbose]   Name=XR_EXT_debug_utils SpecVersion=4
[05:54:01.188][Info   ] Available Layers: (2)
[05:54:01.188][Verbose]   Name=XR_APILAYER_LUNARG_api_dump SpecVersion=1.0.0 LayerVersion=1 Description=API Layer to record api calls as they occur
[05:54:01.188][Verbose]     Available Extensions: (0)
[05:54:01.188][Verbose]   Name=XR_APILAYER_LUNARG_core_validation SpecVersion=1.0.0 LayerVersion=1 Description=API Layer to perform validation of api calls and parameters as they occur
[05:54:01.188][Verbose]     Available Extensions: (0)
[05:54:01.205][Info   ] Instance RuntimeName=SteamVR/OpenXR RuntimeVersion=0.1.0
[05:54:01.205][Verbose] Using system 558 for form factor XR_FORM_FACTOR_HEAD_MOUNTED_DISPLAY
[05:54:01.205][Info   ] Available View Configuration Types: (1)
[05:54:01.205][Verbose]   View Configuration Type: XR_VIEW_CONFIGURATION_TYPE_PRIMARY_STEREO (Selected)
[05:54:01.205][Verbose]   View configuration FovMutable=True
[05:54:01.205][Verbose]     View [0]: Recommended Width=3944 Height=4292 SampleCount=1
[05:54:01.205][Verbose]     View [0]:     Maximum Width=8192 Height=8192 SampleCount=1
[05:54:01.205][Verbose]     View [1]: Recommended Width=3944 Height=4292 SampleCount=1
[05:54:01.205][Verbose]     View [1]:     Maximum Width=8192 Height=8192 SampleCount=1
[05:54:01.205][Info   ] Available Environment Blend Mode count : (1)
[05:54:01.205][Info   ] Environment Blend Mode (XR_ENVIRONMENT_BLEND_MODE_OPAQUE) : (Selected)
[05:54:01.272][Info   ] Loaded vertex shader
[05:54:01.272][Info   ] Loaded fragment shader
[05:54:01.272][Verbose] Creating session...
[05:54:01.846][Info   ] Available reference spaces: 3
[05:54:01.846][Verbose]   Name: XR_REFERENCE_SPACE_TYPE_VIEW
[05:54:01.846][Verbose]   Name: XR_REFERENCE_SPACE_TYPE_LOCAL
[05:54:01.846][Verbose]   Name: XR_REFERENCE_SPACE_TYPE_STAGE
[05:54:01.850][Info   ] System Properties: Name=SteamVR/OpenXR : alvr_server VendorId=10462
[05:54:01.850][Info   ] System Graphics Properties: MaxWidth=3944 MaxHeight=4292 MaxLayers=16
[05:54:01.850][Info   ] System Tracking Properties: OrientationTracking=True PositionTracking=True
[05:54:01.850][Verbose] Swapchain Formats:  [43] 50 109 106 97 126 124 129 130
[05:54:01.850][Info   ] Creating swapchain for view 0 with dimensions Width=3944 Height=4292 SampleCount=1
[05:54:01.852][Info   ] Creating swapchain for view 1 with dimensions Width=3944 Height=4292 SampleCount=1
[05:54:01.853][Info   ] XrEventDataSessionStateChanged: state XR_SESSION_STATE_UNKNOWN->XR_SESSION_STATE_IDLE session=94771179227504 time=37000622593558
[05:54:01.853][Info   ] XrEventDataSessionStateChanged: state XR_SESSION_STATE_IDLE->XR_SESSION_STATE_READY session=94771179227504 time=37000622603873
[05:54:01.929][Info   ] XrEventDataSessionStateChanged: state XR_SESSION_STATE_READY->XR_SESSION_STATE_SYNCHRONIZED session=94771179227504 time=37000705773218
[05:54:01.929][Info   ] XrEventDataSessionStateChanged: state XR_SESSION_STATE_SYNCHRONIZED->XR_SESSION_STATE_VISIBLE session=94771179227504 time=37000705777499
[05:54:01.929][Info   ] XrEventDataSessionStateChanged: state XR_SESSION_STATE_VISIBLE->XR_SESSION_STATE_FOCUSED session=94771179227504 time=37000705782348
[05:54:01.937][Info   ] Grab action is bound to nothing
[05:54:01.937][Info   ] Quit action is bound to nothing
[05:54:01.937][Info   ] Pose action is bound to nothing
[05:54:01.937][Info   ] Vibrate action is bound to nothing

Btw. ALVR provides an OpenXR runtime, right?

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.

I think OpenVR needs different registry keys.

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.

T-X commented 1 year ago

My hello_xr does not produce any log output that looks like this, even with the --verbose flag

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.

Ohh, so that's why DCS Steam Edition ran without making the expected keys in the registry... And maybe why it performed poorly.

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.

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.

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?

KunstDerFuge commented 1 year ago

Really strange, even compiled from your patched version, hello_xr outputs the same thing, never calling your LogVulkanExtensions() which seems to imply that Vulkan is never initiated? Is it possible I'm falling back on some other renderer for some reason? Sorry for the lack of progress, I am pretty much totally lost at sea here...

jwshea commented 2 months ago

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

Thanks for the thorough write-up, I was able to get DCS/2.9.4.53549 running with OpenXR support using Monado. Using both bottles (with a few caveats to accommodate flatpak sandbox), and Lutris (using wine-lutris-GE-Proton8-26-x86_64 runner and DXVK 2.3)

However, with my specific configuration (Debian, Linux 6.7.9, nvidia-driver 535.161.08, Nvidia 3070 Ti and HP Reverb G2); DCS will typically freeze within the main menu (inside the hanger) usually within a few seconds, and the furthest I've been able to progress is loading an instant mission and freezing before being able to interact with the briefing menu.

monado-service at this point will continuously report an infinitely increasing frame delay. wine debug logs will often (but not always) contain "DxvkSubmissionQueue: Command submission failed: VK_ERROR_DEVICE_LOST" dcs.log will only sometimes contain a corresponding "DX device lost. Reason: 0x887A0007"

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; Nvidia driver, DXVK, or Proton's wineopenxr.dll

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.

T-X commented 2 months ago

@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? 1) Sometimes the SLAM / inside-out-camera tracking is thrown off. Especially when I have the Reverb G2 close to surfaces, for instance when just placing it directly on the table, especially with other stuff on the table, or when getting close to walls. In old Monado versions it used to throw "numeric errors" in the debug output and would then crash with a SIGABRT. In recent versions it's not crashing anymore, but instead the view would then just keep running away for me: https://gitlab.freedesktop.org/monado/monado/-/issues/256 2) On DCS startup after a few seconds into the loading screen Monado's USB communication with the Reverb G2 would freeze, especially on a PC with a CPU with only a few, slow cores. When using the monado-service debug GUI the values would not change anymore and the camera feeds were frozen. It seems that on heavy load the USB communication timing might get out-of-sync and Monado has not yet implemented any USB reset routines. What helped for me to fix this: Set CAP_SYS_NICE on the monado-service binary as described here: https://monado.freedesktop.org/valve-index-setup.html#1-initial-setup. $ sudo setcap CAP_SYS_NICE=eip /usr/bin/monado-service Then monado-service would try to increase the priority of some of its child processes automatically. But I also had to manually increase the priority to fully workaround this freeze. For instance I'm starting monado-service like this to decrease it's nice / increase it's priority by ten: $ sudo -E sh -c "nice -n -10 su -c \"XRT_DEBUG_GUI=1 XRT_COMPOSITOR_COMPUTE=1 ~/.local/bin/monado-service\" user "

monado-service at this point will continuously report an infinitely increasing frame delay.

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?

jwshea commented 2 months ago

@T-X thanks for your reply.

  1. Sometimes the SLAM / inside-out-camera tracking is thrown off.

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.

  1. <...> What helped for me to fix this: Set CAP_SYS_NICE on the monado-service binary <...>

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

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?

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.

T-X commented 2 months ago

@jwshea

Perhaps the debian package version doesn't support the debug gui, what's the commit of monado you've built from?

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.

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?

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: https://gist.github.com/T-X/83e2e16b6e07ac759c6bb85352ec083f

jwshea commented 2 months ago

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:

debian kernel: NVRM: Xid (PCI:0000:01:00): 32, pid=21416, name=Main, Channel ID 0000005e intr0 00040000
debian kernel: NVRM: Xid (PCI:0000:01:00): 32, pid=21416, name=Main, Channel ID 0000005e intr0 00040000
debian net.lutris.Lutris.desktop[16144]: ERROR [vk_cmd_submit_locked] vkQueueSubmit: VK_ERROR_DEVICE_LOST
debian net.lutris.Lutris.desktop[16144]: ERROR [vk_cmd_pool_submit_cmd_buffer_locked] vk_cmd_submit_locked: VK_ERROR_DEVICE_LOST
debian net.lutris.Lutris.desktop[16144]: ERROR [submit_image_barrier] vk_cmd_pool_submit_cmd_buffer: VK_ERROR_DEVICE_LOST 4294967292
debian net.lutris.Lutris.desktop[16144]: XR_ERROR_RUNTIME_FAILURE in xrReleaseSwapchainImage: Call to xrt_swapchain_barrier_image failed
debian /usr/libexec/gdm-x-session[2021]: (WW) NVIDIA: Wait for channel idle timed out.

dcs.log

INFO    LUA (Main): Lua: States: 653, CPU load: 39.4%, Mem: 342.9 MB
ERROR   DX11BACKEND (472): DX device lost. Reason: 0x887A0007
WARNING LOG (316): 1018 duplicate message(s) skipped.
ERROR   VISUALIZER (472): OpenXR failure XrResult failure [XR_ERROR_RUNTIME_FAILURE]
    Origin: xrReleaseSwapchainImage(handle, &releaseInfo) 
    Source: Projects\Visualizer\Source\OpenXR\openxr_program.cpp:1101
ERROR   VISUALIZER (472): std exception: XrResult failure [XR_ERROR_RUNTIME_FAILURE]
    Origin: xrReleaseSwapchainImage(handle, &releaseInfo) 
    Source: Projects\Visualizer\Source\OpenXR\openxr_program.cpp:1101