For the past couple months I’ve been having a very weird issue with the XR Plugin Management (3.2.10) when using the Oculus XR Plugin (1.3.4) in 2019.4.1f1 (and every stable build since May 2020), wherein the EarlyUpdate.XRUpdate has been take up around 75% of the main thread’s CPU time for no apparent reason.
This is happening for me even with empty projects with just a basic XR Rig.
Dose anyone have any clue as to what’s happening with this call? It’s not actively causing me any errors… but it’s like ominously ticking black box, which I can’t look into, and it is bombing my project with bad performance.
All that I can find anywhere about EarlyUpdate.XRUpdate is a singe line from the documentation: (“Native engine system updated by the native player loop.”) From:
(View photos for timing details.)
In standalone it’s taking around 8 ms of execution time (out of my budgeted 11 ms for 90 HZ). In standalone the execution time for the EarlyUpdate seems to be trying to lock the timing of each frame to fill out the full 11 ms between frames, which is fine… basically it’s acting like a non-optional VSync which I can’t turn off. Is this guess at all accurate for why it’s taking so long? Is it waiting for a callback from the Oculus app with the new frame’s headset and controller info?
What confuses me most about this is that in-editor it’s taking around 3 ms. It’s bizarre to me that it would be over 2.5x faster with profiling on in-editor. Also I can’t for the life of me figure out why it is giving still be giving me a horrible 3 ms execution time in editor; when the editor loop itself is just as long as an entire 11 ms VR frame, which should mean that there are at least two frames worth of VR input data for every in-editor update call (no need to wait the 3 ms)… What am I missing here?
The problem isn’t too much of an issues for me at this point as I use just a couple MS for both scripting + rendering my project with HDRP at this point, but having 75% of my CPU budget going just to XR’s under-the-hood/no-peaking-at-what-its-doing-with-deep-profiling mystery update call is driving me crazy and I’m a bit afraid that it’s going to put me under impossible timing restrictions of just have 2-3 ms to do all of my scripting and rendering work in the next couple moths as I start to develop the visuals for my game.
Nope. I’m still completely stumped by this, do you think we should report it as a bug? It’s just SO BAD. Yet it doesn’t seem to have any reasonable explanation that I can fathom, and it technically isn’t producing any unexpected behavior other than being slow as hell. Turning off XR entirely makes the problem go away (of course), but I can only do that for short programming testing stents. My game’s core design is exclusively VR. I’m tempted to see if this persists with OpenVR to see if it’s just a platform dependent bug, as OpenVR can still be used on Oculus, but I want to keep support for Oculus natively as well. Have you tried it with OpenVR or any other XR platforms?
This bug is still driving me crazy. I found that upgrading to the most recent version of XR Plugin Management (3.2.13) made the editor behavior match what I’m seeing in builds much more closely in regards to extending the frames runtime to be 11.2 Ms (90 hz)… Adding more slower code to bulk up my project does seem to lower XREarlyUpdate’s runtime (maintaining 90 hz)… I’m still occasionally seeing it take 8-9 Ms in some random frames though (especially in editor)…
Came to this forum to see about this exact issue. Is there a report for it on the bugtracker yet? Since we should probably make one. Even in a bare minimum scene the EarlyUpdate.XRUpdate takes up 7 to 11ms in-editor according to the profiler.
EDIT: the XRUpdate might actually just be spinning to keep the fps equal to the headset screen refreshrate in normal operation, but the fact remains is that it’s ‘overshooting’ and lowering the framerate way below the refreshrate right now in-editor.
Just throwing another voice into the ring to say I have the same problem. Unity 2019.4.1f1, using XR Plugin Management 3.2.13 and Oculus XR Plugin preview.2 - 1.4.0 (also had the same issue when on the Verified 1.3.4).
It straight up sucks when you see that if a bug like this were only HALF as bad, I’d be able to hit my performance threshold (rn a frame takes on average 16-17ms if you include this bug), big oof. I average about 10-11ms waiting on EarlyUpdate.XRUpdate, in editor (haven’t tested a build recently, as my builds take a HOT second since this is a big project), and from the sounds of it it’d be the same in a build.
I can say I know this isn’t normal (or shouldn’t be), as with the old XR implementation, your CPU in an empty project would only be hit with 1-2ms dedicated to the VR calculations. But I’d also say that’s a given considering there’s no way they’d expect developers to make large scale VR games with only an 11.1ms budget and they use up 8-10 of those ms
It is crucial to report these issues with Unity Bug Reporter - Link here because that way it goes straight to QA and straight to the developers, if you post on the forum, they won’t have the information you send over in a bug report such as a reproducible project. If this happens in any empty project it will be very quick to reproduce in a new empty project as a bug report to send over.
Please post your case number back here too and if they give you a link to Unity Issuetracker so we can all vote on it too!
I’ll take point on this and make a bug report tomorrow. Mostly why I made this post first is so I could get input from other people to determine if this was even a bug, if it was a larger issue, and what I would even be reporting other than “there is a mystery slow ass function in my random project I can’t find anything about”.
Thank you for this update, the idea of overshooting didn’t occur to me and explains the problem we’re all seeing almost perfectly (especially with it being so random and overshooting more with more complex scenes in editor). I’ll use that description as the center of my bug report once I get a shareable bug demo project made.
Unrelated tip: If you don’t already know, closing the scene view often cuts the time of the editor loop in half (from my expense) and can often double my framerate in game… It ain’t a good or permanent fix but it’s quick and easy when you need it…
Do you have the voting page already? This bug is completely driving me crazy. My game was working wonderfully and super smooth with the old integrated VR and since I switched to the XR Plugin multiple things are just a mess (massive performance drop, right eye not rendering correctly anymore…). What in the world is Unity doing in this transition. It seems like the “old” team was let go and the new team looked at the existing code and thought “oh what the hell, why is this here, don’t know, let’s remove this weird optimization and see if somebody shouts”. A pattern I’m just too familiar when code gets handed over. Let’s start all from scratch again :-/
@LeonhardP would be great if you had the VR fixes on the radar, as I am certain you already have but just to make sure
I have still not heard anything back from the unity team… 9 days out and all my report says is that it’s “open” as of a few hours after I submitted the bug report on July 12th…
If anyone is interested in submitting a new big report I can post a link to the demo project I made, and you could check it out to see if it errors for you as well. Let me know if you would like that link. My error report was long and a bit rambling, they might react faster to something more concise… Or if multiple people start sending in similar reports…
@colinleet can you post your project and I’ll verify that it acts the same way on my rig.
I’m grabbing 2020.1 and I’ll look a the profiler and see if any improvements are present (doubtful?). I might submit a bug report on that newest release as well.
A more up to date demo report in 2020.1 would probably be a great idea. I believe I’m seeing the same but in 2020.1 as well… maybe with slightly better performance but I’m not sure.
