Hello from VDXR, OpenXR-Vk-D3D12 developer

[mbucchia-msft]

Hi!

I'm the author of all three of the software you listed here:

Can you tell me a little bit more about the issues you've been having?

In particular, 32-bit support in VDXR isn't really well tested (there are so few OpenXR 32-bit apps out there). Could you provide a log file, or even better, a capture?

%ProgramData%\Virtual Desktop\OpenXR.log

https://github.com/mbucchia/VirtualDesktop-OpenXR/wiki/Capturing-debug-traces

Thanks!

[Detegr]

Hi, thanks for reaching out. Thanks for your awesome projects too!

Some background: when I started this project a couple of months back I had no prior experience in implementing anything VR related, nor do I have real experience with Vulkan or modern graphics APIs either, but here I am trying to figure stuff out to my best abilities.

This project is a VR modification to a game that's originally running DirectX 9. It's using DXVK to run it on Vulkan, which in turn allows using VR runtimes as they're compatible with Vulkan's textures.

Recently I implemented OpenXR support for this project. It is done by copying a VkImage rendered by DXVK to the VkImage that OpenXR runtime provides. To do this I've essentially cloned the DXVK implementation of DirectX's StretchRect call in a way that it supports copying to VkImage directly. This is point number one that might have horrible bugs because of me not understanding all complications correctly.

On my Pimax 5K+ Pimax-OpenXR has been working flawlessly, I've had no issues at all.

The users of this project that have Reverb headsets and are using WMR's OpenXR via OpenXR-Vk-D3D12, there is a point in time where an extra flush of the GPU pipeline is needed. I've tried to understand why, but haven't been able to. The point in question is here, just before the copy of the rendered image to the swapchain image. Without this flush, the game will just crash on startup without ever drawing anything. The code for Flush is here. This is no big issue as the extra flush does not cost that much of performance. My hunch is that it would have something to do with the synchronization with the D3D12 pipeline, although what I've understood from your code is that the synchronization done in xrEndFrame should be enough. Pimax and Oculus headsets seem to work without this extra flush.

VDXR+VirtualDesktop fails very early. The call to xrCreateSwapchain fails with error code -7000. I did find this that sounded similar, where you've commented about a flag not being honored. Maybe this is a similar issue?

[Detegr]

Tagging @dancek. Would you like to capture a debug trace of VDXR+VirtualDesktop use case? I don't have Oculus headset.

[dancek]

Hi @mbucchia-msft, great to see you here! I really appreciate your work and I'm a happy VDXR user. I've been trying to debug this issue for some time now, while the OpenXR implementation was still unreleased. But I'm new to VR programming and haven't found a fix.

