UE4 -> UE5 Performance Drop on VR Template. Should UE5 be used for VR?

I have been experiencing confounding performance issues when transitioning a VR project from UE4 to UE5. We have managed to get the project operable on high end hardware. (Hardware in Question) However, this is not a realistic hardware requirement to ask of our users, especially given the comparatively simple content in our project.

Recently I ran a series of tests using the VR template from 4.19 and I wanted to share my results here. I am hoping that this might be useful for others, and that others might be able to provide some insights into the issues I have been experiencing. The goal of these tests where to determine if UE5 (5.4 specifically) is suitable for VR development.

I wanted to replicate what I have done with my active project while eliminating as many variables as possible. In order to do this I took the VR template from 4.19 and updated it to 5.4. (The actual project I am working on was gradually brought up version by version throughout the years, but I don’t have the time or hard drive space to replicate this exactly.) Here is a screenshot of the settings at project creation.


After building this project in 4.19 it preformed very well. It capped out at 11ms according to the frontend profiler and Steam VR performance was reporting around 4ms. The hardware for our test device is as follows:

  • Intel(R) Xeon(R) W-2125 CPU @ 4.00GHz
  • Samsung MZVLB512HBJQ-000L7 SSD
  • NVIDIA Quadro RTX 6000 GPU
  • 32GB of RAM


4.19LabCompSteam

On the other hand, when this project has been updated to 5.4 the performance drops significantly. Unreal insights puts it at about 22ms per frame and Steam VR puts it at around 20ms.



5.4LabCompSteam_4.9temp

On the other hand the 5.4 VR template runs at around according to unreal insights and reads 5.6ms on the Steam VR performance readout.


5.4Temp_GPU

5.4LabCompSteam_5.4temp

From this we can assume that even if 5.4 is slightly less performant than 4.19 the difference is negligible and 5.4 should have the capacity to run well enough. One can assume that there is likely something in the project settings for VR that has changed from 4.19 to 5.4 that is preventing the migrated project from performing well.

I decided to go through the project settings to identify any differences. In the project settings to see if there was anything unexpected. Predictably there are some innocuous differences in the setup such as the game mode and input:







Unsurprisingly most differences are in the rendering section. Most differences are unsurprising and simply align with most general VR performance advice, such as the use of forward rendering, the lack of mobile HDR, and the use of MSAA for anti aliasing. Others I’m not sure are consequential like the lack of motion blur, auto exposure, and the separate translucency.



Lastly the D3D12 Targeted Shader Formats are different under the windows platform settings.

I was hoping to spot something unexpected here, but unfortunately I did not. Unless I am overlooking something, most differences here can already be found in the VR best practices or can easily be found while researching optimization. In other words they are things that I have already implemented on my active project.

So I am left wondering, is there something I am missing here? I would love to know if anyone is able to replicate these results. Better yet if anyone as taken a VR project from UE4 to UE5 and of they experienced any similar issues. If so how have they navigated them? Beyond that what is your opinion on using UE5 for VR? We are currently considering an attempt to return to UE4 as our attempts to optimize in UE5 have been met with failure. As you can imagine this is not something I would like to attempt, so any advice or perspective would be appreciated.

According to the profiler you are GPU bound with an extremely large portion (14ms out of 16ms) being taken by Temporal Super Resolution. You could try switching the Anti-aliasing method to the one you used in UE4.

Most new rendering features in UE5 aren’t very VR friendly. Most of them only support the deferred renderer though, so they get sidestepped by the template using Forward Shading.

1 Like

That is good to know! We are currently using Forward rendering on our base project as well. However we are still seeing a pretty significant dip in performance. I think we are CPU bound in this case on begin frame.


5.4RealProject_GPU
Did UE5 change anything about how they where handling draw calls?

If you switched from using the SteamVR plugin to the OpenXR plugin, it changes up the frame synchronization a bit. Not sure if it has any effect on performance though.

The SteamVR runtime synchronizes on xrBeginFrame (even though it’s supposed to synchronize on xrWaitFrame according to the OpenXR spec). It’s blocking on it for longer than a single frame, which means that SteamVR is throttling the framerate of the application. It’s supposed to do that when it detects that the app isn’t meeting framerate, but will try to drop out of it periodically.

To make it easier to actually see the frame timing, you can disable the throttling from the SteamVR settings under Per-application video settings, by setting the Throttling Behavior to Fixed, and leaving the slider at the highest framerate. The SteamVR performance graph should turn orange instead of yellow if throttling is disabled.

1 Like

Converting a project to a newer version sometimes gave me some headaches. Maybe some cvars that are causing issues? You could try creating a brand new v5 project and migrating your levels from 4.27 instead. That way, any hidden / conflicting old cvars etc won’t transfer over to v5

1 Like

Thank you! That was a significant help. When I do as you instructed it looks like we are actually hitting our performance targets!
SteamThrotaling


5.4SansTrotaling_GPU

Which is extremely encouraging. I have a few follow up questions because I am still slightly confused about what this means for my next steps.

  • Is this throttling known to have a tangible effect on the user experience?
  • Has this been obfuscating my games actual performance or is this throttling actually slowing down my game?
  • if it is - is there a way to ensure that this doesn’t happen when our game is published?

During our testing I thought it was strange that I didn’t notice the performance drop when our frame rate dropped by half. Is steam compensating with motion smoothing or something similar? It would be nice if we didn’t have to instruct every customer using our product to go into the settings and edit the throttling settings.

We did try migrating! I didn’t include this in the original post because when migrating our active project to a blank 5.4 VR template we actually saw a performance drop. In the case of the VR template, however, migrating was effective at returning performance to the expected standards.

From what I understand, the throttling is mainly there to augment motion smoothing. It’s way more intrusive if motion smoothing keeps turning on and off, so the throttling is there to keep it engaged for a bit once the framerate dips.

Both. I’m not sure on the actual algorithms it uses, but it seems it is throttling for too long. It might be affected by the profiler though. It might be a good idea to test on a release build and see if it still throttles that much. If I remember right, it’s supposed to unthrottle after a few seconds.

Not really. I wouldn’t recommend instructing users to disable throttling though. It’s too hard to predict if it will be beneficial across different users and systems.