Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ATW: "bubbles" of missed vsyncs in D3D11 ATW implementation #356

Open
JeroMiya opened this issue Nov 20, 2017 · 1 comment
Open

ATW: "bubbles" of missed vsyncs in D3D11 ATW implementation #356

JeroMiya opened this issue Nov 20, 2017 · 1 comment

Comments

@JeroMiya
Copy link
Contributor

This is a result of testing this branch:
https://github.com/sensics/OSVR-RenderManager/tree/nvidia-atw-updates

But it may affect the master branch as well. I'm noticing that the message that the ATW backend displays when it has missed a vsync comes in batches or "bubbles". That is, the ATW or time warp may end up taking too long and can't present in time for vsync. In this case, the inner D3D11 RenderManager instance blocks for a full frame (it reports that present takes 11ms or so) and then another message occurs. This generally results in bubbles of time where one vsync miss will itself cause the next one, and so on. Sometimes it settles down and manages to go back to hitting vsync consistently.

@russell-taylor Any ideas? I know you had a fix related to vsync misses - I'm not sure if this is related.

@russell-taylor
Copy link
Contributor

My issue relating to missing vsync was one of reporting rather than one of time bubbles. With my testing on the master branch (with only one application with a few settings, and with only one HMD), things were smooth and did not exhibit these bubbles. I did have trouble with the addition of messages causing rendering bubbles, so it is possible that the warnings themselves are contributing. We could consider printing them only once every second or so and reporting summary statistics rather than printing them at every frame skip to see if that fixes the issue -- you could check this by adding a temporary static boolean that stops printing after the first time and see if that improves the judder performance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants