Mirroring on the desktop introduce frame drops

Mirror Texture sometimes has same effects, it is even worse in OpenGL (compared to DX)

I haven't experienced this issue by rendering a third view with a swap chain to a window. Make sure to call present with a syncInterval of 0 so that it doesn't wait for VSync. Perhaps you can try the latest version of Virtual Desktop and enable "Mirror to Monitor" and see if it works.

In Windows 7 you would get frame tearing but on Win8 and Win10 it is hitch free.

Obviously, i forgot to state that no, i do not Present vsync locked, nor have the nvidia driver forcing it.

I will do more test next week, GPUView should show me what happen. I am on multi monitor setup, this can mess thing around too ( One 4k 60Hz and one 1440p gsync 144Hz, the main monitor is the gsync one but the window was on the 4K one ).

The solution may be to play with separate device and share handle to copy around things to keep each free of bad interaction, could also lead to an async time warp mode so, will not be lost. Or a simpler trick would be to go fullscreen, that allow a real swap discard.

Not calling Present at all, in my current environment - it is much more high level abstraction and i am happy to have any low-level access to some textures at all...

"thewhiteambit" wrote:
Not calling Present at all, in my current environment - it is much more high level abstraction and i am happy to have any low-level access to some textures at all...

Typical, Monday morning, boot the computer, problem vanished... Thanks but no thanks windows :)

In case people are interested, A stutter as hell sometimes, B is perfect.

A.
ovr_SubmitFrame
Present(0,0)

B.
Present(0,0)
ovr_SubmitFrame


It is also worth noticing that even if i stop calling ovr_SubmitFrame, the Present cap to 75Hz, and whatever i am windowed, fullscreen, gsync or not.

I read that in the past, there was a property to turn off vsync but there is no anymore ? people confirm ? That's a little annoying to measure app performance.

@galopin

calling A and B in a loop is basically the same, so this seems to be a timing problem...
What has this monday morning to do with me not calling any direct present operation (my environment has a locked representation of a present node for the current renderer (D3D or OpenGL)). But it can also have stuttering sometimes with the mirror texture in use.

PS: the ovr_SubmitFrame is nailed to 75Hz V-Sync now. At least I would love to be capable to overdrive the input. Once had an own renderer, running at 500Hz - this was better than TimeWarp. Even if a non-v-sync tearing would appear, this was caused and therefore virtually corrected by the head movement. Think about it ;)

"thewhiteambit" wrote:
so this seems to be a timing problem...

Everything is about timing, Present is also the black box that hide most of the driver stuff. Optimizing most d3d call is for glory when they are just lazy calls and your Present is milliseconds fat to resolve them in an obscure way.

A is the order samples of Oculus use, and it is logical as the mirror texture is update from submitFrame, but in my case B is better, and not calling Present spare a little more cpu time.

While profiling either way, i can see submit and present to take quite some times, submit is understandable because of the vsync, but present should not when it arrives second as the frame should have been flushed already. I need to do some more testing with forced call to ID3D11DeviceContext::Flush.

My attempt to GPUView capture did not help because it slowdown the app too much and so drop vbls, i need to see if i can lower the capture overhead.

May also be some bad interaction of queueahead and dxgidevice::setmaxframelatency.

It would be nice to have a waitable submit frame like we have with the swap chains setup with DXGI_SWAP_CHAIN_FLAG_FRAME_LATENCY_WAITABLE_OBJECT.

Anyway, it will be for next year, happy holidays :)

Guess it is a problem of virtually concurrent access. For me this problem is not very important right now, since it has been rarely observed only (just wanted to share there is another person aware of the problem. this can help often), and I guess it will resolve with improved Runtime/SDK.

To resolve it I would try to have two separate devices with a DXGI shared surface. Then I would just instantly copy the mirror texture after ovr_SubmitFrame, free the mutex and handle everything else to render the mirror texture to screen on the other device/thread. This worked out very well with many threads on another project, you need some memory, but have only very short access to the original mirror texture resource