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
Implement improved VSYNC estimator from Blur Busters' open source #1145
Comments
Here's the README.md:
|
Cool! Especially for potential beam racing, though also for the Qt port — which does a [terrible] attempt at the same estimation in an attempt to back-load work within frames*. There's already a mechanism in place to try to phase-lock machine execution speed to display rate if they're very similar but not exactly matched, and machines can already be run for arbitrary periods, so hopefully most of the other wiring is already in place. * i.e. it attempts to estimate: (1) standard frame duration; (2) time remaining until next end-of-frame; (3) time it seems to be taking the emulator to run for one frame; and (4) scheduling jitter. It then seeks to sleep the right amount of time to finish generating each frame as close as possible to when it'll be presented, given the potential scheduling jitter from the sleep. Which is a lot of stuff that mostly amounts to: Qt is a terrible target for anything multimedia, but best foot forwards. Though the whole precept of offering only blocking upon posting a new frame as retrace synchronisation seems to be common to many of the platform abstractions, and I'm sure there are others with the same degree of pain attached to trying to split across threads, so maybe it's worth investing properly there. |
There are several possibilities to listener into a VSYNC heartbeat;
All of this can be abstracted somewhat -- our open source module doesn't make assumptions of how you will provide a VSYNC heartbeat -- simply my module helps filter/dejitter the VSYNC heartbeat to error margins accurate enough for "lagless vsync" algorithms (like WinUAE) or at least to flywheel a CPU-clocked emulator VSYNC slowly towards a GPU-clocked realworld VSYNC. |
If you want to have precision needed for ultra-low-latency beam raced sync -- I prefer CPU busywait loops instead of sleeps. It does burn a CPU core, but it does produce massively improved precision necessary for beam-racing feats. Perhaps a configurable sleep (language native sleep, timer sleep, and CPU busyloop sleep). In Tearline Jedi, I used language sleep to 1-2ms before the sleep event, then busyloop the final 1-2ms -- and that worked fairly well. One problem is power management degrades beam racing precision. On VOGONS.org I posted an 2023 updated emulator beamracing HOWTO in response to a question to me by GloriusCow, the author of MartyPC. Relevant Updated 2023 Best Practices for emulator "lagless vsync" beam racing ala WinUAE
|
Paging @TomHarte - Time to upgrade/replace your VSYNC estimator:
CLK/ClockReceiver/VSyncPredictor.hpp
Line 24 in 3e09afb
We just released this today under Apache 2.0. A little TestUFO magic sauce, too.
https://github.com/blurbusters/RefreshRateCalculator
Our algorithm is superior, since it filters jitter better + ignores missed vsyncs (to avoid polluting the data).
Or alternatively, ad8e's cross platform VSYNC estimator algorithm.
https://github.com/ad8e/vsync_blurbusters/blob/main/vsync.cpp
The text was updated successfully, but these errors were encountered: