Skip to main content
Anonymous
September 24, 2015

5.1.2p2 -> 5.2.1f1 - Large Performance Loss

Long post short (i.e. tl;dr;): Avoid 5.2.1 for now. Major performance loss. I'm sure nobody will read the rest of this since Oculus Connect is happening now, but if you want more details, read on!

Just a heads up for those who are tempted to try 5.2.1 that came out 2 days ago. I'm seeing a large performance drop, similar to what was seen when moving to 0.1.0 utils and away from legacy integration. That performance drop was fixed in 5.1.1p3 -> 5.1.2p2, but now something worse seems to have happened 5.1.2p2 -> 5.2.1f1.

I had previously posted these "benchmark" results in the "Oculus Utilities for Unity 0.1.0 Beta released" topic when I was seeing issues with 5.1.1p3 + 0.1.0 utils. This benchmark is a measure in ms of how much CPU time is left for your own scripts outside of rendering a fairly complex scene. I put this together so I could track how Unity + Oculus runtimes improved or degraded over time. It involves a script that acts as fake CPU load, that allows adjusting ms of CPU load until frame skips and judder kick in. This essentially calculates the performance overhead you have. Here were my previous results from the other post:

5.1.1p3 + 0.1.0 Utils: 6.0ms
5.1.1p3 + 0.5.0.1 Legacy Integration: 9.0ms
5.1.2p2 + 0.1.0 Utils: 7.9ms
5.1.2p2 + 0.5.0.1 Legacy Integration: 9.0ms

New data for 5.2.1:
5.2.1f1 + 0.1.0 Utils: 4.0ms

Not good. Can't do much with 4ms of CPU time. I'm rolling back to 5.1.2p2. Unfortunately this means the 0.7 features can't be used as that is what 5.2.1 offered up:

http://unity3d.com/unity/whats-new/unity-5.2.1

VR: Oculus: Upgraded to 0.7 dependencies.
VR: For Windows Oculus Development, the Oculus 0.7.0.0 runtime is required in order to run in VR mode. Future releases will also require this runtime going forward.

I did verify the performance monitor HUD is working now in 5.2.1f1, but unfortunately it just tells me the performance sucks. :)

I'm starting to cringe every time a new SDK version and/or Unity version comes out.

