Forum Discussion
Multiple windows and vsync
My primary monitor is 60hz. When rendering to a single window I call ovrHmd_SubmitFrame(), blit my mirror texture to the window and then call SwapBuffers(). This works well when vsync has been disabled with wglSwapIntervalEXT(0) as I can perform 75 buffer swaps per second. When I render something to a second window (on the same thread) which therefore requires a second call to SwapBuffers() afterwards, I get limited to 60 buffer swaps for both.
It seems as though the SDK may turn on vsync internally, but with multiple windows this causes issues. What's interesting though is that forcing vsync off in the Nvidia settings allows me to swap 75 times for each window with absolutely no side effects at all (no tearing which is great, and I'm guessing the SDK is limiting it to 75 due to internal timing with the headset or whatever). This is in both direct and extended mode.
I have a few questions:
- Am I right in thinking that the SDK enables vsync internally?
- If so, is it necessary, especially as when forcing it off allows multiple windows to swap as many times as they need without issues?
- Does the SDK internally limit to the timing of the headset (i.e. if I have a 120Hz monitor, would the 75Hz of the DK2 limit the number of SwapBuffer() calls I can make on the monitor with vsync forced off on the same thread)?
It seems as though the SDK may turn on vsync internally, but with multiple windows this causes issues. What's interesting though is that forcing vsync off in the Nvidia settings allows me to swap 75 times for each window with absolutely no side effects at all (no tearing which is great, and I'm guessing the SDK is limiting it to 75 due to internal timing with the headset or whatever). This is in both direct and extended mode.
I have a few questions:
- Am I right in thinking that the SDK enables vsync internally?
- If so, is it necessary, especially as when forcing it off allows multiple windows to swap as many times as they need without issues?
- Does the SDK internally limit to the timing of the headset (i.e. if I have a 120Hz monitor, would the 75Hz of the DK2 limit the number of SwapBuffer() calls I can make on the monitor with vsync forced off on the same thread)?
7 Replies
- So I overclocked one of my monitors to 90Hz and tested the 3rd question, and was limited to 150 buffer swaps (75 each), even when forcing vsync off. Searching around the SDK I found references to the WGL_OML_sync_control functions which I'm assuming are what is causing the SDK to limit internally to 75 buffer swaps. I was hoping the compositor process would have a separate context/some magic and be swapping on a separate thread (I'm not sure how it handles multiple applications).
At the very least though, when using multiple windows, limiting the number of buffer swaps of a higher frequency monitor to the frequency of the Rift is better than limiting the Rift to the frequency of a slower monitor, so turning vsync off would be good. I tried setting ovrHmdCap_NoVSync but it didn't do anything, unlike forcing vsync off in the Nvidia control panel. - Could an SDK developer help out with the first 2 questions?
- So, the extension looks like it's per GL context, and it's not well documented what happens when you switch GL contexts (whether the setting persists or not). It's very likely you just need to reapply the wglSwapIntervalEXT() call after you change contexts. Either way, it's not the SDK that's modifying the VSync behavior. Hope that helps.
- Huh, that's really strange, I tried it today and I'm getting the 150 buffer swaps that I expected (and double checked that I'm not forcing vsync off in the Nvidia control panel). I've not made any code change so I am a bit confused, but either way thanks for replying as it prompted me to go and test again. I'll update this thread if I find out what I did differently!
As a side question, since the SDK doesn't modify vsync state, what does the ovrHmdCap_NoVSync flag do? "cybereality" wrote:
So, the extension looks like it's per GL context, and it's not well documented what happens when you switch GL contexts (whether the setting persists or not). It's very likely you just need to reapply the wglSwapIntervalEXT() call after you change contexts. Either way, it's not the SDK that's modifying the VSync behavior. Hope that helps.
V-Sync behavior is always context specific. If the user has multiple windows you need to disable or enable vsync for each of them independently. This is literally the first sentence in the spec after the overview:wglSwapIntervalEXT specifies the minimum number of video frame periods per buffer swap for the window associated with the current context.
"Rajveer" wrote:
As a side question, since the SDK doesn't modify vsync state, what does the ovrHmdCap_NoVSync flag do?
The SDK doesn't modify vsync state for your window. Specifically, v-sync is associated with a given OpenGL context and everything the SDK does is in another context. What ovrHmdCap_NoVSync does is tell the SDK not to use v-sync for it's own context, which it's using to render to the display. So technically I believe it means that ovrHmd_SubmitFrame won't block till the next HMD refresh, which it otherwise would.- Excellent, thank you both for the help, and thanks jherico for linking to the documentation. I used to activate the context and draw per window, and then set vsync and swap buffers per window at the end. You helped me realise that by not activating the context before setting vsync and swapping per window that wglSwapIntervalEXT() was only going to affect the last-drawn window (duh! :roll:), so thanks :)
Interestingly I still can't see any effect when setting ovrHmdCap_NoVSync.
