Search Issue Tracker

By Design

Votes

55

Found in [Package]

2019.4

2019.4.1f1

2020.1

2020.2

Issue ID

1262597

Regression

No

[XR SDK][Oculus] EarlyUpdate.XRUpdate spikes inconsistently

Package: Oculus XR Plugin

-

Reproduction steps:
1. Open the attached project ("1262597Repro.zip")
2. Open "SampleScene" scene
3. Make sure Scene and Game windows are visible
4. Open Profiler Window
5. Enter Play mode
6. Move HMD around

Expected result: EarlyUpdate.XRUpdate does not spike stays consistent
Actual result: EarlyUpdate.XRUpdate spikes inconsistently

Reproducible with: 2019.4.12f1, 2020.1.8f1, 2020.2.0b6
Not reproducible with: 2018.4.28f1 (XR SDK isn't available)

  1. Resolution Note:

    The XRUpdate profiler marker covers a lot, so we're going to go over a few cases where it can spike in duration.

    First of all, almost always, the biggest consumer of time in XRUpdate on Oculus platforms is going to be waiting for frame sync. This wait happens in the Oculus runtime, and they do this wait to reduce latency, maintain proper cadence, etc. In order to clarify where XRUpdate is spending its time, we have added a new profiler marker: `OculusRuntime.WaitToBeginFrame`. This is available in the Oculus XR Plugin 1.7.0-preview.1 and higher. Anyone reporting or voting on this bug, it would be great if you could try this version of the Oculus XR Plugin and verify that the time is being spent in WaitToBeginFrame. If it is, it's likely going to be related to one of the items below. If it's not, please give us feedback.

    1) If you are using minimal frame time. In this case, WaitToBeginFrame will be waiting because you're running great and it's preventing the engine from feeding it frames too fast.
    2) If you are missing framerate, even if barely, or seemingly right on the edge with maybe even a bit of breathing room.
    3) If you are experiencing highly variable frame times. In this case you might see unusual behavior where WaitToBeginFrame is taking a long time one frame, and almost no time the next. This can happen because the runtime is trying to compensate for this variable frame timing.

    For point 3, one thing we've seen is that the in-editor profiler can induce these spikes. The Unity profiler updates in the main thread, but not every frame. When it does update, you'll notice two `EditorLoop` profiler markers. The second one is the profiler updating the UI, etc. Because this is on the main thread, it causes a spike in frame time, and the Oculus runtime appears to be compensating for this, resulting in the WaitToBeginFrame timing that we see.

    In Unity 2020.1+, you can run the profiler standalone, outside of the editor process. Doing this, we aren't seeing the same spikes caused by the profiler timing.

    In summary, please try out the 1.7.0-preview.1 or higher Oculus XR Plugin and see if the WaitToBeginFrame marker is what is taking the most time. If so, this is in the Oculus runtime, and it is doing what is needed to maintain proper cadence and low latency.

    If you don't believe that you are seeing one of the 3 cases mentioned above or something similar, please let us know.

Comments (28)

  1. jj-unity

    Dec 09, 2020 10:33

    Ok, we've been investigating this a fair amount. XRUpdate covers a *lot* of cases, so there's no one answer here. We added a new profiler marker to attempt to help with resolving this. The tl;dr is that almost all of the time in XRUpdate is typically spent in the Oculus runtime waiting for frame timing cadence. This is intentional. If there are situations where this does not seem to be the case, we absolutely want to hear about them. Please try out 1.7.0-preview.1 of the Oculus XR Plugin and verify that the time is spent inside the Oculus runtime waiting for frame timing.

    Here are the notes I added to the bug:

    The XRUpdate profiler marker covers a lot, so we're going to go over a few cases where it can spike in duration.

    First of all, almost always, the biggest consumer of time in XRUpdate on Oculus platforms is going to be waiting for frame sync. This wait happens in the Oculus runtime, and they do this wait to reduce latency, maintain proper cadence, etc. In order to clarify where XRUpdate is spending its time, we have added a new profiler marker: `OculusRuntime.WaitToBeginFrame`. This is available in the Oculus XR Plugin 1.7.0-preview.1 and higher. Anyone reporting or voting on this bug, it would be great if you could try this version of the Oculus XR Plugin and verify that the time is being spent in WaitToBeginFrame. If it is, it's likely going to be related to one of the items below. If it's not, please give us feedback.

    1) If you are using minimal frame time. In this case, WaitToBeginFrame will be waiting because you're running great and it's preventing the engine from feeding it frames too fast.
    2) If you are missing framerate, even if barely, or seemingly right on the edge with maybe even a bit of breathing room.
    3) If you are experiencing highly variable frame times. In this case you might see unusual behavior where WaitToBeginFrame is taking a long time one frame, and almost no time the next. This can happen because the runtime is trying to compensate for this variable frame timing.

    For point 3, one thing we've seen is that the in-editor profiler can induce these spikes. The Unity profiler updates in the main thread, but not every frame. When it does update, you'll notice two `EditorLoop` profiler markers. The second one is the profiler updating the UI, etc. Because this is on the main thread, it causes a spike in frame time, and the Oculus runtime appears to be compensating for this, resulting in the WaitToBeginFrame timing that we see.

    In Unity 2020.1+, you can run the profiler standalone, outside of the editor process. Doing this, we aren't seeing the same spikes caused by the profiler timing.

    In summary, please try out the 1.7.0-preview.1 or higher Oculus XR Plugin and see if the WaitToBeginFrame marker is what is taking the most time. If so, this is in the Oculus runtime, and it is doing what is needed to maintain proper cadence and low latency.

    If you don't believe that you are seeing one of the 3 cases mentioned above or something similar, please let us know.

  2. colinleet

    Nov 27, 2020 19:39

    I'm glad that the "Planned for 2019.4, 2020.1, 2020.2" has been added to this page in the past couple weeks. It's a small bit of progress and hope it's fully implemented very very soon.

  3. silentslack

    Nov 23, 2020 10:01

    Please fix this, we see 10ms for XR update in a blank scene

  4. joeysipos

    Nov 19, 2020 04:51

    This is a show stopping bug for us. We cannot get over the 90fps requirement on Oculus with this bug in place. Is there a way we prioritize this higher?

  5. Miltan_

    Nov 18, 2020 17:14

    Two thirds of the budget goes away because of this issue.

  6. BATTLEKOT

    Nov 16, 2020 18:36

    Hey Hey Hey! How its going with fixing this problem? That bug in Unity for a while (since Unity 2019.4) and its still exist in new 2021.1,05A.
    Would be cool to hear news about this bug status.

  7. colinleet

    Nov 15, 2020 21:03

    This is the most upvoted active bug in the XR issue tracker. Any updates or discretion from those who can prioritize correcting bugs to address this immediately would be highly appreciated.

    Let me not mince words here: Please note that this single bug's severity is platform breaking -- not game breaking -- every game breaking. This bug's effects for Oculus are akin to covid-19's effects on the world economy. It has basically made it impossible to 1) publish any title for Oculus using Unity 2019.4+ (per their fps requirements), and 2) made every ever game which does support Oculus literally physically sickening for it's entire player and developers base.

  8. Vongsomxai

    Nov 09, 2020 02:02

    This is a big issues but seem to get ignored. We can not release any game in Oculus store because of this.(They have fps requirement)

Add comment

Log in to post comment

All about bugs

View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.