Poor performance with Unity VR versus Oculus plugin

I had my game reliably running at 75Hz on the Oculus 0.6.0 Unity package, but now that I've switched to Unity 5.1.1p1 my performance has tanked. The profiler shows OculusWaitForGPU taking most of the CPU time, taking upwards of 19ms of a 26 ms total frame time. If I'm reading that correctly that should mean my own code should be well below the expected 13.3ms budget.

A strange thing I'm noticing in there is that Gfx.ProcessCommands is taking up exactly as much time on timeline as OculusWaitForGPU. I'm not sure what ProcessCommands does (couldn't find documentation) but I'm guess it's waiting on the GPU too?

On the GPU side, the GPU profiler shows only 25% time spent on Camera.Render, and has no entry for the rest (under "other"). If I run that under a standalone build, that time gets a name: Graphics.PresentAndVsync. I presume that means that the GPU is running idle and waiting on the CPU to feed it data.

Here's what the profiler looks like in a standalone build:


As far as I can tell, I've got a fairly well optimized application that used to reliably hit the VR target framerate on Oculus's plugin, but now that I'm working with Unity's SDK both the CPU and GPU are largely sitting idle and all but the least demanding scenes are missing the 75Hz target. What's going on here?

 

I downloaded the 6.0.1 Oculus runtime update which added "queue ahead" support which is supposed to allow greater CPU and GPU parallelism. I noticed a significant performance improvement, with a 75Hz framerate more consistently achievable in the standalone build. While still substantially below the previous performance I was seeing, it does help, and highlights just how close to the line I'm currently toeing.

Here's my best guess as to what's going on:

The current scheme is largely unparallelized between the CPU and GPU. The CPU calculations and render instructions are done, then the main thread largely just waits for the GPU job to be done before the final composition is done (excepting the time spent in Camera.Render feeding instructions to the GPU, where both start to work in parallel a little). This means that I DON'T have a 13ms budget for the CPU; I have 13 minus whatever my GPU load is going to be (so 6-7 milliseconds), minus whatever allowance I have for handling computation spikes. The queue ahead functionality of the latest runtime update allows me to reclaim a bit of that by running the next frame's calculations before the GPU is done processing. According to the Oculus docs, it gives me 2.8ms, which MIGHT mean I've got 9 ms to work with.

This is a substantially tighter window and it's still not anything like what I had before with the Oculus integration. Can anyone verify whether my above interpretation is correct, or say what's changed between now and then?

 

Well, I think I've found the change that caught me. I didn't realize that I had a different set of post processing effects on my non-VR camera and my Oculus camera setup, and when I shifted to using the Unity implementation the VR cameras were all of a sudden using the bloom shader that was on my main camera. Not having that shader on helped bring my framerate back to historical levels.