openRBRVR
openRBRVR copied to clipboard
Detegr
Hello from VDXR, OpenXR-Vk-D3D12 developer
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!
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?
Tagging @dancek. Would you like to capture a debug trace of VDXR+VirtualDesktop use case? I don't have Oculus headset.
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.
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)
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
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.
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.
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: https://github.com/mbucchia/VirtualDesktop-OpenXR/commit/54acba0c4038e43878392e7cde24122b3968b72c
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?
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.
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.
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.
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.
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.
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()).
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!
This seems to have done the trick!
This version isn't public yet, but will be sometimes in February.
It works great, thanks for working on this!
No more loading screen issues either.
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?
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?
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.
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.
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.
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.