Firstly, I would just like to thank the team for working so hard on this application for the VR community. We are extremely grateful and fortunate that you’ve taken up the not inconsiderable challenge of making VR accessible to those of us with more modest hardware.
Secondly, I just wanted to provide some feedback about my experiences today using the OpenXR Toolkit (v1.0.1) together with a Quest 2, the Oculus Desktop app and a RTX2070S. Essentially what I’m finding is not being able to disable the MR (i.e. ASW in the Oculus language) results in serious stuttering of the Quest 2 image. For my system, I’ve always found setting the headset refresh rate to 90Hz and clamping the PC monitor FPS to 30Hz via the NCP results in the smoothest VR experience. However, this is only true when MR (ASW) is disabled using either the OTT or ODT. What I’ve discovered, however, is v1.0.1 only provides this function for WMR headsets and I think forces MR to be enabled for Quest 2 users. Hence, for the moment, I’ve switched back to v0.9.7 where I can still disable MR using the OTT. Nevertheless, this is still so much better than running without the OpenXR Toolkit. Many thanks to the Team.
Hmmm, this is definitely not true. If you don’t have WMR, we do absolutely zero about ASW. We simply don’t have control over it. The motion reprojection feature added in 1.0.1 write registry keys that only WMR uses.
So I think you are experiencing a placebo effect.
Thanks for your reply. Definitely not a placebo effect though. Its very easy to spot and I’ve been able to repeat it several times. Could it possibly be a conflict between the OTT and the OpenXR Toolkit that forces ASW back to auto? I just can’t seem to disable ASW when running v1.0.1 but I could do this when running the previous version.
Must be a conflict somewhere but really don’t see where. I know this is a ridiculous ask, but can you try with DX12 to see if you have the same results. I wonder if this had to do with the issue we have with FFR (the DX injection) and somehow we are fighting Oculus apparent hack with our own hack 
Hi! I just tried the new version out today and noticed the same with when turning FFR on - I’d get a black screen until I enabled some form of AA in the sim. Using a Index, so SteamVR and DX11. I keep AA off because it keeps things looking sharper, at the expense of some jagginess, but nothing that bothers me. Turning AA on seems to kill any performance gains the FFR might be giving me. I’m using a 3080 and a stock clocked 9600K, so I think I’m CPU limited.
You got a link to the prop mod? The C152 is driving me crazy 
I did have another thought. I do also employ the Width/Height control in v1.0.1 but of course this can also be set using either the OTT or ODT. When I first open either of the latter to disable the ASW, they will try to impose their default settings which will differ from those set in the Toolkit. Is it possible this results in a conflict, forcing ASW back to its default. Not sure.
I’ll keep experimenting. Thank you again!
Yes, i mean Ctr-Alt-Del. But for your test i captured the WMR Preview and by starting it, the issue also got solved. But here are the images:
In the last picture you can see the problem, GPU utilization is toggling between very high and very low. After my workaround, it gets yellow and works.
How the heck do you not use PP?
3090 with 12th gen cpu, pimax 8kx: I was really excited about this update but it gives me black dots everywhere on edges and the FFR is not centered correctly no matter what I adjust although the expert options were politely added, I couldn’t get either eye to line up FFR. It seems to be way to the bottom right in the left eye and no where at all on the right eye. Also sadly even when the FFR is ridiculously high, I see negligible performance improvement. NIS/FSR didnt look right to me either, but never did. I am glad it seems to be helping many others however. Fholgers vrperfkit does work well for me elsewhere. MSFS2020 was what I bought the Pimax for, and I have found Pimax 8KX just doesn’t seem to play nice with this mod or FS2020 in general.
VR FS2020 is like a money-pit house I have too much emotional investment in. Except it’s time that I keep pouring into it. I need to take a break and just wait for 15th gen cpus and 4090gtx to fix everything else. After all wideFOV HMD support was booted to 2023.
Given that you’re not providing any actionable feedback here, I give up too 
EDIT: Thank you for adding details.
You’re right. Not fair at all to you. Family first thats all.
@dbuz1805 @Flobud thanks guys for your help.
Yeah, in the meantime I figured out I had to activate dev membership, but the needed options still don’t come up under Beta. I think I’ll just wait 'til tomorrow and check if Beta options are updated.
[edit] Minor detail, I had to log out in order to activate dev account.
Amazing to see my virtual hands float through the cockpit.
Didn’t manage to interact with buttons/rotators yet, but I’m sure gonna find out.
Are you also having the “no right eye” issue?
@legia92 was reporting this too at first, but then it went away. So there has to be an option or a state causing this. Definitely worth investigating some more, but not having a device, this is going to take some help from you both to understand what is causing this.
Well it looks like you never really got it to work properly (only one eye), so it’s a bit early to make performance assessment. It’s a bit difficult to judge the performance of a car when you only put 2 tires on it.
Are you sure you are even GPU limited? FFR will not help if you are CPU limited or on the edge of it. What numbers do you have? FFR also only help when the Pixel Shader unit is your bottleneck (which you can’t really know without using a GPU profiling tool, which is quite complex).
That’s great, but not at all a valid comparison to make. We use the same tech, and the black dot issues is specific to FS2020 post-processing. Until you can get vrperfkit to work with FS2020, your statement is completely blank in the context of our conversation.
There’s definitely something with the 8K, my tester with a 5K is not having your eye position issues. That said, it looks like both my tester and @legia92 had PP off, so it’s likely part of the culprit here.
As you already know, we use the same math as vrperfkit for calculating the eye centers. So when you use vrperfkit with OpenVR apps, are those apps also doing PP or no PP?
The issue with PC and FS2020 user IMO is the crazy amount of GPU driver tweaking and 3rd party mods that creates a ridiculous amount of variability. So much that it’s impossible for any developer to handle all these cases. I’m pretty sure 90% of those non-default settings are absolutely not justified, because 90% of the time the software will make a better decision than any standard user. Now sure there are extreme cases like the need of PP for the WFOV issue, not arguing with this one.
That’s the goal yes, but without owning a Quest device to debug the issue, it’s very difficult.
The technical details of it is that Oculus seems to be using a technique similar to ours for intercepting some of the draw calls from the application (no idea what they do with it) and it conflicts with what we do.
Anybody else tried this configuration? I was not aware that the SteamVR runtime for Oculus supported the hands. AFAIK the hand tracking can only work with OpenXR through the use of the Oculus runtime.
Will consider it.
Thanks for the screenshots @dbuz1805. Do you mind if I steal them for our website?
Thanks for confirming, I will log a bug for this. However this will likely take a while to get to it (low priority since the majority of users seem to not want to live without AA - but I understand your use case and we will try to get it working).
Thank you and let me know what you find. I could think of the OpenXR runtime being picky about texture size for certain effects, however when you use the Anamorphic option in OXRTK, the Oculus runtime still sees the full res texture. So it should not impact anything (Oculus runtime is not aware of it).
Interesting find.
Also what I notice is the Post GPU going from 9ms to 2ms, that’s a huge drop. Definitely looks like something odd with this. Maybe the screenshot was timed weirdly, so can you observe this Post GPU value a bit closer next time and comment on its fluctuations before/after the issue?
Thank you!
Well, I’m also a programmer so I’d be happy to test stuff on my Quest 2.
Mind you, I’m only fluent with JS and I have no clue about this VR voodoo stuff. But I think I should be able to test/run code and provide you with some logging. Just let me know if that would help.
Well. Of course I’ll keep trying occasionally. I just need a break is all. Im highly let down by MSFS2020 for VR wide FoV support. DLSS however will bring me back to visit as yea I’m GPU limited. I will give it an earnest try without PP but that has always meant culling issues - has that been magically resolved?
Ah, I thought I read that the SteamVR runtime must be used, but maybe that is only for the FFR? I will try the hand tracking again tomorrow with the Oculus runtime.