Difference between revisions of "Input lag"

From Emulation General Wiki
Jump to navigation Jump to search
(Expanded section on Windows Aero)
(Added information on Run-Ahead, some edits elsewhere)
Line 33: Line 33:
 
Use:
 
Use:
 
*Wired controller
 
*Wired controller
*Linux OS in KMS mode<ref>https://wiki.archlinux.org/index.php/kernel_mode_setting</ref><ref>https://github.com/libretro/RetroArch/wiki/KMS-mode</ref>
+
*Windows 10 or Linux OS in KMS mode<ref>https://wiki.archlinux.org/index.php/kernel_mode_setting</ref><ref>https://github.com/libretro/RetroArch/wiki/KMS-mode</ref>
 
*Exclusive fullscreen (Not borderless windowed, or windowed fullscreen)
 
*Exclusive fullscreen (Not borderless windowed, or windowed fullscreen)
*CRT TV or monitor
+
*CRT TV or monitor OR HDTV set to Game Mode receiving image at native panel resolution
 +
*Vulkan driver set to 2 max swapchain images OR OpenGL driver with GPU Hard Sync set to 0
 +
*Run-Ahead set to 1 frame
 +
*Frame Delay set as high as your system will allow
  
 
If you don't have a CRT or can't be bothered with one, you can mitigate input lag on LCDs by setting the display to game mode if available and also only pass them their native resolution.  This turns off some post-processing effects and reduces scaling delay, which both introduce lag.
 
If you don't have a CRT or can't be bothered with one, you can mitigate input lag on LCDs by setting the display to game mode if available and also only pass them their native resolution.  This turns off some post-processing effects and reduces scaling delay, which both introduce lag.
  
To disable Windows Aero under Windows Vista/7, select the Basic or Classic theme under Control Center > Personalization, or disable desktop composition under .exe properties > Compatibility. Some emulators and frontends allow you to disable desktop composition without having to switch themes. The desktop composition will also be disabled by playing under the non-windowed full-screen mode. In Windows 8 and later, the desktop composition cannot be disabled manually.
+
To disable Windows Aero under Windows Vista/7, select the Basic or Classic theme under Control Center > Personalization, or disable desktop composition under .exe properties > Compatibility. Some emulators and frontends allow you to disable desktop composition without having to switch themes. The desktop composition will also be disabled by playing under the non-windowed full-screen mode. In Windows 8 and later, the desktop composition cannot be disabled manually, so your only hope to avoid the compositing lag penalty is to play in exclusive fullscreen.
  
Triple buffering will inherently add a few frames of latency. So disable that wherever possible, either through emulator settings or driver settings.
+
Triple buffering will inherently add a few frames of latency, so disable that wherever possible, either through emulator settings or driver settings.
  
Some graphics drivers enforce excessive frame buffering, which may be eliminated with GPU commands<ref>https://www.twentymilliseconds.com/post/latency-mitigation-strategies/#toc_7</ref>. [[RetroArch]]'s Hard Sync does this.
+
Some graphics drivers enforce excessive frame buffering, which may be eliminated with GPU commands<ref>https://www.twentymilliseconds.com/post/latency-mitigation-strategies/#toc_7</ref>. [[RetroArch]]'s Hard Sync does this. If using Vulkan, be sure to set the max swapchain images parameter to 2, though weaker GPUs, especially Intel iGPUs, can struggle with this, particularly if using shaders or increasing rendering resolution.
 +
 
 +
A relatively new lag-mitigating technique known as Run-Ahead has recently been implemented in several emulators and frontends, which leverages spare performance overhead to run one or more instances of the emulator ahead of the regular instance, then uses save state rollback to lay that instance over what you see, effectively cutting a whole frame or more of input lag. Most games, even on real hardware on a CRT, have at least one hard-coded frame between executing an action on the controller and said action being reflected on screen, so setting Run-Ahead to 1 frame cuts out that superfluous frame and thus is usually considered safe, but setting it to 2 or more can result in dropped frames and perceived video stutter (though some games can benefit from 2 or more frames, particularly a lot of 5th-gen games). This is also quite processor-heavy, as every extra Run-Ahead frame requires a whole extra instance of the emulator, easily doubling or tripling CPU load, and some emulators are currently not able to use Run-Ahead at all. That said, combined with all the other lag reduction techniques on a sufficiently powerful system, Run-Ahead in theory can actually result in less input lag than even real hardware.
  
 
[[File:Vsync and Predictive Waiting.png]]
 
