VR Reverb G2 WMR Performance (Motion Reprojection CPU issues, overclocking)

I found out several puzzling issues while trying to get a decent performance in VR. The strangest issue is being stuck in CPU-bound mode as soon as I engage Motion Reprojection.

I’m firmly CPU-limited in VR with MR (and OpenXR Toolkit, but the issue is the same without it):
image
Doesn’t even flicker occsionally with GPU-limited. No settings can bring it to GPU-limited, even LODs at minimum. It’s always CPU-limited.

When I engage VR with Motion Reprojection off - I isntently get GPU-limited, although I still have red background:
image
Does MR induce so much CPU overhead, 10FPS worth and enough to push for hard CPU limit? Very doubdful.

The moment I go to pancake mode, here’s what I get in 4K (“High-End” preset): I’m instantly limited by GPU as well (still red background).
image
SPU has 2 cores loaded well:
image

I see a strange picture in HWInfo though: unlike with synthetic benchmarks where CPU clock and effective clocks are basically the same in all stress tests, here there is a huge difference. Cores used by MSFS are boosting up to 4900Mhz which seems great, but effective clocks are only up to 3647 Mhz. ■■■?
Temps never ever go above 72C. I spent last 2 days trying to improve my overclocking, and this is the best I got. When testing OC CPU boosted to 4700 on all cores and 4800+ on single/dual core tasks. Core clocks and effective clocks are identical in all testing runs.

Does this discrepancy in effective clocks pose a problem? I don’t see it in any stress tests I threw on my system. Maybe there’s something with my overclocking that doesn’t want to play nice with this sim? But I did try with stock (no OC) and it didn’t make a noticeable difference. BTW no matter how hard I tried to push overclocking, I could never make the temps go above 72C. I do have large (360, 3-fan) AIO liquid CPU cooling system, and 5-fan case. It doesn’t even have to spin up the fans at full speed.
image

I wonder if there’s anything I’m doing wrong here…

System specs:
Ryzen 9 5900X
EVGA RTX 3080 FTW3, mildly overclocked (+200 VRAM, +110 GPU)
64Gb 6800 DDR (overclocked, tightened timings, rock-stable), 8Gb RAM drive for MSFS rolling cache. 2TB very fast MSFS M2 SSD
512Gb System M2 SSD (Win10)
Reverb G2 (with v2 cable)
Motion platform (DIY, run by FlyPT Mover, 2DOF + 2x DIY transducers fed by SimShaker)

MSFS: mostly high settings in VR, OpenXR Toolkit at 80% scaling FSR, OXR100/TAA100, LOD 100. Same flight precet - KLGA facing Manhattan - RWY 22, in TBM.

I see the same general results when comparing motion reprojection on versus off…MR has a heavy impact on the CPU and I see it also results in my GPU being less utilized and therefore not as balanced across both GPU/CPU. Even with the G2 which has fairly good motion reprojection compared to some headsets it’s very heavy on the CPU and quickly tanks frame rates as the CPU-limited bottleneck is quick and strong, along with the locking it has to do to 22.5 or 30fps for the G2. I am running an i9 12900k and rtx 3090 with 64gb ram. I tend to not use reprojection at all due to the wing warping, propeller artifacts (even with the mods you can get), and fuzziness on the cockpit instruments and I have become used to the slight studdering you get when flying low and looking outside without reprojection (meaning with final fps of around 30-40fps). I don’t think overclocking has anything to do with what you are experiencing, I think it’s just the load on the CPU to process the motion reprojection which isn’t as well optimized at this point as it may be in the future. Having said that, in the G2 with WMR it is far better MP performance than it was even 6 months ago, it’s quite good actually now when compared to the early days of motion reprojection where the wing warping and other artifacts were very noticeable (much much less now).

Unfortunately I can’t stand MR off, stuttering is too evident for me. I don’t see any difference in clarity with MR on. I have literally 0 propeller artifacts with the “multi” mod - which is logical, as it basically replaced props with solid almost-transparent disks, which is what I was doing before the mod appeared. I do see wing and cockpit artifacts but they are relatively minor, compared to the stutter without MR even ar 40FPS. I may be more susceptivle for that effect, because I also can’t stand 60Hz refresh - I see constant flickering, and some people are fine with that and don’t notice any flickering.

When MR works it’s mostly butter-smooth now (with an occasional scenery-loading stutter which still plagues MSFS, not related to MR). Often I have it locket at 30, falling to 22.5 on the ground at busy locations. But when it breaks down, which happens rarely, but often enought o be a concern, it becomes a terrible mess…

