Its just a Valve Index with SteamVR. There is no OpenXR software in play as far as I know (unless its inherent within MSFS) and in fact the OVR Toolkit doesnt seem to work.
Yeah I know it’s confusing and the data doesnt help. Fact remains, and I can assure you 100% it does, that with older AMD drivers you can limit FPS to 22 and play perfectly well with Motion Smoohting on. At newer versions of the drivers, same situation, same system and same level of details, you still DO hit the target and yet it bubbles like crazy and just doesn’t work AT ALL. I wish it could be experienced second hand…
so ive been trying out MR with my reverb g2 and it seems like mine locks at 30 FPS which seems to be a very acceptable level but the picture is extremely wobbly giving an underwater kind of look.
If you’re using OpenXR Toolkit you probably want to disable Shaking reduction if you have that on.
If you are on AMD card I don’t expect you will ever get good results.
Good things are coming though. I do have some changes in progress, one of them should help on AMD.
I tried really really hard to come up with options for AMD. They just don’t seem to have any options for developers.
I asked AMD to see if their new-generation SDK (AMF) would allow me to get better motion estimation, and they replied it’s just not a feature they have.
The only other thing I found is LiquidVR, which is an 8-year old SDK designed for GPUs 2-3 generations older…
It’s night and day compared to Nvidia: they’ve had dedicated support for several generations of product, and now they’re pushing hard their Optical Flow, including improvements on 4000 series cards…
Disappointing, but precisely the reason I jumped ship and went back to nVidia for the 4090. The Radeon 7000 series could be super fast*, but they just can’t be trusted to have the features I need for VR.
Although there are rumours that AMD in fact cannot match the 4090 and have pushed back both announcement and release date of the 7000 series.
@mbucchia
As usual we thank you so much for your help and expertise! Regarding MR, when i plot my frame times, i see quite a lot of significant ( maybe 5 to 10 msec) variation even though 90% of my frames are at the sync frequency - and yet MR works well throughout except for occasional stutters.Not sure how MR does it but I am thankful for smooth VR. In my professional career in flight sim, we made sure there were never frame overruns in our out-the-window scenery so that was simpler but not nearly as beautiful as MSFS scenery
While I made the diagram (the one with the workload scheduling), I thought of the possible explanation for this:
Direct3D doesn’t let you control precisely where the preemption of current workload happen.
So there can be a lot of variability for when then MR workload takes precedence over the app frame time?
Sometimes, some MR workload might be pushed all the way to that large Idle period after the end of app frame rendering.
This could explain large variation.
One thing not discussed in my post is the frame rate heuristic, the code that determines what divider rate to select based on observed app CPU/GPU frame times. That code definitely acts as a “low-pass filter” meaning it will cut off noise for frame times that are out-of-family for the given selected divider. Without this filtering, these large variations on frame time would make you bounce between frame rates all the time.
