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

feat(server_openvr): ✨ Add "Enforce server frame pacing" #2632

Merged
merged 1 commit into from
Jan 16, 2025

Conversation

zmerp
Copy link
Member

@zmerp zmerp commented Jan 16, 2025

This is exactly the same as the old "Optimize game render latency" but with a different name to make it more clear that you don't want to touch it unless you know what you are doing

@zmerp zmerp requested a review from shinyquagsire23 January 16, 2025 21:48
@zmerp zmerp merged commit 64828ae into master Jan 16, 2025
8 checks passed
@zmerp zmerp deleted the revert-opt-rend-lat-removal branch January 16, 2025 22:51
@shinyquagsire23
Copy link
Contributor

actually I realized a bit too late, that 8ms fallback suould probably have been 1ms because now if a game runs at ie 6ms per frame, it'll get saddled with an 8ms wait every time and get worse performance. And 16ms turns to 24ms.

@zmerp
Copy link
Member Author

zmerp commented Jan 16, 2025

actually I realized a bit too late, that 8ms fallback suould probably have been 1ms because now if a game runs at ie 6ms per frame, it'll get saddled with an 8ms wait every time and get worse performance. And 16ms turns to 24ms.

I don't understand you reasoning. 8 ms is like 125hz. But now that I think about it, we should have left som room for the game render. so 1ms is probably the right thing to do

@shinyquagsire23
Copy link
Contributor

Yeah the current enforced system rounds up to display Hz increments so that if game render is 8ms on a 100Hz HMD, it waits 2ms, so 1ms is technically a perf penalty but a very small one comparatively. Arguably the wait could be dropped to a yield if the game render is more than the display vsync interval.

@zmerp
Copy link
Member Author

zmerp commented Jan 16, 2025

I don't understand you reasoning. 8 ms is like 125hz. But now that I think about it, we should have left som room for the game render. so 1ms is probably the right thing to do

No wait, I pull that back. we do fall back to 8ms per frame only when the StatisticsManager is not initialized. so in those moments there is no load in the rendering loop.

@shinyquagsire23
Copy link
Contributor

I think my original PR had an unwrap_or(Duration::from_millis(50)); for that condition specifically, so that None only applied to framepace-less settings and not no StatisticsManager. So here it'd be unwrap_or(Duration::from_millis(8)); and then 1ms in the else

@zmerp
Copy link
Member Author

zmerp commented Jan 16, 2025

Ah. I think it's better if you make another PR with the final fix

@shinyquagsire23
Copy link
Contributor

Yeah sure

@shinyquagsire23
Copy link
Contributor

Oh, lol I guess I didn't have the 50ms thing separate

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

Successfully merging this pull request may close these issues.

2 participants