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)
-
superstream1
Jun 16, 2023 09:49
For anyone facing EarlyUpdate.XRUpdate takes Massive CPU time issues in the future (mine took 800 ms +)
My Solution:
*** 1. Update All of your graphic drivers (if you have more than one including Onboard Graphic Driver (Important) in your laptop)2. Update Oculus ADB Driver (not sure if this is related but I also updated it)
3. Update Oculus SDK (in my case) and XR plugin management
My Problem:
EarlyUpdate.XRUpdate takes Massive CPU time issues (mine took 800 ms +) only in the buildMy Environment:
1. 2 graphic cards on the laptop 1. Onboard: AMD Radeon Graphics Processor (0x1638) 2. Dedicated: NVIDIA GeForce RTX 3060 Laptop GPU
2. Build for PCVR Quest 2
3. Unity 2022.3.0 / Oculus XR plugin 4.0.0 / XR plugin management 4.3.3 -
Siba_M_M
May 10, 2023 05:33
I'm still facing this issue with Unity 2021.3.18
XR management Plugin 4.3.1
Oculus plugin 3.2.3
When should we expect the fix? -
hanisherif1997_unity
Feb 12, 2023 14:18
This issue still persists in my project
unity: 2021.3.4
XR plugin: 4.2.1
Oculus XR: 3.2.2Can't believe there is still no working solution for this after all these years. This issue was raised in 2019. Would love a fix for this
-
Wanyudo
Jan 20, 2023 16:01
It seems that this issue might be connected with URP and MSAA.
I noticed this Issue on the Pico 4 with URP in Unity 2021.3.11f.
Turning on any level of MSAA leads to an appearance of seemingly needless EarlyUpdate.XRUpdate that takes 50-80% of every frame.I am still in the process of verifying if this is Pico Specific (my quest does have the same issue, but it does not seem to be solved by removing MSAA).
According to the Pico Documentation, MSAA in URP in Unity 2021 creates drops in FPS.
@Unity if i can provide more detailed information to specific areas, please reach out to me. -
Mikedegianthobbit
Oct 26, 2022 02:35
Running at 500fps on a low-mid tier pc in editor. 50%, at least, of my frame time is in OculusRuntime.WaitToBeginFrame. IDK if its unity or meta's issue but its crippling game development. Can't launch the game, can't get revenue for meta's or make money to pay to unity.
2021.3.11f1, URP 12.1.7
can hit 90fps for a moment in build but as soon as the player starts looking around it tanks to 45ish. Would be nice if the forced v-sync just dropped to the next frame rate level instead of -50% -
icormier
Aug 18, 2022 16:01
I have noticed that I can easily trigger this issue by change MSAA to 8 and Pixels per Display to 1.5 on Oculus in my game. it is cause huge performance drop and I am running this on a 3080. In the profiler it take more then 90ms
-
ArthurRibeiro
Aug 04, 2022 17:53
Any news on this? I am currently wasting 17.82ms on OculusRuntime.WaitToBeginFrame alone, 60 ~ 80% of my frame time is just this.
I profiled on a oculus build directly, so no editor influence.
My scene is super small, never going over 30 drawcalls.Everything is up to date:
- Unity 2021.3.7
- XR Management: 4.2.1
- Oculus Plugin 3.0.2 -
jeyalakshmi_chandrasekaran
Aug 04, 2022 07:12
Facing the same issue with EarlyUpdate.XRUpdate, which is taking up to 8.72ms. Is there any fix for this issue?
PS: I'm using Unity 2020.3.25, and Oculus XR plugin 1.11.2 -
jana553
Jul 09, 2022 03:54
Any update on this issue?
I am still facing this problem in the Unity 2021.3.4f1 version, with the Oculus XR plugin v3.0.2 and Oculus Integration SDK version v41. Is there any solution to the problem (or) a setting we can tweak to decrease the time consumed by EARLYUPDATE.XRUPDATE ?I am using a fixed timestep value of 3 ms and targeting for a 90 FPS
-
cnw_1
Sep 01, 2021 14:54
I am making a VR project where I am also getting spikes averaging around 9ms per frame from EarlyUpdate.XRUpdate in build and standalone profiler which is by far the largest performance hit. I am getting around 80 fps at the moment but need to get it to a stable 90 fps as the project progresses and many more features are added.
I am running an Oculus Quest 2 via link cable to an MSI GP66 Leopard (i7, RTX 3070). Unity 2021.1.13 with Oculus plug in 1.9.1
It would be great to have this looked into further.
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
- “Readme” Asset is unreadable in the Inspector window when switching Editor Theme to Light
- “NullReferenceException” error thrown when switching Editor Theme to Light if “Unity Version Control” tab is enabled
- A Warning is displayed in the Inspector when a Mesh with any Material is added as a Terrain Detail
- [Android][Vulkan] Memory leak when playing and stopping a video using the Video Player on some devices
- Caret moves by a character when typing "." and any number into 'Grid and Snap' toolbar's input field
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.