I would like to share some observations from several weeks of testing MSFS 2024 in VR.
This is not intended as a performance guide or a definitive solution. These results come from a single system, and several variables may still be interacting. However, some of the behaviour may be useful to other users or provide additional clues for the developers.
System and VR configuration
AMD Ryzen 9 9950X3D
NVIDIA RTX 5080 16 GB
64 GB RAM
Meta Quest 3
Virtual Desktop using AV1 10-bit
Tested at 80 Hz and 70 Hz
Triple-monitor desktop configuration
MSFS graphics generally set to Ultra
My objective is not to obtain the highest possible FPS figure. I prioritise stable frame pacing, acceptable image quality and a smooth VR experience.
Initial behaviour
During previous tests, MSFS 2024 could become almost unusable in VR, sometimes dropping to approximately 18–20 FPS.
The main symptoms included:
very low and inconsistent performance;
high or irregular Game latency;
VRAM usage approaching the 16 GB limit;
occasional “lack of resources” warnings;
texture quality degradation;
poor performance despite the GPU not always appearing to be used efficiently;
substantial differences between flights that appeared to have similar conditions.
The behaviour was not always fully reproducible, which made identifying a single cause difficult.
Variables tested
During the investigation I tested, among other things:
Virtual Desktop at 80 Hz and 70 Hz;
SSW enabled and disabled;
frame-rate limits matching the headset refresh rate;
no external FPS limit;
NVIDIA application and profile settings;
ReBAR enabled and disabled through NVIDIA Profile Inspector;
different MSFS graphics and LOD settings;
different aircraft, from general aviation to complex airliners;
large airports and less demanding areas;
native MSFS traffic and SayIntentions traffic;
disabling the two side monitors before starting the VR session.
No individual setting initially explained all the performance problems.
Traffic does not appear to be the main cause
The severe performance loss occurred both when using native MSFS traffic and when using SayIntentions traffic.
For that reason, I do not currently consider traffic injection to be the main explanation for the previous 18–20 FPS behaviour.
It may still affect performance, but it does not appear to explain the fundamental problem in my case.
Recent test results
After disabling the two side monitors, the simulator began behaving considerably better.
I have not yet completed a fully controlled A/B comparison in which the side monitors are the only changed variable. Therefore, I cannot confirm that the multi-monitor configuration is the sole cause.
However, the improvement coincided clearly enough with disabling them that I believe desktop composition, monitor capture or some related overhead may be worth investigating.
Aerostar near Granada
With the same Ultra graphics settings:
SSW disabled: approximately 40–50 native FPS;
smooth experience without significant visible stuttering;
SSW enabled: approximately 80 displayed FPS;
Game latency during the better tests was around 20–21 ms.
The 80 FPS result was clearly not native performance. SSW was generating intermediate frames from a native frame rate of approximately 40 FPS.
This confirms that SSW can be very effective under certain conditions, although it does not solve the underlying simulator limitation.
Fenix A320 at Barcelona
I also tested a more demanding scenario using the Fenix A320 at Barcelona, including taxi and take-off.
Results with SSW disabled:
approximately 30–40 FPS;
no major or persistent stutters;
subjectively smooth and usable despite the relatively low FPS;
some visible texture degradation;
the “lack of resources” warning still appeared.
This is still poor performance relative to the hardware being used, but it represents a major improvement over the previous 18–20 FPS behaviour.
Virtual Desktop latency observations
During these tests, Virtual Desktop network, encoding and decoding values did not generally appear to be the main limitation.
Total latency could fluctuate between approximately 60 and 80 ms, but the largest persistent limitation appeared to be the Game value.
This suggests that, at least in these scenarios, the main restriction is inside the simulator rendering pipeline rather than the wireless streaming chain.
Current interpretation
My current interpretation is that several bottlenecks may be involved simultaneously.
- Main thread or simulator core limitation
Even with a Ryzen 9 9950X3D, complex aircraft and airports appear to remain heavily limited by the simulator Game Thread.
Reducing graphics settings may provide some relief, but it does not appear to remove the fundamental CPU-side limitation.
- VRAM and texture-streaming behaviour
The RTX 5080 has 16 GB of VRAM, but MSFS frequently approaches that limit.
When this happens, the simulator may display the resource warning and reduce texture quality. The result may remain playable, but image quality becomes less consistent.
- Possible multi-monitor or desktop-composition overhead
Disabling the two side monitors coincided with a substantial performance improvement.
This still requires a strict A/B test before it can be considered confirmed. Nevertheless, it may indicate that desktop composition, monitor capture or the handling of multiple displays has an unexpectedly large impact during VR operation.
- SSW can be useful, but it is not native performance
SSW can convert an approximately 40 FPS native experience into an 80 FPS presentation that appears considerably smoother.
That can be very useful, but it should not be interpreted as the simulator actually rendering 80 FPS.
In my case, I currently prefer 40–50 native FPS with SSW disabled whenever the experience remains smooth. SSW remains a useful fallback for more demanding situations.
Conclusion
MSFS 2024 has gone from being practically unusable in VR on my system to providing a reasonably smooth and enjoyable experience.
However, the current results remain disappointing for a Ryzen 9 9950X3D and an RTX 5080:
30–40 FPS at Barcelona with the Fenix A320;
texture degradation;
resource warnings;
persistent Game Thread limitations;
little remaining hardware headroom in complex scenarios.
The improvement is significant, but it should not be interpreted as a definitive fix or a recommended universal configuration.
The areas that may deserve further investigation are:
Game Thread and core utilisation;
VRAM allocation and texture streaming;
the effect of multiple active monitors during VR;
desktop composition and capture overhead;
consistency of performance between otherwise similar flights.
I will continue testing the side monitors in a controlled comparison, changing only that variable, to determine whether the improvement is reproducible.
