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

Limit each frame ms time on WaitForSingleObject #3

Closed
MolotovCherry opened this issue Sep 13, 2023 · 2 comments
Closed

Limit each frame ms time on WaitForSingleObject #3

MolotovCherry opened this issue Sep 13, 2023 · 2 comments
Assignees
Labels
awaiting feedback Feedback is required to proceed good first issue Good for newcomers

Comments

@MolotovCherry
Copy link
Owner

MolotovCherry commented Sep 13, 2023

Currently hard coded to 16ms, which is fine for 60hz. We should share the monitor's refresh rate over and wait for the maximum of 1 frame for the refresh rate. Not a big deal right now, but could be a good optimization

It's not clear whether making such a change would result in any actual performance improvements, so this issue remains open until a resolution is found.

So far seems to be fine without any change

@MolotovCherry MolotovCherry added good first issue Good for newcomers awaiting feedback Feedback is required to proceed labels Oct 8, 2023
@MolotovCherry MolotovCherry self-assigned this Oct 26, 2023
@TsuZing
Copy link

TsuZing commented Dec 21, 2023

Is this the reason for performance decline? I'm streaming game on 120Hz virtual display, game's fps doesn't reach 120fps and unstable. Keep game running and press Win+shift+← to switch game to physical display, game can stable at 120fps.

@MolotovCherry
Copy link
Owner Author

MolotovCherry commented Dec 21, 2023

Is this the reason for performance decline? I'm streaming game on 120Hz virtual display, game's fps doesn't reach 120fps and unstable. Keep game running and press Win+shift+← to switch game to physical display, game can stable at 120fps.

No, I highly doubt it. That is a 16ms maximum wait time (timeout). That is, it will go return when ready even before. Do keep in mind that performance "optimizations" don't always result in performance, but can actually result in worse performance. Testing would have to be done (and it works great for me, so I have nothing to test with)

... But in either case, the current driver has other performance optimizations which aren't present in the stable version. Particularly under high CPU load (which is likely your case). This had to do with setting up AvSetMmThreadCharacteristicsW for the thread under load

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting feedback Feedback is required to proceed good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

2 participants