Poor performance with new SDK

The SDK forces VSync @ 75Hz. So if your app is running below 75fps (even by just one frame) then it will drop to 37.5fps. This is expected, and is normal. You will need to optimize your app so that you are getting well over 75fps in order to be comfortable.

But why isn´t oculus using adaptive V-Sync? I understand the reasoning about V-Sync to limit the framerate to avoid tearing but there is no reason to force V-Sync on lower framerates. That´s why Nvidia introduced adaptive V-Sync and for AMD there is a small tool to add Dynamic V-Sync control, to avoid exactly this huge performance drop from 75fps to 37fps.

Adaptive V-Sync improves the experience quite a bit, especially when used with timewarping. Instead of waiting for the application to finish rendering a frame and then display it, it could use whatever frame the application has produced so far (probably timestamped) and timewarp it as good as possible to match the current v-sync point. The important thing is not to block the application so it can continue rendering and produce a new frame. This causes every displayed frame to be timewarped a littlebit if the framerate drops below 75fps but overall you get a much smoother experience.

Optimizing the application works for games, sadly I am working on a workstation application, so there are limits to what you can do since you have no control about the content and are stuck with workstation hardware (so massive multicore CPUs with low clockspeeds and Workstation GPUs). Our application is quite optimized already though, at least it is quite a bit faster than unity on the scenes that we are using.

Kind regards
Michael

I tried to reproduce the poor GPU usage with our normal Stereo mode and just enabling V-Sync can cause the observed drop to 37fps but not the drop to 25fps and the limited GPU usage. The only way to get this was by explicitly calling glFinish, which is known to stall the pipeline and shouldn´t be used unless you need to sync different displays.

Is it possible that there is something like this happening in the oculus driver or lib?

A shot in the dark, but if you're rendering directly to the textures Oculus is supplying, you might consider rendering to your own framebuffer (as you would have been with client distortion) and then only at the end either do a texture copy or a framebuffer blit to the Oculus textures. I believe Oculus is using the DX/GL interop extensions with the texture it provides and it's possible there's some performance hit involved when writing to them.

"MichaelNikelsky" wrote:
But why isn´t oculus using adaptive V-Sync?

You're referring to two independent (but related) things: variable vsync and async time warp. The former is when vsync time is delayed when the application is taking longer to finish drawing the frame. The latter is when OVRServer dynamically time-warps based on the most recently completed frame drawn by the application. While the purpose of these two is similar -- to handle the case of the application not making a consistent frame rate -- they achieve it by different means.

There are problems with variable (adaptive) vsync. The first problem is that when the frame becomes visible it is at a time later then the application (and OVRServer time-warp) predicted. This causes a form of judder because timing isn't consistent. Consider a ball rolling across your field of view. If one of the frames was delayed by a couple milliseconds then it would appear as if the ball was very briefly stuck in one position while rolling. It would not roll smoothly.

The second problem with variable vsync is that it would result in inconsistent brightness of the display due to the fact that the Rift display runs with low pixel persistence. If the frame rate were to dynamically drop in half then the Rift display would appear considerably dimmer to the viewer.

As for async time warp, that's a topic you can read about online.

@jherico: Thanks, I will try that. Indeed, looking at it using nSight it seems like wglDXLockObjectsNV seems to be one of the last calls before our Application goes to idle and waits for the driver to return.

@paul.pedriana: Ok, I understand the reasoning about using V-Sync. As far as I figured by now the issue seems to be not the V-Sync on its own but something else happening in the library that causes the application to wait until the frame was displayed, causing the much more drastic drop to 25fps since it rips away 50% of the available GPU power.

I believe I'm seeing the same issue; simple scenes which were at 75Hz with 0.5.0.1 are only running at 37.5Hz with 0.6.0.0. I can get a completely blank scene to render at 75Hz. Unfortunately I'm not able to run nSight in order to profile wglDXLockObjectsNV. I can at least profile my ovrHmd_SubmitFrame calls and in the blank scene I'm seeing an average of 6ms but a max of about 16ms and if I sample long enough I'm seeing times that go as high as 97ms.

@ JeffBail with the upcoming 0.6.0.1 release you'll be able to use the built-in debug perf HUD to get basic information about what's going on inside the compositor service. Also, it would be useful to look at GPUView traces to see what's going on.

so when is this 0.6.0.1 update coming ? and will it fix the blank flickering screen issue

Coming shortly, but I'm not sure if that issue is fixed.