Editing Input lag
Jump to navigation
Jump to search
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.
The edit can be undone.
Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 1: | Line 1: | ||
'''Input lag''' is the delay between pressing a button and seeing the game react.<ref>http://www.anandtech.com/show/2803</ref> 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. | '''Input lag''' is the delay between pressing a button and seeing the game react.<ref>http://www.anandtech.com/show/2803</ref> 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 modern displays/televisions/monitors (due to the nature of the digital technology). [[Wikipedia:Digital_image_processing|<abbr title="Shouldn't be confused with analog image processing.">Digital image processing</abbr>]] (such as upscaling, motion smoothing and edge smoothing etc.) takes time and therefore [https://www.rtings.com/monitor/tests/inputs/input-lag#why-there-s-input-lag adds some degree of input lag as well]. Once the frame has been processed, the final step is the [https://www.rtings.com/monitor/tests/motion/motion-blur-and-response-time pixel response time] for the pixel to display the correct color for the new frame. | ||
+ | |||
+ | Analog [[Display FAQ#CRT TVs|CRT TVs]] and [[Display_FAQ#CRT_monitors|VGA CRT monitors]] have nearly zero display lag, due to the nature of the technology, the exception being later model CRT TVs (HD CRTs) that do digital image processing such as High-Definition/HD, 100Hz/doubling the scanrate or 480p inputs, which use scaling. | ||
− | + | Having said that most modern "gaming" LCD monitors have "low enough" <abbr title="Shouldn't be confused with Display Lag though.">'''input''' lag</abbr>, and many newer TVs also have negligible '''input''' lag so long as '''Game Mode is turned on'''. [[Input_lag#External_Links|These websites]] makes it a point to test the displays it reviews for display and input lag, so if you're in the market for a monitor or TV and display lag including input lag is a concern, check there first. | |
− | + | ||
− | + | ===[[Wikipedia:Compositing_window_manager|Compositor]]/Windows Aero=== | |
+ | If you're using Windows Vista/7 and are playing in windowed mode, having [[Wikipedia:Windows_Aero|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 due to [[Wikipedia:Windows_Display_Driver_Model#WDDM_1.2|WDDM 1.2+]]. That said, exclusive fullscreen should automatically disable compositing on all Windows OSes, making it the preferred way to emulate in most cases. | ||
+ | |||
+ | 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. | ||
− | + | ===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 [[Wikipedia:Mode_setting|KMS]] and [[Wikipedia:Direct_Rendering_Manager|DRM]]/[[Wikipedia:EGL_(API)|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.<ref>[https://developer.nvidia.com/blog/understanding-and-measuring-pc-latency/ nvidia: Understanding and Measuring PC Latency]</ref> 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.<ref>https://forums.libretro.com/t/an-input-lag-investigation/4407/291</ref> | |
− | |||
− | |||
− | + | ===Controller/Input=== | |
− | + | When it comes to input delay of input devices most important thing usually is [[Wikipedia:Keyboard_controller_(computing)|input controllers]] (ASICS/MCU/[[Wikipedia:Embedded_controller|ECs]]), [[#External_Links|sensors]] and [[Wikipedia:Miniature_snap-action_switch|switches]] including [https://deskthority.net/wiki/Category:Keyboard_switches_by_design switch designs]. Wired and wireless technologies usually doesn't affect that much ([https://kanuan.github.io/DS4WSite/troubleshooting/input-delay-bt/ unless its Bluetooth]); thing that really matter when it comes to this topic is actually "[https://forums.blurbusters.com/viewtopic.php?t=6162&start=10#p55425 consistency about polling rate]", polling rate fluctuations causes stutters and unstable input device feedbacks. When it comes to wireless technologies "consistency" may be affected by lots of environmental variables etc. | |
− | |||
− | + | Some people even claim most [[Wikipedia:DIN_connector|devices that use a DIN connection (PS/2, AT etc.)]] are much faster than '''cheap''' [[Wikipedia:USB|USB connection]] devices due to the nature of the technology ([https://www.geeksforgeeks.org/difference-between-interrupt-and-polling/ DIN:Interrupt vs USB:Polling]). See [[Input_lag#External_Links|these websites]] for various controllers and keyboard/mouse devices for input lag performance benchmarks. | |
− | |||
− | + | For input devices make sure using reasonable DPI/CPI values and polling rate values for USB devices because optimizing [https://www.youtube.com/watch?v=lc7JVjcPzL0 input and matrix resolution] may affect input delay little bit.<ref>[https://www.youtube.com/watch?v=6AoRfv9W110 Battle(non)sense: Low DPI vs. High DPI and Polling Rate Analysis]</ref> | |
− | |||
− | + | ===BIOS, Bad driver, OS misconfiguration and placebo effect=== | |
+ | Some people claims that BIOS settings (most motherboard vendors and models usually) and Windows OS by default comes with registry settings, bloated services etc. that causes little bit extra input lag and if you tweak these settings it will affect input delay positively. These kind of tweaks on internet considerably popular due to placebo effect but actually some of them really improves input delay a tiny bit. If you're obsessed with hacking OS and improving your system responsiveness you can check out [[Input_lag#External_Links|FR33THY's latency analysis]] which is includes useful scripts and tweaks. Also see [[#Ways_to_reduce_input_lag|ways to reduce input lag section]] for more proper ways to reducing input delay. | ||
− | + | Some people even [https://forums.blurbusters.com/viewtopic.php?f=10&t=6378 claim that using "ICC Profiles" other than default OS one causing little bit extra input delay]. | |
− | |||
− | + | Make sure using proper drivers for your devices otherwise it will affect your system responsivess negatively (High DPC Latency/spikes etc.), see [https://old.reddit.com/r/Windows11/comments/12yghi6/eliminating_high_dpc_latency_and_getting_kernel/ this thread] for more information. | |
− | |||
==Ways to reduce input lag== | ==Ways to reduce input lag== | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | *Wired controller/input device (just for minimizing possible negative factors, just like using wired connection for router and client device) | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | *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> OR Windows OS with [http://geedorah.com/eiusdemmodi/forum/viewtopic.php?pid=1009#p1009 CRT Emudriver] but you need compatible GPU for this. | |
− | + | **Use exclusive fullscreen for Windows 8+ if available. Reason for this is borderless windowed, or windowed fullscreen in Windows 8 and later, due to [[Wikipedia:Windows_Display_Driver_Model#WDDM_1.2|WDDM 1.2+]] the desktop composition cannot be disabled manually, so your only hope to avoid the compositing lag penalty is to play in exclusive fullscreen mode. | |
− | + | *Use [[Display FAQ#CRT TVs|CRT TV]] OR [[Display_FAQ#CRT_monitors|VGA CRT]] with analog input/output. If your GPU only support digital output then use [https://old.reddit.com/user/ahayriSG/comments/16q18h6/highend_dacs_for_crts/ high-end DAC/Digital-to-Analog converters]. [https://youtu.be/WIDeNItt69s?t=1885 HDMI ones generally pretty bad]. See [https://hardforum.com/threads/24-widescreen-crt-fw900-from-ebay-arrived-comments.952788/ this thread] for more information about high-end DACs. | |
− | : | + | **Also you could use RetroArch's [https://docs.libretro.com/guides/crtswitchres/ CRTSwitchRes] option with your CRT display. Works the best with CRT Emudriver, no pre setup required for Linux other than X11 of course. Another option is using [[GroovyMAME]] instead of MAME, [http://forum.arcadecontrols.com/index.php/topic,162364.msg1711236.html?PHPSESSID=3on534tbvcn64srjrnmi387mnf#msg1711236 using VMM to export settings to mame.ini]. Also there is a [https://github.com/PCSX2/pcsx2/issues/6348 "CRT Mode" feature request] for adding similar option to PCSX2. |
− | + | **If you don't have a CRT, you can mitigate input lag on LCDs by setting the display to game mode if available (this will turns off some post-processing effects) and also set resolution to native panel resolution (for preventing possible low quality hardware display scaler or [https://www.youtube.com/watch?v=Qdp7VfLXnB4&t=279s GPU scaling] delay) | |
+ | **If you have a "Gaming" monitor you can also turn on "Overdrive" if available for overclocking/applies overvoltage to pixels making them react faster (Pixel response time) which results in less ghosting. That said, increasing pixel overdrive may cause inverse ghosting as the increased voltage can cause the pixels to [https://www.rtings.com/monitor/tests/motion/motion-blur-and-response-time#test_4246 overshoot] the colors. See [[#External_Links|these websites and reviews]] to learn information about your display devices capabilities and performance. | ||
− | + | *Turn off digital image processing options from nvidia control panel etc. including post-processing effects such as [[Shader_Presets|shader chain/preset]] from applications if you're using heavy/intensive one. | |
− | |||
− | |||
− | |||
− | |||
− | ''' | + | *Always [https://youtu.be/7DPqtPFX4xo?t=72 make sure your GPU underutilized] for preventing [https://images.nvidia.com/content/images/article/system-latency-optimization-guide/nvidia-latency-optimization-guide-pc-latency.png render queue bottleneck] which causes considerable amount of input lag. Keep in mind using in-game [https://youtu.be/L07t_mY2LEU?t=530 vertical sync] causing huge amount of input lag '''if it includes triple buffering'''. Use alternatives for capping your framerate such as in-game frame capping or "Nvidia Max Frame Rate". However you could use [https://youtu.be/7DPqtPFX4xo?t=650 NVIDIA Reflex feature '''instead of capping your framerate and underutilizing your GPU'''], but not all [https://www.nvidia.com/en-gb/geforce/technologies/reflex/supported-products/ games supports this feature]. |
+ | **But if you have a G-SYNC monitor another option for you is using V-SYNC option '''from Nvidia Control Panel''' with Low Latency Mode: ULTRA setting. According to Nvidia; | ||
+ | For G-SYNC gamers who don’t want to tear, keeping VSYNC ON from Nvidia Control Panel while using NVIDIA Reflex or NVIDIA Ultra Low Latency Mode, will automatically cap the framerate below the refresh rate, preventing VSYNC backpressure, eliminating tearing, and keeping latency low if you become GPU bound below the refresh rate of your display. Do note, however, that this method will result in slightly higher latency than just letting your FPS run uncapped with NVIDIA Reflex enabled. | ||
+ | As a side note, VSYNC ON in the NVIDIA Control Panel will only work for Fullscreen applications. In addition, MS Hybrid-based laptops do not support VSYNC ON. If you are gaming in windowed mode or on one of these laptops, and want to utilize G-SYNC + VSYNC + Reflex mode, use in-game VSYNC.<ref>[https://www.nvidia.com/en-us/geforce/guides/gfecnt/202010/system-latency-optimization-guide/ Nvidia: System latency optimization guide]</ref> | ||
− | ' | + | *Some graphics drivers enforce excessive frame buffering, which may be eliminated with GPU commands. RetroArch's [[Vsync#Hard_GPU_Sync|Synchronization Fences/Hard Sync]] for OpenGL does this. If using Vulkan, be sure to set the [https://arm-software.github.io/vulkan_best_practice_for_mobile_developers/samples/performance/swapchain_images/swapchain_images_tutorial.html 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 [https://github.com/higan-emu/emulation-articles/tree/master/input/run-ahead 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. | |
− | It cannot be understated how much system requirements increase the more lag reduction measures are employed. A computer or device that would normally be able to run an emulator or core at full speed with ease can suddenly find itself chugging with said measures implemented, especially once Run-Ahead and Frame Delay come into play, which may necessitate foregoing some of them. Some ways to alleviate the load and unlock more lag mitigation potential include making sure performance options are enabled, turning on speed hacks or dynarecs if applicable (to the extent that they don't hamper the game significantly, that is), or switching to faster, less | + | **Another option for lag-mitigating technique known as Preemptive Frames. See [https://www.youtube.com/watch?v=NDYqRoyOKI4 this video] for information. |
+ | |||
+ | *Some emulator frontends like [[RetroArch]] or [[GroovyMAME]] have the option named "[https://www.libretro.com/index.php/retroarch-1-9-13-automatic-frame-delay/ Frame Delay]" to delay the processing of emulation for a few milliseconds until right before the given frame period is over, which causes inputs to be polled quickly before your display refreshes instead at the beginning of the 16.7ms (for 60 fps) frame 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 [https://community.pcgamingwiki.com/files/file/897-gedosato/ GeDoSaTo]. Also you can use [https://www.libretro.com/index.php/retroarch-1-9-13-automatic-frame-delay/ Automatic Frame Delay] instead of manually giving a value for Frame Delay. | ||
+ | |||
+ | ''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.'' | ||
+ | |||
+ | ''It cannot be understated how much system requirements increase the more lag reduction measures are employed. A computer or device that would normally be able to run an emulator or core at full speed with ease can suddenly find itself chugging with said measures implemented, especially once Run-Ahead and Frame Delay come into play, which may necessitate foregoing some of them. Some ways to alleviate the load and unlock more lag mitigation potential include making sure performance options are enabled, turning on speed hacks or dynarecs if applicable (to the extent that they don't hamper the game significantly, that is), or switching to faster, less accurate emulator/cores altogether, as the less CPU intensive an emulator is, the more performance overhead is left over for lag reduction. An example would be switching from bsnes to SNES9X, which trades cycle accuracy and compatibility with a handful of games for far greater performance and thus more room to reduce input lag. Also, as implied before, if you have to choose between Run-Ahead and Frame Delay, you should almost always choose Run-Ahead. Of course, if your system is powerful enough to run the most accurate emulators along with all the input lag reduction techniques all at once, go ahead and do so.'' | ||
+ | |||
+ | *There are some emulators have the option named "threaded presentation" OR "backend multithreading" for Vulkan video renderer backend and some people claim that this technique adds a frame of input lag. (e.g. [https://github.com/libretro/flycast/issues/738 Flycast_libretro], [https://old.reddit.com/r/RetroArch/comments/vwktz2/pcsx2_turned_off_vsync_to_reduce_input_lag_but/ifqkbux/ LRPS2]). This option has actually existed for some time in various emulators that implemented Vulkan renderer backend. What it actually does is when the CPU wants to make something draw it has to issue a "draw call" which takes up CPU time, on old APIs this was nearly all done on one thread, the reason for that is different threads can't access other threads data (quickly) if it's being updated and because of how it used to be done, you needed to synchronise threads a lot and that meant that using lots of threads ended up not always being too helpful, in Vulkan because the person using the API is more explicit about how they want their memory and what have you allocated and used it's easier to submit "draw calls" on multiple threads so it (usually) performs better because it's designed to avoid the issues of older APIs.<ref>[https://old.reddit.com/r/DolphinEmulator/comments/ckfes1/back_end_multithreading_with_vulkan_how_much_of_a/evrbv2h/ sdrawkcabdaertseb's comment about vulkan threaded presentation]</ref> | ||
+ | |||
+ | *If you have a variable refresh rate supported monitor you could also use these settings: Latest MAME versions "[https://shmups.system11.org/viewtopic.php?t=65615 -lowlatency]" flag and RetroArch's [https://www.libretro.com/index.php/upcoming-retroarch-1-7-4-sync-to-exact-content-frame-rate-ideal-for-g-syncfreesync-users/ Sync To Exact Content Frame Rate]. | ||
==References== | ==References== | ||
{{reflist}} | {{reflist}} | ||
− | |||
− | |||
− | |||
− | |||
==External Links== | ==External Links== | ||
− | + | [https://docs.google.com/spreadsheets/d/1XvuDUHluuqDJ0DmF_PrWIjsLBgeg8CKVlL0w_Cyguxk/edit#gid=1101422075 Run-Ahead Wiki]<br/> | |
− | + | [https://sensor.fyi/mice/ Mouse devices sensor list]<br/> | |
− | + | [https://old.reddit.com/user/DestinyXZ9/submitted/ DestinyXZ9's investigations about input lag in various emulators]<br/> | |
− | + | [https://www.rtings.com/monitor/tests/inputs/input-lag RTINGS: Input Lag of Monitors]<br/> | |
− | + | [https://www.rtings.com/tv/tests/inputs/input-lag RTINGS: Input Lag of TVs]<br/> | |
− | + | [https://www.rtings.com/monitor/tests/motion/motion-blur-and-response-time RTINGS: Pixel Response Time of Monitors]</br> | |
− | + | [https://www.rtings.com/tv/tests/motion/motion-blur-and-response-time RTINGS: Pixel Response Time of TVs]</br> | |
− | + | [https://tftcentral.co.uk/reviews_index TFTCentral: Reviews and Input Lag analysis of Monitors]<br/> | |
− | + | [https://www.aperturegrille.com/reviews/ ApertureGrille: Reviews and Input Lag analysis of Monitors]<br/> | |
− | + | [https://docs.google.com/spreadsheets/d/1KlRObr3Be4zLch7Zyqg6qCJzGuhyGmXaOIUrpfncXIM/edit#gid=0 Controller latency on MiSTer] ([https://old.reddit.com/r/allbenchmarks/comments/gz1bhx/controller_latency_testing_spreadsheet_by/ftdkptr/ might find this interesting as well])<br/> | |
− | + | [https://www.youtube.com/watch?v=ahsO5bhBUtk Rocket Science: Controller Input Lag comparison video]<br/> | |
− | + | [https://www.rtings.com/mouse/tests/control/latency RTINGS: Mouse Click Latencies]<br/> | |
− | + | [https://www.rtings.com/mouse/tests/control/cpi RTINGS: Mouse CPI and Speed-Related Accuracy Variation/SRAV results]<br/> | |
− | + | [https://www.rtings.com/mouse/tests/control/sensor-latency RTINGS: Mouse sensor latencies]<br/> | |
− | + | [https://www.rtings.com/keyboard/tests/latency RTINGS: Keyboard Latencies]<br/> | |
− | + | [https://mousespecs.org/mouse-click-latencies/ mousespecs: Mouse Click Latencies]<br/> | |
− | + | [https://www.youtube.com/@RocketJumpNinja/videos Rocket Jump Ninja (Usually reviews mouse devices)]</br> | |
− | + | [https://www.anandtech.com/show/2803 Derek Wilson/AnandTech: Exploring Input Lag Inside and Out]<br/> | |
− | + | [https://blurbusters.com/gsync/preview2/ BlurBusters: Preview of NVIDIA G-SYNC, Part #2 Input Lag]<br/> | |
− | + | [https://www.retrorgb.com/bsnes-runahead-mode-lag-tested.html RetroRGB: BSNES Runahead Mode Lag Tested]<br/> | |
− | + | [https://www.youtube.com/@BattleNonSense/videos Battle(non)sense (Usually analysis netcode performance and input lag etc.)]<br/> | |
− | + | [https://www.youtube.com/@FR33THY/videos FR33THY (Usually reviews computer hardware and peripherals, testing for input lag etc.)]<br/> | |
− | + | [https://docs.google.com/spreadsheets/d/19rFOoJtx8OTF7GumSxwhB_3oCQ5bmY4bSpth7ef69Iw/edit#gid=0 FR33THY latency analysis]<br/> | |
− | + | [https://github.com/hrydgard/ppsspp/issues/17685 PPSSPP: Input lag too high - ideas for improvement] | |
− | |||
− | |||
− | |||
[[Category:FAQs]] | [[Category:FAQs]] |