2 Likes

I think you are reading the statistics incorrectly. I was just discussing this with @RomanDesign by PM, but I will explain it here too.

You can use the OpenXR “Display frame timing overlay” (see Developer Tools) in order to confirm everything I am about to say below.

The stats in the OpenXR overlay will show you 3 lines:

App Cpu/Gpu ← This is the workload of FS
Pre Cpu/Gpu ← This will always read 0 for now because the game does not submit depth buffers
Post Cpu/Gpu ← This is the workload of the OpenXR runtime, in this case the Motion Reprojection.

Based on the numbers @RomanDesign shared with me, it appears that App Cpu is basically just a little bit more than what the other overlays calls “RdrThread”, here 13.4ms. These values are directly reflecting the amount of CPU time used to submit the work to the GPU.

So if you look at your values here, we have RdrThread being 13.4ms, and OpenXR App Cpu was about ~15ms. This number is the CPU utilization for rendering a frame in the game.. Now 15ms, that is technically low enough to drive up to 60 FPS. Yes 60 FPS.

Now you look at the App Gpu number. This number matches the GPU time you also see in the other overlay. In your case, here, you see 27.4ms. This duration is low enough to drive ~37 FPS.

So very clearly, you look at those 2 numbers above:

  • CPU can drive 60 FPS
  • GPU can drive 37 FPS

You take the smallest one out of the 2. This is the GPU one. You are GPU-bound.

Q:

Nope. You can go look at the statistics I mentioned yourself. Post Cpu/Gpu, on my machine at least, is reading less than 1ms on CPU (so basically nothing) and 4-5mis on the GPU.

Q: OK so what the heck is this “Limited by MainThread”?

I cannot answer than with certainty, because only the developers can. But I can give you a very reasonable guess and explanation.

The time shown as App Cpu is the duration between the game calling the “beginning of the frame” and the game submitting the frame, ie “finish of the frame”. This is the time the game is actively busy doing computational work and writing commands to the GPU.

There is however, another step involved in this frame rendering process: the “waiting to begin the frame” step. The MainThread duration observed in the overlay is likely corresponding to the duration between the “waiting to begin the frame” and “finish of the frame”.. Yes, you just read it. Read it back. This MainThread timer is including the “waiting” phase. During that phase, well, nothing happens. The game just waits. It does not use extra CPU.

This is also why the MainThread time is reading ~30ms in your screenshot, because 30ms is about 30 FPS (there’s always a few milliseconds of overhead/gap here and there, so just ignore them).

Q: Now wait, why 30 FPS? Why not 37 FPS?

These questions are all answered by looking at the principle of reprojection. VR headsets are best driven at the same rate that their display supports. So for example with a 90Hz display, you want to send an image 90 times per second, and this timing must match when the display will start showing the image (the “scan out”). Why is that by the way? This is because it takes several milliseconds for a display to fully illuminate all the pixels making up the image. So when you want to reduce latency, you want to produce an image as close as possible to the beginning of scan out.

For reprojection to be able to match the display rate mentioned above, it is easiest to lock the app framerate to a rate that is divisible of the refresh rate. This is why for your 90Hz display, we will try to lock at 90 FPS, or 45 FPS, or 30 FPS, or 22.5 FPS. This way for each frame, we will either do (respectively) no reprojection, 2x reprojection, 3x reprojection or 4x reprojection.

Q: And also why waiting, this sounds stupid?

In order to lock onto the frame rate chosen above, we must throttle down the game. This means doing a wait. There are 2 paradigms when implementing a wait: 1) the so-called “active wait” or “busy loop” and 2) the sleep.

The 1) as its name indicates is actively using the CPU to perform the wait. Literally, the CPU core will be executing these instructions called NOP (No Operation) and check for the desired wait condition to be over. When doing that, nothing else runs on your CPU core, and the wattage/temperature will go up, because a busy loop is effectively using 100% of your CPU core. Active wait is bad, and typically not used in high-performance applications.

Option 2) is what OpenXR implements. When the game is waiting for the next frame to lock onto, the game thread performing the wait goes to sleep. When it sleeps, two things may happen:

  • Another thread is executed, effectively allowing other tasks within the application or other programs on your system to run.
  • If no other thread is eligible, the CPU core will go into a so-called halt state. In the halt state, the CPU core will not do anything, and this effectively lowers wattage and heat. This is what you sometimes sees referred to as the “idle thread”.

So for short, this wait between the RdrThread’s 15ms and the MainThrThread’s 30ms is 15ms of sleep, where either the game will decide to do something else (like downloading something, or doing physics, or audio) or the system will just go idle.

