ShuriZma
/
RetroArch
mirror of https://github.com/libretro/RetroArch.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Updated Getting optimal vsync performance (markdown)

Hans-Kristian Arntzen 2013-12-17 04:18:58 -08:00
parent 7338b8aa20
commit dbdf738150
1 changed files with 4 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
Getting-optimal-vsync-performance.md

@ -6,12 +6,13 @@ It can be disabled, but be aware that proper video/audio sync is nearly impossib
## Problems ## Problems
While using RetroArch, the default settings might not be adequate, and you might experience video stuttering and/or audio crackling. For correct synchronization, `video_refresh_rate` must be configured for your monitor. It cannot be detected accuractely enough by OS-provided APIs (i.e. they tend to blatantly lie). For proper behavior, an accuracy of roughly ~0.1% is needed for dynamic rate control to smooth out the drifting. This is trivial to obtain by measuring manually under normal conditions. Without dynamic rate control one would need a "perfect" measurement which obviously isn't possible without special hardware. While using RetroArch, the default settings might not be adequate, and you might experience video stuttering and/or audio crackling. For correct synchronization, `video_refresh_rate` must be configured for your monitor. It cannot be detected accuractely enough by OS-provided APIs (i.e. they tend to blatantly lie). For proper behavior, an accuracy of roughly ~0.1% is needed for dynamic rate control to smooth out the drifting. This is trivial to obtain by measuring manually under normal conditions. Without dynamic rate control one would need a "perfect" measurement which obviously isn't possible without special hardware.
RetroArch can give you an estimate of your monitors refresh rate. Make sure VSync is enabled and working, start RetroArch directly in RGUI with `retroarch --verbose --menu`. Let it run uninterrupted for at least 4096 frames (displayed in title bar), and exit. In the log, you should see something like: RetroArch can give you an estimate of your monitors refresh rate in [RGUI](RGUI) under video settings, which is updated in real-time using a running average over frame times. Make sure VSync is enabled and working. Also make sure you're running in full-screen for more accurate results (compositors can easily interfere with timing). Press accept button on the estimated refresh rate to configure RetroArch with the estimated rate. If the running average isn't drifting much anymore, it's probably a good result.
You can also have RetroArch log the output at the end and configure things more manually. Start RetroArch directly in RGUI with `retroarch --verbose --menu`. Let it run uninterrupted for at least 4096 frames (displayed in title bar), and exit. In the log, you should see something like:
RetroArch: Average monitor Hz: 59.869485 Hz. (1.347 % frame time deviation, based on 2048 last samples). RetroArch: Average monitor Hz: 59.869485 Hz. (1.347 % frame time deviation, based on 2048 last samples).
If you're unsure about the result, run this test several times and see if the results are consistent. Some systems tend to have very unreliable VSync behavior and this result will wildly fluctuate. If you're unsure about the result, run this test several times and see if the results are consistent. Some systems tend to have very unreliable VSync behavior and this result will wildly fluctuate.
You can use this value in `video_refresh_rate` and the video and audio should ideally be butter smooth if the game's FPS and monitor FPS are relatively close to each other (playing a PAL game on 60 Hz monitor won't be perfect no matter what you do ...) You can use this value in `video_refresh_rate` and the video and audio should ideally be butter smooth if the game's FPS and monitor FPS are relatively close to each other (playing a PAL game on 60 Hz monitor won't be perfect no matter what you do ...)
## Input latency ## Input latency
@ -19,7 +20,7 @@ There have been cases reported on excessive input lag in Windows for some users.
It's not really input latency, but video driver latency. Some video drivers tend to buffer way too much in the name of increased performance. This problem is explained by Carmack [here](http://www.altdevblogaday.com/2013/02/22/latency-mitigation-strategies/). It's not really input latency, but video driver latency. Some video drivers tend to buffer way too much in the name of increased performance. This problem is explained by Carmack [here](http://www.altdevblogaday.com/2013/02/22/latency-mitigation-strategies/).
RetroArch recently got an option to use a swap/fence sync method in OpenGL driver, which is reported to greatly lower input latency ([thread](http://forum.themaister.net/viewtopic.php?id=495)). RetroArch recently got an option to use a swap/fence sync method in OpenGL driver, which is reported to greatly lower input latency ([thread](http://forum.themaister.net/viewtopic.php?id=495)).
To enable it, set `video_hard_sync = true` in config. To ensure that this sync method is actually used, make sure that you see this in the log: To enable it, set `video_hard_sync = true` in config or enable it from RGUI. To ensure that this sync method is actually used, make sure that you see this in the log:
RetroArch: Querying GL extension: ARB_sync => exists RetroArch: Querying GL extension: ARB_sync => exists
RetroArch: [GL]: Using ARB_sync to reduce latency. RetroArch: [GL]: Using ARB_sync to reduce latency.