ccs
    This topic has been closed for replies.

    58 replies

    Show previous replies
    Anonymous
    November 12, 2015
    I tried a couple more queue ahead values by editing OVRManager.cs to change it to see what would happen:

    5.2.2p1 (0.1.2 utils - queue ahead 1.0) 7.2ms
    5.2.2p1 (0.1.2 utils - queue ahead .25) 7.1ms
    5.2.2p1 (0.1.2 utils - queue ahead .1) 4.2ms
    5.2.2p1 (0.1.2 utils - queue ahead 0) 4.1ms

    ccs
    vhamm
    Participant
    November 12, 2015
    There seems to be a lot of factors a play here. Just ran a new batch of tests with the exact same scene, just toggling queue ahead tickbox in the component, and I get the following:

    5.1.3.p2 (0.1.2 utils, queue ahead enabled): 7.85
    5.1.3.p2 (0.1.2 utils, queue ahead disabled): 7.85
    5.1.3.p3 (0.1.2 utils, queue ahead enabled): 5.75
    5.1.3.p3 (0.1.2 utils, queue ahead disabled): 7.70

    So, I'm still seeing a slight perf impact on p3 without queue ahead (~0.15ms), but the big gap for me is really the queue ahead tickbox.
    There might be some other parameter I'm missing, so would it be possible for you to send me your exact scene you used in your latest test batch, and let me know what version of the runtime you're currently using?
    I will do another batch of tests with 5.2.2.p1 with your scene to see if I see the same difference.

    -Vincent
    Anonymous
    December 11, 2015
    Vincent informed me there was a new patch release of Unity out today that he thought addressed this issue. Not only does the new patch address the original performance degradation, it goes WAY past the previous high performance. Don't walk, but RUN to get the new 5.2.3p3 patch release!!!!!

    In case you need more convincing:

    Nvidia driver 358.78 & Runtime 0.8
    5.1.3p2 (0.1.0 utils) 9.6ms (previous best)
    5.2.2p1 (0.1.0 utils) 7.2ms
    5.2.2p1 (0.1.2 utils) 7.1ms
    5.2.3p3 (0.1.2 utils) 11.8ms (new best by FAR!!!!! Holy Crap!)


    Patch 5.2.3p3
    Released: 10 December 2015


    Improvements

    VR: Optimized Oculus to start CPU work for next frame while Rendering the current frame.

    Fixes

    (749329) - VR: Fixed a crash when trying to toggle showDeviceView to false before first Update.
    (748988) - VR: Fixed an issue where Oculus was starting while building the standalone player while Virtual Reality Supported is true.
    (750510) - VR: Fixed an issue where showDeviceView was not caching between runs in the Editor. Now forces to true on play.

    Well done Oculus! Big day for you with this + Eve Valk announcement!
    SvenViking
    Inspiring
    December 11, 2015
    Excellent! Sounds like it's probably back to the performance level of some of the 4.x/5.0.x versions. Thanks for running the tests and letting us know!
    Scorched Battalion - VR Jam edition available for Gear VR and DK2 (Win/Mac/Linux) Jungle Juice Sven Co-op
    sh0v0r
    sh0v0r
    Up and Coming
    December 12, 2015
    I can concur, performance is great now!

    Still hoping to see even more gains with the talked about instanced rendering.
    Anonymous
    December 12, 2015
    I tried it out on my real project, and found similar results. I got back about 2ms of overhead (2.7ms -> 4.5ms) which is very comforting. My only concern is in the profiler it looks like the render thread is blocked/fully scheduled. I see this in a brand new project with just OVRPlayerController prefab dropped in an otherwise blank scene:

    renderthread.PNG

    In my real project, I use a number of compute shaders, and I used to be able to see Gfx.ProcessCommand bubbles for these on the timeline on the render thread where the commands were processed during BehaviourUpdate. Now it appears they come after OculusWaitForGPU as one block of commands, but it isn't super clear since you can't see details inside Gfx.ProcessCommands. It doesn't seem to be an issue, but I thought I would mention it in case someone could explain what is going on here with the giant block of Gfx.ProcessCommands on a nearly blank scene.

    ccs
    vhamm
    Participant
    December 14, 2015
    My guess here is that the GPU is waiting to present the previous frame, so new gpu processes will have to wait for the present to happen before they can be executed (in your case, the compute shaders).
    In the old way, updateBehaviour would happen after on the main thread after the GPU present happened, so the GPU would be already free at that point and execute the compute shader right away. Now the updateBehaviour happens earlier in parallel with previous GPU frame, so your compute shaders gets queued up, and have to wait for the previous frame present to happen.

    Assuming my guess is correct, this should still be a win for you, as updateBehaviour will still have much more free time. Unless you wait for compute shader completion in updateBehaviour. In that case, your perf gain would be margnial (but still a bit better than before).
    Anonymous
    December 14, 2015
    Hi Vincent-

    Your explanation makes sense, and I am glad to see this. It allows more CPU/GPU parallelism. That is obviously the cause of the performance improvement we are all seeing. Well done! :)

    Old:
    Physics -> BehaviourUpdate & Compute Shader -> LateUpdate & Compute Shader -> CPU Render -> GPU Render -> WaitForGPU(Present Frame)

    New:
    Physics -> BehaviourUpdate -> LateUpdate -> WaitForGPU(Present Frame) -> CPU Render -> Compute Shaders -> GPU Render

    In the old way, the CPU was sitting there waiting on GPU before it could start next Unity frame (Physics -> BehaviourUpdate). In new way, CPU is released to start next frame work. Does Queue Ahead have any functionality in this new way? The toggle doesn't seem to make any difference anymore.

    In my case I don't wait on the compute shaders (generally a bad practice since fetch from GPU is horrendously slow). The compute shaders feed input data directly into regular GPU shaders and that order is still preserved and doesn't cause a performance issue.

    ccs
    Terms & ConditionsAccessibility statement