[[File:Vsync and Predictive Waiting.png]]
  
Some emulator frontends like [[RetroArch]] or [[GroovyMAME]] have the option to delay the processing of emulation for a few milliseconds until right before a vsync occurs, which causes inputs to be polled quickly before your display refreshes instead at the beginning of the 16.7ms (for 60 fps) vsync period. The amount of time you can use frame delay without dropping frames is dependent on the performance of the emulator on your machine. Predictive waiting may also be forced with any DirectX based program through GeDoSaTo<ref>http://blog.metaclassofnil.com/?p=715</ref>.
+
Some emulator frontends like [[RetroArch]] or [[GroovyMAME]] have the option to delay the processing of emulation for a few milliseconds until right before a vsync occurs, which causes inputs to be polled quickly before your display refreshes instead at the beginning of the 16.7ms (for 60 fps) vsync period. The amount of time you can use Frame Delay without dropping frames is dependent on the performance of the emulator on your machine. Predictive waiting may also be forced with any DirectX based program through GeDoSaTo<ref>http://blog.metaclassofnil.com/?p=715</ref>.
  
Realistically, this is the last thing to configure, after all other sync and buffer settings have been configured for your system's performance. It is possible on systems with performance much higher than is required to run at full speed.
+
Realistically, Frame Delay is the last thing to configure, after all other sync and buffer settings and Run-Ahead frames have been configured for your system's performance, as it gives the least lag reduction bang for your CPU load buck. It is possible on systems with performance much higher than is required to run at full speed.
  
 
==References==
 
==References==

Revision as of 04:00, 20 June 2022

Input lag is the delay between pressing a button and seeing the game react.[1] The potential causes for "input lag" are described below (steps which have negligible contributions to the input lag have been omitted). Each step in the process increases "input lag", however, the net result may be unnoticeable if the overall "input lag" is low enough.

Causes

Display lag

This is the lag caused by the digital televisions and monitors. Image processing (such as upscaling, 100 Hz, motion smoothing, edge smoothing) takes time and therefore adds some degree of input lag. It is generally considered that input lag of a television below 30ms is not noticeable.[2] Discussions on gaming forums tend to agree with this value. Once the frame has been processed, the final step is the pixel response time for the pixel to display the correct color for the new frame.

CRT TVs and monitors usually have no display lag, the exception being later model CRT TVs that do HD, 100Hz or 480p inputs, which use scaling. Most modern LCD monitors have very little lag, and many newer TVs also have negligible lag so long as Game Mode is turned on. This site makes it a point to test the displays it reviews for input lag, so if you're in the market for a monitor or TV and display lag is a concern, check there first.

Windows Aero

If you're using Windows Vista/7 and are playing in windowed mode, having Aero enabled will add a noticeable amount of input lag because it forces vertical synchronization at the OS-level. The same thing applies to other OSes if compositing is enabled with VSync. Aero can be disabled in both Vista and 7, thus disabling compositing and lowering input lag when playing in windowed mode, but this can no longer be done from Windows 8 onward. That said, exclusive fullscreen should automatically disable compositing on all Windows OSes, making it the preferred way to emulate in most cases.

GPU driver latency

There is video latency caused by the GL drivers in Windows/Linux. Both the GLX X11 and Windows GL/D3D drivers are full of hacks, code paths, and buffer schemes that cater to benchmarking applications and games. This is counterproductive when the aim is low-latency audio and video synchronization for emulators. You don't want all this stuff going on in the background.

Hard GPU sync options in some emulator frontends can reduce or remove latency from buffering at the possible expense of performance.

This can be avoided by using KMS and DRM/EGL, specifically on Linux. By using these modes, the user is in control of front and back buffers and don't have to rely on APIs, so that they can find where and when a frame was dropped and how to act accordingly with that in mind. It is advisable to get the latest driver to improve performance, as notable graphics chip manufacturers (e.g. Nvidia) do not find KMS a priority. Intel and most AMD graphics chips, however, should be fine regardless, but it is still advisable to update drivers.

