Long Waits in 0.4.3 and 0.4.4 SDK in Direct Mode Present()

[cegli]

Edit: Reposted in "Reporting Issues" forum. Seems like this forum is not checked when there is no Alpha released.

I'm working on trying to get "Direct Mode" working properly in Dolphin VR. The frame rate holds steady at 75fps in Extended Mode with no pauses.

I finally have Direct Mode displaying at 75fps, with no judder, which is great. The problem is, whenever the games starts loading something there is a long freeze somewhere inside line 399 of CAPI_D3D1X_DistortionRenderer.cpp

    if (swapBuffers)
    {
        if (RParams.pSwapChain)
        {
            UINT swapInterval = (RState.EnabledHmdCaps & ovrHmdCap_NoVSync) ? 0 : 1;
            RParams.pSwapChain->Present(swapInterval, 0);  //This line has a long pause when new scenes/large objects are loading.

This happens when I try to bring up a menu for the first time, or when the whole level changes, etc. Once the area is loaded, and you don't try to load anything else, it's very smooth.

Things I've tried:
1. Running "WaitUntilGpuIdle();" directly after, like it does in Extended Mode. No change.
2. Play with the AMD Control Panel a bit. No change.
3. Run in OpenGL mode. No change. I assume it's also pausing during present here.
4. Run everything (CPU and GPU stuff) in a single-thread, to make sure no weird mutex lock stuff was going on. No change.
5. Change Present(swapInterval, 0); to Present(0, 0), which fixes it completely, but now Vsync is off and there is tearing.
6. Change Present(swapInterval, 0); to Present(swapInterval, 1), which is supposed to be a NoWait flag. Caused everything to run at 0.5fps and caused ghosting. Not a good idea apparently...

I'm not sure how to debug further, because it appears that this is happening in the OVRDisplay64.dll at 0x7feeb9425b8(). I can't look in the .dll to debug further. It's always paused at that address though. Any ideas? Seems like a bug in the display driver, because it works perfect in Extended Mode, and also perfect with Vsync off.

My specs are in the specs post, but I have:
AMD HD7970 - Latest Drivers
Windows 7 64bit
Intel I7 3570k @ 4.4GHz.

[jherico]

If you're still using asynchronous timewarp, I'd suggest that might be the problem. Async timewarp will be great once there are GPU driver extensions that let you prioritize work from a given drawing context or thread. Until that happens though, what you get is an arbitrarily long amount of wait time on the present from the distortion call because the GPU is being saturated by calls from the rendering code.

I had the same problem when I tried to add async timewarp to my shadertoy app. My original video of the technique shows it works great when you're simulating a long rendering pipeline via CPU delays on the rendering thread, but when you actually attempt to implement it in a situation where the GPU is being maxed out, it completely falls apart, because the distortion code can no longer accurately determine how long it will take to perform the distortion.

[cegli]

Right now we've disabled Asynchronous Timewarp, because we also found it didn't work very well when the GPU was under load. I've actually gotten a "Synchronous Timewarp" (1:1 ratio to pull-up 30fps games to 60fps) to work almost perfectly, though some games require the user to tweak the timing a bit in the GUI... Not super user-friendly, but at least it works.

Anyway, this problem is just on normal games running at 75fps, with the rift also at 75fps. Wish I could see the source code for the display driver so I could find what the problem is...