Attached are a couple of debug traces. VDXR_openrbrvr_0.5.0.etl is the one you want, it's captured with Virtual Desktop Streamer 1.29.10 with the bundled VDXR and OpenRBRVR 0.5.0 on a Quest 3. The archive also contains two other traces with stuff I've been working on (the additions in PR #10 (mainly adding reference space) and 0.5.0 with ReShade, which doesn't work well), just in case they're useful for some reason.

VDXR_openrbrvr_0.5.0_ETLs.zip

[mbucchia-msft]

Thanks. I will try to reproduce this exact allocation:

VirtualDesktopOpenXR	xrCreateSwapchain	65210	14172	31212	Verbose	Info	24-01-17 12:25:25.689147	Session:1 ArraySize:1 Width:5376 Height:5568 CreateFlags:0 Format:43 FaceCount:1 MipCount:1 SampleCount:1 UsageFlags:16
VirtualDesktopOpenXR	xrCreateSwapchain_Error	65209	14172	31212	Verbose	Info	24-01-17 12:25:25.836788	Error:ovrResult failure [-7000]
    Origin: ovr_CreateTextureSwapChainDX(m_ovrSession, m_ovrSubmissionDevice.Get(), &desc, &ovrSwapchain)
    Source: D:\a\VirtualDesktop-OpenXR\VirtualDesktop-OpenXR\virtualdesktop-openxr\swapchain.cpp:365

This Vulkan interop code isn't tested super well either.

One thing I find odd though: why such a big swapchain? 5376x5568 while the recommended resolution is 2688x2784?
Generally, if you are doing double-wide rendering, you'd want a swapchain of size 5376x2784 for example.

(I don't think that's the cause for the error you are seeing, but it's still odd)

[dancek]

That's because of supersampling, sorry for that! Here's another one with supersampling off.

VDXR_openrbrvr_0.5.0_no-supersampling.zip

Also, the log contents:

2024-01-17 22:45:47 +0200: VirtualDesktopXR - v1.0.1 (C:\Program Files\Virtual Desktop Streamer\OpenXR)
2024-01-17 22:45:47 +0200: Application: openRBRVR; Engine: 
2024-01-17 22:45:47 +0200: Requested extension: XR_KHR_vulkan_enable
2024-01-17 22:45:47 +0200: Using Virtual Desktop runtime
2024-01-17 22:45:47 +0200: Streamer: 1.29.10
2024-01-17 22:45:47 +0200: OVR: 1.64.0
2024-01-17 22:45:47 +0200: Device is: Meta Quest 3 (23)
2024-01-17 22:45:47 +0200: Using Vulkan on adapter: NVIDIA GeForce RTX 4080
2024-01-17 22:45:47 +0200: Using Vulkan on adapter: NVIDIA GeForce RTX 4080
2024-01-17 22:45:47 +0200: Recommended resolution: 2688x2784
2024-01-17 22:45:48 +0200: xrCreateSwapchain: ovrResult failure [-7000]
    Origin: ovr_CreateTextureSwapChainDX(m_ovrSession, m_ovrSubmissionDevice.Get(), &desc, &ovrSwapchain)
    Source: D:\a\VirtualDesktop-OpenXR\VirtualDesktop-OpenXR\virtualdesktop-openxr\swapchain.cpp:365
2024-01-17 22:45:48 +0200: xrCreateSwapchain failed with XR_ERROR_RUNTIME_FAILURE

[dancek]

The implementation is using separate swapchains for each eye. I saw some sample using a common one with layers per eye, but since this one works with the oculus openxr runtime and some other runtimes and it already fails on the first swapchain creation, I paid no attention to it.

[mbucchia-msft]

Thanks that makes sense, for some reason I saw the 2x factor and assumed you were going to do double-wide (side-by-side views). Didn't think of 2x supersampling :)

I'll take a look after work.

[mbucchia]

OK so fun stuff, I completely randomly run into a bug (not even looking at your issue yet), which I fixed, then I moved on to trying to repro your issue, and it turns out it was the same :D

I believe your issue will be fixed by this change: mbucchia/VirtualDesktop-OpenXR@54acba0

Let me see if I can test better. I thought I asked already but it looks like I didn't: is there a legit place where I can acquire the original game online?

[dancek]

I don't think that's the fix as XR_SWAPCHAIN_USAGE_COLOR_ATTACHMENT_BIT was enabled in version 0.5.0 and only removed in 0.5.1.

I'm not sure what you mean by legit but Richard Burns Rally is literally abandonware. It's not possible to purchase it, and this has been the case for about 15 years. The way to get the game is to install the RallySimFans distribution which while not open source is built by a community. The installation instructions require you to download a torrent (to reduce server load) but I archived the contents of the torrent except for tracks if you want to download it without sharing anything yourself: https://f.hrtk.in/rbr-torrent.zip . Do let me know when you've downloaded it and I'll take it offline. And when you install, install without community-made tracks and it'll work.

[dancek]

Sorry, I was wrong. 0.5.0 did have the flags changed. But during the beta phase we did have the earlier set of flags, including color attachment bit.

[mbucchia]

OK, I am mimicking your exact xrSwapchainCreate() call from a vulkan test app, and I was getting the same -7000 with the DST bit only, and the success once I added the RENDER_TARGET flag. Maybe a coincidence. I'll download the game from.

[mbucchia]

I downloaded your file. Will look into it tomorrow.

[dancek]

Modifying the current code from develop branch to use

.usageFlags = XR_SWAPCHAIN_USAGE_TRANSFER_DST_BIT | XR_SWAPCHAIN_USAGE_COLOR_ATTACHMENT_BIT

I still get XR_ERROR_RUNTIME_FAILURE from xrCreateSwapchain. I hope I'm not overlooking something stupid -- this does seem relevant but it doesn't seem to be the only issue. I also tried a couple of other combinations of usage flags, but found none that would work.

[Detegr]

The RallySimFans installer does not come with a new enough version of this plugin to have the OpenXR support. Take the latest release and extract the files to the game's installation folder, overwriting existing files if necessary. Plugins/openRBRVR.ini file needs to have a line runtime = openxr in it to enable OpenXR. The game can be launched from RichardBurnsRally_SSE.exe.

[mbucchia]

Thanks both. So I tried with RBR and indeed getting the error, regardless of the bindFlags.

So I went and modified a very very basic OpenXR Vulkan test app and that same xrCreateSwapchain() calls succeeded (as mentioned yesterday). But this was 64-bit build. I rebuilt as 32-bit, and now getting the same error :(

I am talking to Guy about it, this isn't code I can access inside Virtual Desktop (ovr_CreateTextureSwapChainDX()).

[mbucchia]

I believe we found the issue inside Virtual Desktop 32-bit code. Guy is fixing it and hopefully I will have a version to test end-to-end soon!

[mbucchia]

This seems to have done the trick!

This version isn't public yet, but will be sometimes in February.

[mbucchia]

Working pretty good!

[Detegr]

That's awesome! Thank you very much for your help.

[dancek]

Awesome! I'm looking forward to the release!

[mbucchia-msft]

Version 1.30.0 is public now!

[kordekm]

It works like a dream. Thanks a lot:)

[dancek]

It works great, thanks for working on this!

No more loading screen issues either.

[Detegr]

I was wondering, should it be possible to use OpenXR-Vk-D3D12 layer to get OpenXR Toolkit working with this? If I understand it correctly it shares the Vulkan textures to DX and submits those to OpenXR. Wouldn't it then look to OpenXR side that the application is using DirectX and in theory OpenXR toolkit could work? I did try this briefly but could not get it to work. Is there something else the toolkit requires to work? Does it support 32-bit applications at all?

[mbucchia]

OpenXR Toolkit doesn't support 32-bit

[Detegr]

I see. What about Quad-Views-Foveated? Is it D3D11 only so OpenXR-Vk-D3D12 would not help for that either even if I would write XR_VARJO_quad_views support for this?

[mbucchia]

OpenXR Toolkit was meant to inject features that the game developer did not include. You are the game developer, so you shouldn't even consider OpenXR Toolkit, but instead build the features directly in the game.

Here is an example thread with another game mod developer:

https://community.khronos.org/t/problem-with-fixed-foveated-rendering-both-eyes-are-always-using-the-left-eye-ring/110805

In the end they did the right thing and built the feature into their app, which was much better than relying on yet another 3rd party hack.

[Detegr]

Thanks for the reply, I understand your reasoning. I was asking because I thought there could be some low hanging fruits to enhance the experience using your ready made tools.

I would implement foveated rendering for sure if I knew how. Basically the rendering in this context is a black box for me as this is a plugin that's implemented by reverse engineering the game. I have located the function to render everything and I'm taking the result out. To make things more complex the game is written in DirectX9 and I'm using DXVK for emulating it in Vulkan. With some more reversing I could maybe get more granular information on what is rendered when, but I'm a total newbie to computer graphics and VR, so doing anything more complex is quite daunting.

[Detegr]

Hi again @mbucchia, sorry to ping you about this but it seems like a new release of Virtual Desktop broke compatibility with this plugin and the game is just crashing at startup. I don't want to burden you with this unless you want to so please let me know if there's somewhere else I should report this.

EDIT: Found Virtual Desktop's Discord and reported the issue there so it is known now.

[mbucchia]

I think the issue is due to a Detour we added, which doesn't seem to play well with 32-bit apps (you are also using Detours?). I can try to remove it for 32-bit apps.

[mbucchia]

Hmm nevermind, I think it's a new bug introduced in VD itself. Even removing the Detour, I am still getting some sort of weird stack overflow somewhere.

[mbucchia]

This should do the trick: mbucchia/VirtualDesktop-OpenXR@1801c77

[Detegr]

I had one user test that build out via the action's artifacts (I hope they installed it correctly) but according to them the stack trace still looks the same:

0019f1a8 60d50e84     064d2050 064d2068 d0a5ab76 VirtualDesktop_LibOVRRT32_1!ovr_SetSynchronizationQueueVk+0x1b8c0
0019f350 60d4f213     0019f708 0019f708 0019f530 virtualdesktop_openxr_32!getVersionString+0x36cc4
0019f470 60cf8d81     00000001 00000000 0019f708 virtualdesktop_openxr_32!getVersionString+0x35053
0019f528 642edf97     04384768 642edf97 00000001 virtualdesktop_openxr_32+0x48d81
0019f5cc 643e9ae9     00000001 00000000 0019f708 openxr_loader!xrGetSystem+0x67

Does this need changes from VD side also?

[mbucchia]

They could look at the log file %ProgramData%\Virtual Desktop\OpenXR.log to confirm the commit hash printed in the log.

I tested with OpenRBRVR and did not encounter the issue anymore. I am seeing another crash but it's well past the init, nowhere near VDXR, and happens even with the previous version, so I assume that's an install issue on my end. But the the ovr_Create() issue was gone. Btw don't trust your stack trace, we don't use ovr_SetSynchronizationQueueVk(), it's just the debugger incorrectly demangling symbols.

[Detegr]

That has to be an incorrect installation then. I obviously trust your tests especially if you tested against openRBRVR. Sorry for the bogus report.

[mbucchia]

Mistakes can happen here too. Maybe I made a very small last second change without thinking of it. Having them look at the log file will confirm for sure whether they picked up the change correctly.

[Detegr]

There was a mishap in the installation. After trying again it seems to be working all right. Thanks for the help again!

[mbucchia]

Cool this is great news!

I wouldn't recommend many people substituting the DLL btw - because these are not digitally signed so they break anti-cheat software. This shouldn't be a problem if they switch only the 32-bit one. But there are many 64-bit apps today where anti-cheat will break with these development DLL. JFYI.

[mbucchia]

Just checked with Guy, the update will likely go out tomorrow or the day after.