Low-level APIs such as Vulkan give the user control over buffering and may lower latency without resource-heavy solutions like hard GPU sync. However, there is evidence that OpenGL has lower latency than Vulkan in some instances.[3]

Controller

For wired controllers, this lag is negligible. For wireless controllers, opinions vary as to the effect of this lag. Some noticed extra lag when using a wireless controller, while others didn't.[4]

Typical overall response times

Testing has found that overall "input lag" (from controller input to display response) times of approximately 200ms are distracting to the user.[5] It also appears that (excluding the monitor/television display lag) 133ms is an average response time and the most sensitive games achieve response times of 67ms (again, excluding display lag).

Ways to reduce input lag

Use:

  • Wired controller
  • Windows 10 or Linux OS in KMS mode[6][7]
  • Exclusive fullscreen (Not borderless windowed, or windowed fullscreen)
  • CRT TV or monitor OR HDTV set to Game Mode receiving image at native panel resolution
  • Vulkan driver set to 2 max swapchain images OR OpenGL driver with GPU Hard Sync set to 0
  • Run-Ahead set to 1 frame
  • Frame Delay set as high as your system will allow

If you don't have a CRT or can't be bothered with one, you can mitigate input lag on LCDs by setting the display to game mode if available and also only pass them their native resolution. This turns off some post-processing effects and reduces scaling delay, which both introduce lag.

To disable Windows Aero under Windows Vista/7, select the Basic or Classic theme under Control Center > Personalization, or disable desktop composition under .exe properties > Compatibility. Some emulators and frontends allow you to disable desktop composition without having to switch themes. The desktop composition will also be disabled by playing under the non-windowed full-screen mode. In Windows 8 and later, the desktop composition cannot be disabled manually, so your only hope to avoid the compositing lag penalty is to play in exclusive fullscreen.

Triple buffering will inherently add a few frames of latency, so disable that wherever possible, either through emulator settings or driver settings.

Some graphics drivers enforce excessive frame buffering, which may be eliminated with GPU commands[8]. RetroArch's Hard Sync does this. If using Vulkan, be sure to set the max swapchain images parameter to 2, though weaker GPUs, especially Intel iGPUs, can struggle with this, particularly if using shaders or increasing rendering resolution.

A relatively new lag-mitigating technique known as Run-Ahead has recently been implemented in several emulators and frontends, which leverages spare performance overhead to run one or more instances of the emulator ahead of the regular instance, then uses save state rollback to lay that instance over what you see, effectively cutting a whole frame or more of input lag. Most games, even on real hardware on a CRT, have at least one hard-coded frame between executing an action on the controller and said action being reflected on screen, so setting Run-Ahead to 1 frame cuts out that superfluous frame and thus is usually considered safe, but setting it to 2 or more can result in dropped frames and perceived video stutter (though some games can benefit from 2 or more frames, particularly a lot of 5th-gen games). This is also quite processor-heavy, as every extra Run-Ahead frame requires a whole extra instance of the emulator, easily doubling or tripling CPU load, and some emulators are currently not able to use Run-Ahead at all. That said, combined with all the other lag reduction techniques on a sufficiently powerful system, Run-Ahead in theory can actually result in less input lag than even real hardware.

Vsync and Predictive Waiting.png

Some emulator frontends like RetroArch or GroovyMAME have the option to delay the processing of emulation for a few milliseconds until right before a vsync occurs, which causes inputs to be polled quickly before your display refreshes instead at the beginning of the 16.7ms (for 60 fps) vsync period. The amount of time you can use Frame Delay without dropping frames is dependent on the performance of the emulator on your machine. Predictive waiting may also be forced with any DirectX based program through GeDoSaTo[9].

Realistically, Frame Delay is the last thing to configure, after all other sync and buffer settings and Run-Ahead frames have been configured for your system's performance, as it gives the least lag reduction bang for your CPU load buck. It is possible on systems with performance much higher than is required to run at full speed.

References