Forum Discussion
[0.4.3] Intermittent but severe performance issue
I'm seeing an occasional performance issue that happens at least a few times every time I run through my demo with the 0.4.3 SDK, built with Unity 4.5.5f1.
It will be running smoothly at 75 FPS (200+ without Vsync via EnabledCaps), and then suddenly halve to 37FPS (or somewhere between 37 and 75) and stay that way until I toggle Vsync off and then back on again.
According to profiler (running in the Editor), the culprit is OVR_UnityGetModeChange() in the Oculus plugin. When it's called from OVRDisplay.UpdateTextures(), It either clocks in at ~0ms, or at 7-12ms on the CPU on my GTX 660. During a simple scene, this doesn't kill my GPU, but during the main game I am seeing GPU skyrocket to 20-43ms at around the same time that there starts to be a few slow calls to OVR_UnityGetModeChange(). Switching vsync off and back on again doesn't help break out of this in the Editor.
Here's a couple of screenshots. (Right-click -> open in new tab to see the whole thing since the forum's upload feature seems to be broken at the moment)
In this first picture, the top shows the performance problem, and the bottom shows normal profiler readings. That whole spiky section of the CPU graph on the top is all slow OVR_UnityGetModeChange() calls, and the spikes themselves are when the OVR_UnityGetModeChange() takes extra long (43ms etc).
And this second screenshot has the script breakdown pointing to OVR_UnityGetModeChange() as the culprit.
I didn't see the source code for OVR_UnityGetModeChange() anywhere in the base SDK, so I'm guessing the Unity plugin has some extra logic built on top of that. Is anyone able to describe what OVR_UnityGetModeChange() is actually doing, and if not calling it would cause any serious issues?
Thanks in advance!
It will be running smoothly at 75 FPS (200+ without Vsync via EnabledCaps), and then suddenly halve to 37FPS (or somewhere between 37 and 75) and stay that way until I toggle Vsync off and then back on again.
According to profiler (running in the Editor), the culprit is OVR_UnityGetModeChange() in the Oculus plugin. When it's called from OVRDisplay.UpdateTextures(), It either clocks in at ~0ms, or at 7-12ms on the CPU on my GTX 660. During a simple scene, this doesn't kill my GPU, but during the main game I am seeing GPU skyrocket to 20-43ms at around the same time that there starts to be a few slow calls to OVR_UnityGetModeChange(). Switching vsync off and back on again doesn't help break out of this in the Editor.
Here's a couple of screenshots. (Right-click -> open in new tab to see the whole thing since the forum's upload feature seems to be broken at the moment)
In this first picture, the top shows the performance problem, and the bottom shows normal profiler readings. That whole spiky section of the CPU graph on the top is all slow OVR_UnityGetModeChange() calls, and the spikes themselves are when the OVR_UnityGetModeChange() takes extra long (43ms etc).
And this second screenshot has the script breakdown pointing to OVR_UnityGetModeChange() as the culprit.
I didn't see the source code for OVR_UnityGetModeChange() anywhere in the base SDK, so I'm guessing the Unity plugin has some extra logic built on top of that. Is anyone able to describe what OVR_UnityGetModeChange() is actually doing, and if not calling it would cause any serious issues?
Thanks in advance!
21 Replies
Replies have been turned off for this discussion
- I see that too, and noticed new CPU bottlenecks that I didn't have before.
If you comment out OVR_UnityGetModeChange() then the delay gets moved to OVRDispaly.OVR_GetRenderPose()
If you freeze TimeWarp (which avoides calling GetRenderPose), it moves to Gfx.WaitForPresent
So I guess it's timewarp related. I would worry that it sleeps the thread before my game logic happens, then I miss the vsync causing a judder.
I tried using Unity's Script Execution Order to move OVRManager & OVRCameraRig to be called after everything else, but I think that made it worse.
The other strange thing, I sometimes see the fps go above 75, that didn't happen before. - Thanks for pointing this out. OVR_UnityGetModeChange does nothing but lock and return a boolean data member from the plugin. It does sound like it's blocking on TimeWarp. We can probably eliminate some of the locking for the next release. We don't provide the source for the Unity plugin yet, but it's mainly just calling ovrHmd_BeginFrame, ovrHmd_EndFrame, and ovrHmd_GetEyePoses from the render thread with synchronization to the game thread. Are you using D3D 9 or 11?
- Great info Protonz. I confirmed what you're seeing with the bottleneck moving around.
@ vrdaveb, DX11 here. I'm glad you've got a sense of what the issue might be! - I spent a whole bunch of time on this last night, and I was going to post this exact same thing today! Drash beat me to it! :)
I used the profiler as well, but I wasn't seeing the issue at all in the editor, only the runtime (i used debug build + auto connect to profiler to find it). I used Profiler.BeginSample/Profiler.EndSample functions inserted into the OVR code to narrow it down as well to this line in OVRDisplay.cs:
needsSetTexture = needsSetTexture
|| OVRManager.instance.virtualTextureScale != prevVirtualTextureScale
|| Screen.fullScreen != prevFullScreen || OVR_UnityGetModeChange();
And then more specifically to the OVR_UnityGetModeChange() call
I basically changed that to this:
needsSetTexture = needsSetTexture
|| OVRManager.instance.virtualTextureScale != prevVirtualTextureScale
|| Screen.fullScreen != prevFullScreen;
And it eliminated the issue in my application. I don't plan on changing anything at runtime so I think this is not a big deal as it just re-inits the render textures. The profiler was showing this single call taking 7.5ms of CPU!!!! That was killing my framerate as I was already CPU-bound in my application.
ccs - Interesting side note in all of this I forgot to mention. I actually noticed this issue on my application built with 0.4.2 using the new runtimes. The performance of my application was killed using new runtime. I was freaking out! :)
During debug I tried many things, including using 0.4.3 SDK with old runtime. I was surprised 0.4.3 SDK actually worked with the old runtime and did not exhibit this performance issue. So it seems the issue is clearly in the runtime, not the SDK. The old 0.4.2 SDK also called this same OVR_UnityGetModeChange function every frame (in OVRCamera.cs).
ccs - @ccs, more great info from you. I was considering reverting to 0.4.2 SDK when I saw your post that it could be runtime related.
And it does help to remove the "|| OVR_UnityGetModeChange()" condition here as well (and no obvious side effects that I can see), but I still ran into a performance issue at one point, although it was a lot rarer than before. Currently trying to track that down so I can release something with confidence. - Hi there, i haven't had time to do any proper profiling and stuff, but just wanted to mention that several Unreal Engine 4 developers (including me) have encountered similar problems:
https://developer.oculusvr.com/forums/viewtopic.php?f=60&t=16181
Might be related! - Hi guys,
I just want to thank you for narrowing this down. Technolust is already fairly hard on the CPU with all of my video textures etc., so this issue has been killing me.
I'm not very code savvy, so the best I could tell was ( that with new revisions to the SDK) my cpu was getting bogged down more and more even though I've been constantly optimising.
Very frustrating.
Thank you again Drash et all for pinning this down.
@dave/oculus: I would kill for a hotfix. I'm a little stuck between a beta version (made with Unity 4.5.4 and ovr 4.1) that won't run under the new runtimes, or a new version that will take forever to re-rig because of the name convention changes and runs like crap.
♥ - I experience this issue as well. After installing the sdk 0.4.3, framerate drops in some places to 30. With the 0.4.2 sdk i had a smooth FPS of 75.
Glad to see other people experience this as well, and it is not my project that is causing this FPS.
