ATW not operating as expected with example programs on DK2/GeForce 1080

[russell-taylor]

When ATW is run using the Oculus_ATW.json configuration file that has a 0ms maxMsBeforeVSync (the one installed with the RenderManager version 0.6.52), both the RenderManager D3DATWDoubleBufferExample program and the RenderManagerOpenGLHighPolyTest example programs operate at half update rate and display errors about missed rendering each frame.

When run using the Oculus_ATW.json configuration file in today's master in the installers directory that has a 5ms wait, they both render smoothly in ATW but the rendering update rate is very slow (less than 1 frame/second and sometimes 1 frame every 10 seconds).

Windows 10, nVidia driver version 385.69.

[russell-taylor]

The version installed with 0.6.52 runs mostly smoothly, with frame jitter from time to time, at between 75 fps and 90 fps.

[russell-taylor]

PresentRenderBuffersInternal() hangs waiting for the lock on mutex mLock.

[russell-taylor]

Adding a debug print statement in the block at line 320 that is checking the timing info to see if it is time to present causes things to render smoothly and continuously for the HighPoly test with no command-line arguments. Perhaps it is always thinking that it is time to present and therefore not leaving the mutex unlocked long enough for the rendering thread to get ahold of it.

[russell-taylor]

Indeed, the nextRetrace values are almost always 0 seconds and a negative small number of microseconds (hundreds). Sometimes they are 7-11 thousand microseconds (as expected) and there appear to be render skips when they are over 10k microseconds (10ms). nextRetrace should never be negative...

[russell-taylor]

Modifying the nVidia DirectMode driver so that it ensures that we're using the most-recent vertical retrace (rather than the previous one) by skipping refresh rates until retrace is less than the refresh interval fixed the problem for the HighPoly example with the default number of triangles and for the D3D ATW test.

[russell-taylor]

There is still fairly frequent missed-deadline judder for the case of 4e5 polygons (rendering at around 59fps, whereas the default was around 200fps). For 4e6 polygons, the rendering rate was 8fps and there was almost constant judder.

[russell-taylor]

With maxMsBeforeVSync of 9ms, the 4e6 polygon case still has quite-frequent frame missing (showing up as judder). The 4e5 case has several-second period of glitch-free behavior interleaved with periods with a few or a lot of missed frames. The same is true for 11ms.

[russell-taylor]

Even when we skip the copying of the rendered buffers into the renderBuffers[i].D3D11->colorBuffer structure, we get blips in rendering from time to time when doing 4e5 polygons. When doing 4e6, it is pretty much continuous. This was tested by putting in code to skip the texture copy all but 1 time in 100 in the PresentRenderBuffersInternal() function.

[russell-taylor]

The high-priority context flag is being set before creating the harnessed ATW context. Switching from the deprecated function to the non-deprecated NvAPI_D3D1x_CreateLowLatencyDeviceHint() and re-running with 4e6 polygons fixed the problem for the case where we only rarely did the copy. It also fixed it for the case where we're always rendering.

Looks like the function was deprecated for good reason!

[russell-taylor]

This is fixed in pull request https://github.com/sensics/OSVR-RenderManager/pull/353