In all cases, you are not CPU-bound. Wait is good. Wait means you have headroom.

Q: Wut?

Limited by MainThread, in the circumstances described above, does not mean limited by how powerful your CPU is.

Here, Limited by MainThread is a reflection of the OpenXR runtime throttling down the game to lock onto an optimal Motion Reprojection rate. This optimal rate is determined by looking at both the CPU and GPU load. In the case reviewed above, the bottleneck is the GPU.

To quickly find out if you are truly CPU Limited, take a look at RdrThread and GPU time. The higher value of the two indicates whether your CPU (RdrThread is higher) or GPU (GPU time is higher) is the limiting factor.

17 Likes

This is incredibly helpful, thank you for such a detailed and informative post!

3 Likes

This is the best explanation of how the FPS and frametime counters work, period! Thank you for sharing this and sharing out private discussion, I’m sure this will be helpful to many. What it tells me is that I can now understand how to balance my settings better - I can see where I have headrom to improve. In this situation it looks that I can bump up CPU-intensive settings a bit (LOD, car and plane traffic) and tone down some GPU-intentive settings, so the CPU/GPU balance is more even. There is no sense leaving computational power to be unused. So if there’s some headroom I better use it to get a better experience.

3 Likes

This is excellent info. It’s going to take a few reads for me to comprehend and apply to my setup but my results when enabling MR are exactly the same as @RomanDesign and @tempestornado23.

I too have stopped using it since the toolkit came out due to all reasons listed but if you start seeing favorable results please let us know. I would love to be able to switch between all planes, places and weather and know with confidence how to get MR working in harmony.

Right now, any configurations I try seem so hit and miss.

2 Likes

That’s the story with MSFS with VR even on high-end PCs, unfortunately. I’m aiming now to have a TBM working smoothly and reliably in and around Manhattan with “Scattered Clouds” weather. Hopefuly that would mean that everything would work everywhere, more or less. So far I’m not entirely successful. KJFK on the ground I have perfect (for MR) 30FPS, and most of the time flying as well, occasionally falling to 22.5 (4x MR) which is fine. Unfortunately as I turn back, or just suddently it can break down at the same place that it was 30FPS just 2 minutes ago, and fall back to a horrible 15-17FPS with no reason whatsoever. Sometime, if I put it on pause and wait for a monute, then un-pause - its 30FPS again. I’m not sure what’s going on, because my PC has stellar specs and no bottlenecks, and I’m on 1Gb internet. OpenXR Toolkit helps a lot, so for the first time it’s closer to smooth and reliable performance than ever. But it’s still not quite there yet.

I was under impression that I’m CPU-bound and tried to lessen the load on CPU to get smoother performance, but now it seems that I should lower GPU settings instead. Will do some more experimenting. Also installed the latest beta. First test was horrible (15FPS!), but after a minute it started working as well as before. Go figure. MSFS is notorious for performing differently in identical conditions, making any testing and comparison extremely difficult.

2 Likes

Exactly. Going back to your first post screenshots; if I lower NIS factor to say 70% (2150x2150ish - MR Off) the sim will do about 50fps and that red will go to a yellow. It won’t flicker green until you can hit 60fps but you really have to cut the Sims features down to get that high of a frame rate.

I enabled MR whilst hitting these numbers thinking the sim could easily handle MR now but no. This was in the 152 in a rural airfield too.

I often wonder if two users would see similar performance if they flew together. Same plane, time, weather, etc. MR working for both then it stop working for both at the same time or area for example.

When I did use MR I had TLOD & OLOD 65 and cars about 25% but now i question how much any of it impacts MR when sometimes it won’t work in the middle of no where ina 152 that’s cold and dark but then I can zip through downtown Illinois in a citation like magic another time.

When MR is failing for me the FPS overlay looks like an ECG graph showing a heartbeat. Looking out the windows it’s smooth motion, then it drops out, then smooth, then drop out, smooth, drop out. It’s consistent but nauseating.

I felt the sim worked better by turning off the rolling cache and setting up a fixed with about 15G. Won’t take you long to see if it helps you.

Thank you for your detailed explanation, I now see that I’m GPU limited (around 35-39ms). Tried out some settings changes and the best reward was changing Clouds from Ultra to High, 3-4 fps gain and still nice visual quality.

If others could compare, I have a RTX 3080 with AMD 5600x cpu. Is it normal to be at around 27-28 fps (when lots of clouds in the sky) if I run the game in VR at 100% resolution everywhere, no upscaling?

(If I put clear weather presets, I’m hovering around 30-32 fps)

I’m curious how you’ve been progressing with this. I’ve all but given up on MR until i hear from someone with solid results.

I’m forcing my self to adjust to MR Off and 40-45 fps. I can learn to live / ignore the judders just as i did the wobbles using MR.

I think your results are in line with many. I am running a G2 on an i9 12900k with a 3090, set to 100% LODs, 100% in sim resolution, medium settings on most graphics options, a few highs like glass screen and clouds, and then 85% render in the OpenXR Toolkit. I can get ~40 fps with mixed clouds (day or night) in most cities and rural areas…some bumps up to mid/high 40s in very rural areas and a few dips to low 30s in busy cities/airports…and the GPU sits in mid 90% usage with CPU at 25% average (a few cores of course are far higher than that). If I turn on motion re-projection I actually get GPU usage that drops to ~70% and CPU usage of course goes up and frames lock then to 30, sometimes 22.5 as I have my G2 running in 90hz mode. Good call on the clouds at high and not ultra as you don’t really see much difference in visuals…ultra really stresses the cpu/gpu for any of the options but especially clouds. That YT video that shows the side by side of Medium vs. High vs. Ultra for many of the graphics settings convinced me to stop chasing High and Ultra settings and instead go for smoothness and consistent frame times with still good visuals on mostly medium settings.

3 Likes

Thanks for the reply. Ok seems about right then. I’m sitting at around 31fps with OXR 150% and toolkit at 75% (100% sharpness). Also, see below my clouds in HIGH vs Ultra. You can notice it a bit but not enough to lose the almost 5fps (my personal gain)

Clouds High setting

Clouds Ultra setting

This sounds exactly like the problems I’m having. I thought it was the NIS scaller at first but I’ve deleted that now and its still the same.

I’ve aways used MR even well before the NIS tool ever came out and although the graphics haven’t been brilliant they have been smooth. Just lately though my frame rates have been dropping through the floor seemingly at random times. It will fly ultra smooth and then suddenly becomes a stutter fest, frames of around 10fps and the sim just wont recover from this, even back in the menu’s it stays at 10fps or something like this. Occasionally if you start a new flight it goes smooth again but more often than not I have to start the sim again.

It will also go like this if I go from VR to 2D and then back to VR, I also have to make sure I’m in VR mode before the flight fully loads or I’ll have the same problem.

However I’ve just discovered that if I dissable MR then none of this happens no matter how hard I try to recreate it. Its just with MR disabled everything looks like the camera is shaking when I turn the plane or my head, almost looks like the view is vibrating.

Whats changed in the last few weeks to go as horribly wrong as this has done?

Whats changed in the last few weeks to go as horribly wrong as this has done?

Did your MR stutters start last week?

I’m also experiencing odd, unexplainable stutters with MR enabled over the past week. I’m going to try disabling the preview mode in OXR Tools to see if perhaps it helps.

Please let me know, but I would be very surprised, there aren’t really any changes affecting PCVR in this release.

I tried disabling preview mode and I can’t tell that it made any difference. I’m not sure what’s going on on my system. I had everything set up in a set-it-and-forget-it state with OXR 80, MR auto, NIS 85, Sharpening 25. Then, about a week ago, I started getting oddball loss of performance that comes and goes. The hunt for the cause continues…

Same problems for me. I’ve done everything I possibly can to get to the bottom of it which included the following.

complete format of my PC
new windows install
reinstalled flight sim
latest drivers (earlier ones made no difference)
every setting left as standard
no other programs installed apart from what comes with windows
nothing in the community folder

Within minutes of playing the game I had exactly the same problems.

With motion projection on everything is fine to begin with but within minutes the stutters and serious frame rate drop to the point it becomes a slide show, the problem continues in the menu area. This also happens if I tab out of VR and back into it, I can get this problem to manifest every time I go out and back into VR without fail.

With motion reprojection off this problem will not happen no matter how hard I try to replicate it. Turning the preview mode off so it uses an earlier runtime makes absolutely no difference.

This problem has only happened within the last couple of weeks, before that it was running perfectly.

Just to add to my last reply as well, I have now deleted the NIS/FSR toolkit as opposed to disabling it and the problem seems to have gone away. Of course my settings are now much lower and the graphics are worse but never the less it seems to have stopped doing it even with MR active

My open XR setting is now 70% instead of 150% though so maybe its that but there definitely seems to be a problem between the scaling tool and MR/high settings, certainly for me at least.