-
Notifications
You must be signed in to change notification settings - Fork 7
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
Hello from VDXR, OpenXR-Vk-D3D12 developer #9
Comments
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 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 VDXR+VirtualDesktop fails very early. The call to |
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. |
Thanks. I will try to reproduce this exact allocation:
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? (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:
|
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: 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? |
I don't think that's the fix as 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 |
I downloaded your file. Will look into it tomorrow. |
Modifying the current code from
I still get |
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. |
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 I am talking to Guy about it, this isn't code I can access inside Virtual Desktop ( |
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! |
That's awesome! Thank you very much for your help. |
Awesome! I'm looking forward to the release! |
Version 1.30.0 is public now! |
It works like a dream. Thanks a lot:) |
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? |
OpenXR Toolkit doesn't support 32-bit |
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: 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. |
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. |
This should do the trick: mbucchia/VirtualDesktop-OpenXR@1801c77 |
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:
Does this need changes from VD side also? |
They could look at the log file 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 |
That has to be an incorrect installation then. I obviously trust your tests especially if you tested against openRBRVR. Sorry for the bogus report. |
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. |
There was a mishap in the installation. After trying again it seems to be working all right. Thanks for the help again! |
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. |
Just checked with Guy, the update will likely go out tomorrow or the day after. |
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!
The text was updated successfully, but these errors were encountered: