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
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)
-
luminator
Feb 23, 2021 09:51
Any updates on this? I'm running autoconnected profiler directly from Oculus Quest 2 and while the apk is running, the EarlyUpdate.XRUpdate is taking 25.58ms !!! The rest of the apk is taking 11.3ms, so if not for this I'd easily have stable 72 fps instead of current 26/28fps. Worth noting that I'm running my apk on Vulkan, with URP and Oculus XR Plugin 1.7.0 + XR Plugin Management 3.2.16
-
EusebiuMarcu
Dec 25, 2020 13:37
I tried with an older version of Unity (2019.4) with legacy XR and Oculus Integration v15(?) (OVR 1.46.0) and the FPS is still low (on same Oculus App v24 and Oculus Quest v23). This wasn't the case before the update of either Windows 10 (20H2 from 1809), NVidia Drivers (v460.89 for GTX 1070) or Oculus Quest/App.
Since it works fine (i.e. 80-90 FPS) the first time I start the app (Unity, Oculus App/Link) I tend to believe that is the latest update of Oculus Quest.
The issue is not present if I build & run directly on the Quest (Android Player). -
TeorikDeli
Dec 24, 2020 09:35
By Design? Wow...
-
EusebiuMarcu
Dec 22, 2020 10:27
Still happens on Unity 2020.2 with Oculus Integration 20.1, Oculus XR Plugin 1.7.0 preview 2.
-
SOICGeek
Dec 22, 2020 01:15
I'm using Unity 2020.1.17f1, and I'm seeing spikes on EarlyUpdate.XRUpdate both in the editor and in standalone. I upgraded to the 1.7.0 preview of the Oculus XR plugin, but I'm not seeing any new markers registering in the profiler - it still says EarlyUpdate.XRUpdate.
I'm not 100% sure that it's the same bug - the spikes are very frequent (every 10-15 seconds or so) and the spike is on the order of 100-300 milliseconds, which is a lot bigger than others who are reporting, and as mentioned, I'm seeing the same spikes in standalone. At this time, I can't deliver this to my client.
This is on a 10-core i9, 64G memory, RTX 2080-Ti, M.2 SSD, so if anyone tells me my computer isn't fast enough, I'm going to laugh in your face. :)
-
DevinW
Dec 17, 2020 15:35
Hopefully this is resolved soon.
-
TeorikDeli
Dec 10, 2020 11:44
I tried the new Oculus 1.7.0-preview2 package and standalone profiler in 2020.2.0.b14 (HDRP 10.2); but still have XRUpdate spikes regularly (10+ ms with i9-9900kf + 2080s). It might be better than 1.6.x version, but not sure yet. I have not seen any OculusRuntime.WaitToBeginFrame spike.
-
jj-unity
Dec 09, 2020 10:57
One additionaly comment, this new profiler marker will only show up in 2020.1 and higher, because the profiler interfaces weren't exposed to plugins in 2019.4.
-
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.
-
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.
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Long Prefab save times when using Unity 2022.2 and higher
- Console displays error "UnityException: Creating asset at path Assets/Scenes/ .scenetemplate failed." during scene template saving
- "Development Build" watermark is shown in non-development UWP release builds
- Console errors appear when the Inspector is set to Debug and a GameObject is selected
- A script public variable value is not used when set in the Inspector window
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.