I’ll see if I can write a wiki page on this topic soon, but here’s a quick general guide:[B]
Linux[/B]
Important: Run RetroArch from an X-less terminal. This requires a working DRM video driver, which most modern systems appear to have. See https://github.com/libretro/RetroArch/wiki/KMS-mode
Important #2: You may get performance issues unless you set your CPU to max frequency. This is because the CPU’s power management thinks the CPU is idle enough to be downclocked. In Ubuntu, you can run sudo cpufreq-set -g performance to do this. You may want to put this in a startup script.
In retroarch.cfg set:
video_driver = “gl”
video_vsync = true
video_threaded = false
video_max_swapchain_images = 2
video_frame_delay = See description further down
Windows
In retroarch.cfg set:
video_driver = “gl”
video_vsync = true
video_threaded = false
video_fullscreen = true
video_windowed_fullscreen = false
video_hard_sync = true
video_frame_delay = See description further down
Note on video_max_swapchain_images setting
When using the OpenGL (“gl”) video driver, this setting switches between using two or three buffers for rendering. Without going into details, a setting of 3 allows the emulator to run ahead and prepare the next frame before the current one has even been shown. This improves performance (i.e. makes framerate hiccups less likely), especially on slow hardware, but increases input lag by one whole frame in the general case.
So, the general rule is to use a setting of 2 if the system can handle it. It will shave off one frame of input lag compared to the default setting of 3. Please also note that a setting of 2 forces vsync on.
For OpenGL, this setting only applies under Linux KMS/DRM. Using “video_hard_sync = true” is similar on the Windows side.
Note on video_frame_delay setting
This setting delays the running of the emulator by the specified number of milliseconds. This sounds bad, but actually improves input lag, since it pushes the input polling and rendering closer to when the frame will actually be displayed. For example, setting video_frame_delay = 10 shaves off 10 ms of input lag.
The general rule here is to use the highest value possible that doesn’t cause framerate or audio issues. This is highly system dependent. The faster your system is and the less demanding the emulator is, the higher you can push this setting. On my Core i7-6700K, I can put this setting at 12-13 ms when using snes9x2010, but not nearly as high when using bsnes-mercury-balanced.
Please note that the frame delay value can’t be higher than a frame period (which is 16.67 ms at 60 Hz). I believe the GUI caps this setting to a maximum value of 15.
I would also advice to play with this setting last. It takes a bit of trial and error to find a good setting, and unless you’re willing to make per game settings, you might not be able to find a setting that works well in all situations while still giving a worthwile improvement.
A general note on GPU drivers
Input lag can vary depending on GPU driver, so it’s not possible to guarantee a certain input lag without testing the particular combination of hardware and GPU driver. For example, I have measured different input lag when just upgrading from one GPU driver version to another.
Note on Raspberry Pi
[SIZE=2]
The Raspberry Pi is sort of a special case. In general, it’s too slow to use anything other than the default value for[/SIZE] video_frame_delay (which is 0). Also, unless you’re using the DispManX driver or OpenGL via the experimental open source driver (VC4), the video_max_swapchain_images setting has no effect.[SIZE=2]
[/SIZE]In retroarch.cfg set:[SIZE=2]
[/SIZE]video_driver = “dispmanx” (“gl” if you require 3D acceleration or shaders. Using the default GPU driver, this will add one frame of input lag compared to the dispmanx driver.)
video_vsync = true
video_threaded = false
video_frame_delay = 0
The settings above are what’s recommended for all of those using the default Raspberry Pi GPU driver. I have some comments coming up regarding the experimental OpenGL driver.
If you’re using DispManX with the default GPU driver or OpenGL with the experimental GPU driver (VC4), you can try setting video_max_swapchain_images = 2. It will reduce input lag by one frame, but framerate will suffer unless you’re running some very lightweight stuff. It seems to work better with DispManX than OpenGL on VC4, probably thanks to lower overhead. If you want to try video_max_swapchain_images = 2 with the DispManX driver, please make sure you’ve rebuilt RetroArch after October 17 2016, since this setting wasn’t enabled on the DispManX driver before that.
Also, I would highly recommend adding the setting force_turbo=1 to /boot/config.txt when using the video_max_swapchain_images = 2 setting. This will force the Raspberry Pi’s CPU to run at max frequency at all times and has been shown to provide much better performance, since the Pi otherwise occasionally tries to downclock to 600 MHz.
Regarding accuracy vs input lag
There’s no real correlation between the two, except that accuracy usually comes with a performance penalty (i.e. frame rendering times increase). This, in turn, makes it less likely that you can use video_max_swapchain_images = 2 and high video_frame_delay numbers. I’d choose the emulator(s) I prefer/need for the games I play and then tweak the above mentioned settings to their optimal values.
) the github and issue are there: