Changes

Jump to navigation Jump to search

Input lag

704 bytes added, 13 March
Input
'''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.
 
;Before diving in, let's distinguish between four key terms. Display lag, input lag, system latency, and [https://old.reddit.com/r/apexlegends/comments/f02vxz/apex_netcode_still_worst_of_all_brs/ netcode/network lag]. They might sound similar, but they affect your experience in different ways. While display and system lag can subtly influence input lag, it's crucial not to mix them up.
:''See GamersNexus: [https://www.youtube.com/watch?v=Fj-wZ_KGcsg Framerate Isn't Good Enough: Latency Pipeline, "Input Lag," Reflex, & Engineering Interview] and [https://youtu.be/C_RO8bJop8o Fixing GPU & CPU Benchmarks: Introducing Animation Error] videos for more information about some of these''.
==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 FAQDisplays#CRT TVsCRT_TVs|CRT TVs]] and [[Display_FAQ#CRT_monitors|VGA CRT monitorsHD CRTs]] have nearly zero display lag (although its limited by phosphor decay time) and input lag, due to the nature of the technologyLCDs, the exception being later model [[Display FAQ#CRT TVs|HD CRTs]] that OLEDs and other digital displays do have digital image processing such as High-Definition, 100Hz/doubling the scanrate or 480p inputs which use scaling and cause noticable input lag. [[Displays#OLED_Monitors|OLEDs]] also have [https://www.rtings.com/monitor/tests/inputs/input-lag considerable amount of input lag compared to analog CRTs] but there is almost no display lag due to their fast response time and the nature of the technology. They are also capable of displaying true black levels, which means that they do not require a backlight to produce an image and this allows OLEDs to turn individual pixels on and off much faster than [[Displays#LCD_monitors|LCDs]], which require a backlight to produce an image. Having said that most modern "gaming" LCD and OLED monitors have "low enough" display and input lag, 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 :;Response time:Once the GL drivers in Windows/Linux. Both digital processing done, the GLX X11 and Windows GL/D3D drivers are full of hacks, code paths, and buffer schemes that cater pixels need time to switch to benchmarking applications and games. This is counterproductive when the aim new frame's colors, which is lowcalled '[https://www.rtings.com/monitor/tests/motion/motion-blur-latency audio and video synchronization for emulators. You don-response-time pixel response time]'t want all this stuff going (cause a blur on in screen, so it's different from input lag), remember, pixel response affects how fast you see the image update, while input lag impacts how quickly the backgrounddisplay reacts to your commands.
Hard GPU sync options in some emulator frontends can reduce or remove latency from buffering at :Analog [[Display FAQ#CRT TVs|CRT TVs]] and [[Display_FAQ#CRT_monitors|VGA CRT monitors]] and even [[Displays#CRT_TVs|HD CRTs]] have very fast response times but it's limited by [https://old.reddit.com/r/crtgaming/comments/qyx4r3/is_this_normal_for_a_crt_monitor_if_not_is_there/ phosphor decay time] due to the possible expense nature of performancethe technology. [[Displays#OLED_Monitors|OLED]] displays have almost no blur on screen due to their very fast response time and also capable of displaying true black levels, which means that they do not require a backlight to produce an image and this allows OLEDs to turn individual pixels on and off much faster than [[Displays#LCD_monitors|LCDs]], which require a backlight to produce an image.
This can be avoided by using [[Wikipedia:Mode_setting|KMS]] and [[Wikipedia:Direct_Rendering_Manager|DRM]]While <abbr title="Flicker/PWM/BFI/[[Wikipedia:EGL_strobe-based motion blur reduction such as LightBoost, ELMB, ULMB, VRB, DyAc, PureXP etc.">BFI (APIBlack Frame Insertion)|EGL]]</abbr> technology can significantly improve motion clarity for LCDs, specifically on Linux. By using these modes, the user is it still falls short of both OLED and CRT in control terms of front both perceived clarity and back buffers motion resolution, though it's a great alternative/bridge the gap between these display technologies, offering a compromise between OLED's brightness and donCRT't have to rely on APIss legendary motion, although at the cost of some flicker, so that they potential extra input lag and reduced overall brightness. Although strobing (BFI) can find where and when a frame was dropped and how to act accordingly with that eventually become obsolete in mind. It is advisable to get the latest driver to improve performancefuture (including DyAc, ULMB, ELMB, VRB, as notable graphics chip manufacturers (eetc) for modern content supporting 1000fps+ 1000Hz+ reprojection.gThis is a fully ergonomic PWM-free and flicker-free method of display motion blur reduction. Nvidia) do not find KMS a priorityNo PWM or flicker.<ref>[https://developer.nvidiablurbusters.com/blog/understandingframe-generation-andessentials-measuringinterpolation-pcextrapolation-latency/ nvidia: Understanding and Measuring PC Latency-reprojection#dev]</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 If you're in the user control over buffering market for a monitor or TV; check [[Input_lag#External_Links|these websites]] for input lag and may lower latency without resource-heavy solutions like hard GPU syncdisplay lag performance of various display products. However, there is evidence that OpenGL has lower latency than Vulkan in Some of the modern digital displays only have negligible amount of input lag and display lag and even some instancesof them are near identical performance compared to Analog CRTs.<ref>https://forums.libretro.com/t/an-input-lag-investigation/4407/291</ref>
===Controller/Input===[[File:Keyboard Switches demonstration.gif|thumb|298px|[https://thegamingsetup.com/gaming-keyboard/buying-guides/keyboard-switch-chart-table actuation force] demonstration, see [https://www.x360ce.com/Keyboards this page]]]
When it comes to 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/wireless usually doesn't matter ([https://kanuan.github.io/DS4WSite/troubleshooting/input-delay-bt/ unless its Bluetooth with power saving mode]); the thing that really matter is "[https://forums.blurbusters.com/viewtopic.php?t=6162&start=10#p55425 consistency about polling rate]"; polling rate fluctuations cause stutters and unstable input device feedback to users. When it comes to wireless technology "consistency" may be affected by lots of environmental factors.
See [[Input_lag#External_Links|these websites]] for various controllers and keyboard/mouse devices for input lag performance benchmarks.
* Back in the days some people claim that [[Wikipedia:DIN_connector|DIN/mini-DIN connection]] keyboards and mice give better results compared to cheap [[Wikipedia:USB|USB connection]] peripherals due to the nature of the technology. Although this is far from the truth [https://forums.blurbusters.com/viewtopic.php?t=8411#p65756 it has better handling of the data], whereas the USB busses can be more easily interrupted etc(kinda similar to wired/wireless polling consistency situation mentioned above).
:: [https://www.youtube.com/watch?v=eEswl6kZq5k Battle(non)sense: Keyboard Input Lag 125, 250, 500, 1000Hz USB vs. PS/2]
:: [https://www.youtube.com/watch?v=6AoRfv9W110 Battle(non)sense: Low DPI vs. High DPI and Polling Rate Analysis]
===System (BIOS settings, bad drivers, OS misconfiguration ) and placebo effect===Some people claims that default BIOS settings, Windows settings, registry settings, bloated services etc. causes little bit input delay and if you tweak these settings it will improve your system responsiveness. 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 your operating system and improving your system responsiveness even for a little bit you can check out [https://docs.google.com/spreadsheets/d/19rFOoJtx8OTF7GumSxwhB_3oCQ5bmY4bSpth7ef69Iw/edit#gid=0 FR33THY's latency analysis] and also [https://www.youtube.com/watch?v=89R9KlJ3ocM optimization pack] which includes useful scripts. Most importantly make sure to use always proper and official drivers for your computer otherwise it may affect your system responsivess negatively (e.g. High DPC Latency, spikes , IRQ issues etc.)
See [[#Ways_to_reduce_input_lag|ways to reduce input lag section]] for reducing input delay.
==Ways ==[[Wikipedia:Compositing_window_manager|Compositor]]====If you're using Windows Vista/7 and playing in windowed mode, having [[Wikipedia:Desktop_Window_Manager|DWM]] enabled will add a noticeable amount of input lag because it forces vertical synchronization at the OS-level. The same thing applies to reduce other OSes if their compositor uses V-Sync. [[Wikipedia:Windows_Aero|Windows Aero]] and [[Wikipedia:Desktop_Window_Manager|DWM]] 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.
*Wired controller====GPU driver====There is video latency caused by the GL drivers in Windows/input device 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. This can be avoided by using [[Wikipedia:Mode_setting|KMS]] and [[Wikipedia:Direct_Rendering_Manager|DRM]]/[[Wikipedia:EGL_(just for minimizing possible negative factorsAPI)|EGL]], just like specifically on Linux. By using wired connection for router 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 client devicehow 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.
*Choose your operating system as Linux 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 Linux/Windows version that compatible with [https://mame.3feetunder.com/windows-ati-crt-emudriver/ CRT Emudriver] (Also you need compatible GPU).==Ways to reduce input lag==;Display**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 ;Option 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]] (not [[Display FAQ#CRT TVs|HD CRTs]]) with analog input/output. If your GPU only support digital output then use [https://www.youtube.com/watch?v=puu-iyTsZtg GPU-Passthrough] OR [https://old.reddit.com/user/ahayriSG/comments/16q18h6/highend_dacs_for_crts/ high-end DAC/Digital-to-Analog converters] for higher resolutions and refresh rates (Keep in mind that HDMI ones generally [https://youtu.be/WIDeNItt69s?t=1885 pretty bad]). But what about digital-to-analog conversion input lag? See Aperture Grille's video about [https://youtu.be/puu-iyTsZtg?t=840 testing GPU-Passthrough and cheap DAC input delay lag results]. Also see [https://hardforum.com/threads/24-widescreen-crt-fw900-from-ebay-arrived-comments.952788/ page-435#post-1044652495 this thread] for more information about high-end DACs.**::Use CRT modelinesCustom resolution/SwitchRes/EDID generator CRTSwitchRes solutions for displaying it on a CRT display in the correct resolutions. You could use [https://emulation.gametechwiki.com/index.php?title=Special:Search&limit=500&offset=0&profile=default&search=Built-in%20CRT%20modelines built-in Custom resolution/CRTSwitchRes solutions] like RetroArch's [https://docs.libretro.com/guides/crtswitchres/ CRTSwitchRes] or [[GroovyMAME]] using with [httpshttp://mame.3feetundergeedorah.com/windows-ati-crt-emudrivereiusdemmodi/forum/ viewtopic.php?pid=1009#p1009 CRT emudriver] which is much more practical compared to using EDID editor tools like such as [[https://wwwDisplays#240p.monitortests.com/forum/Thread-Custom-Resolution-Utility-CRU 2F480i|Custom Resolution Utility (CRU)]] or using Linux in KMS mode<ref>https://wiki. If you have a variable refresh rate supported monitor and don't want to mess with [archlinux.org/index.php/kernel_mode_setting</ref><ref>https://mamedocs.3feetunderlibretro.com/windowsguides/kms-ati-crt-emudrivermode/</ CRT emudriver] you could also use latest [[MAME]] with "ref>. See [https://shmupsemulation.system11gametechwiki.orgcom/viewtopicindex.php?tsearch=%22%23Enhancements|Enhancements%22&title=Special%3ASearch&limit=500&profile=default&fulltext=65615 1 #Enhancements sections] in each page for "built-lowlatency]in custom resolution/CRTSwitchRes" flagsupport for emulators.:;Option 2*If you don't have a CRT[[#External_Links|Fast-TN or IPS panel LCD or fast-OLED display]], also make sure that you can mitigate input lag on [[Displays#LCD_monitors|LCDs ]] and [[Displays#OLED_TVs_and_Monitors|OLEDs]] by setting the display to turning on "game mode " from display OSD if available (this will turns turn off some post-processing effectsoptions on display) and also . If your LCD display is old set your [https://www.youtube.com/watch?v=Qdp7VfLXnB4&t=279s native resolution to native panel resolution (] for preventing possible low poor quality hardware display scaler or otherwise you can use [https://wwwforums.youtubeblurbusters.com/watchviewtopic.php?v=Qdp7VfLXnB4&t=279s 6155#p46190 GPU scaling] delay)if you have at least mid range GPU.**::If you have a "Gaminggaming" monitor you can also turn on "Overdriveoverdrive" option if available for overclocking/pixels (applies overvoltage to pixels ) making them react faster (Pixel better 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 and [https://youtu.be/NzYvudM9BmI?t=723 frame generation] options. If :Also you're using intensive one turn off post-processing effects from applications/emulators and could use latest [https://www.pcgamingwiki.com/wiki/Category:Graphics_Adaptor GPU driver control panels].**Turn on DLSS/FSR upscaling technologies [https://youtu.be/-ajK3netvv4?t=173 if it uplift your framerate which '''likely''' decrease your latencyMAME]. *Always make sure that your [https://youtu.be/7DPqtPFX4xo?t=72 GPU is underutilized] for preventing with "[https://imagesshmups.nvidiasystem11.comorg/content/images/article/system-latency-optimization-guide/nvidia-latency-optimization-guide-pc-latencyviewtopic.png render queue bottleneck] which causes considerable amount of input lag. Keep in mind that using in-game [https://youtu.be/L07t_mY2LEUphp?t=530 vertical65615 -synclowlatency] causes huge amount of input lag '''if it includes triple buffering'''. Use alternatives " flag for capping your framerate such as in-game frame capping or "Nvidia Max Frame Rate" option from [https://www.pcgamingwiki.com/wiki/Category:Graphics_Adaptor GPU driver control panels].**Also you could use [https://youtu.be/7DPqtPFX4xo?t=650 NVIDIA Reflex feature], but unfortunately not all [https://www.nvidia.com/en-gb/geforce/technologies/reflex/variable refresh rate supported-products/ games supports this feature]. *If you have a G-SYNC monitor you could use V-SYNC option with Low Latency Mode: ULTRA from Nvidia Control Panel. According to Nvidia; For G-SYNC gamers who don’t want to tear, keeping VSYNC ON 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----;Input'''1. RetroArch's [[Vsync#Hard_GPU_Sync|Synchronization Fences'' Wired controller/Hard Sync]] input device (just for minimizing possible negative factors, just like using wired connection for OpenGL does thisrouter and client device)----;System'''1. If you're using Vulkan backend'' Use exclusive fullscreen for Windows 8 and onwards if available because with borderless windowed and windowed fullscreen, be sure due to set the [https[Wikipedia://arm-softwareWindows_Display_Driver_Model#WDDM_1.github2|WDDM 1.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 intensive [[Shader_Presets|shader presets]] or increasing [[Resolution|internal or rendering resolution]]the desktop composition cannot be disabled anymore, so your only hope to avoid the compositing lag penalty is to play in exclusive fullscreen mode.
*Use input lag-mitigating techniques if application supports it'''2.**A relatively new lag-mitigating technique known as ''' Turn off digital image processing and [https://githubyoutu.combe/NzYvudM9BmI?t=723 frame generation] options from [https:/higan-emu/emulation-articleswww.pcgamingwiki.com/treewiki/masterCategory:Graphics_Adaptor GPU driver control panel] if it cause additional/noticeable input/run-ahead Run-Ahead] has recently been implemented in several emulators and frontendsdelay, which leverages spare performance overhead to run one or more instances some 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 generation technologies can noticeably affect input lag. Most gamesdelay, even on real hardware on a CRTeither positively or negatively, have at least one hard-coded frame between executing an action depending on the controller and said action being reflected on screen, so setting Runspecific technique used[https://blurbusters.com/frame-generation-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 5thessentials-gen games). This is also quite processorinterpolation-heavy, as every extra Runextrapolation-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 allreprojection]. That said, combined with all the other lag reduction techniques on a sufficiently powerful system, RunAlso if you're using intensive one turn off post-Ahead in theory can actually result in less input lag than even real hardwareprocessing effects from applications/emulators and [https://www.pcgamingwiki.com/wiki/Category:Graphics_Adaptor GPU driver control panel].**Another option for lag-mitigating technique known as Preemptive Frames:'''2.1. See ''' Turn on DLSS/FSR upscaling technologies [https://www.youtubeyoutu.combe/watch-ajK3netvv4?vt=NDYqRoyOKI4 this video173 if it increases your framerate which will likely decrease your latency] for information.
*Some emulator frontends like [[RetroArch]] or [[GroovyMAME]] have the option named "'''3.''' Use [https://wwwemulation.libretrogametechwiki.com/index.php/retroarch?search=%22%23Enhancements|Enhancements%22&title=Special%3ASearch&limit=500&profile=default&fulltext=1 input lag-mitigating techniques] if application supports it.:'''3.1.''' A relatively new lag-9mitigating technique known as [https://github.com/higan-13emu/emulation-automaticarticles/tree/master/input/run-frameahead Run-delay/ Frame DelayAhead]" has recently been implemented in several emulators and frontends, which leverages spare performance overhead to delay run one or more instances of the processing 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 emulation for input lag. Most games, even on real hardware on a few milliseconds until right before CRT, have at least one hard-coded frame between executing an action on the given controller and said action being reflected on screen, so setting Run-Ahead to 1 frame period cuts out that superfluous frame and thus is overusually considered safe, which causes inputs but setting it to be polled quickly before your display refreshes instead at the beginning 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 the frame period5th-gen games). The amount of time you can use Frame Delay without dropping frames This is dependent on the performance 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 your machinea sufficiently powerful system, Run-Ahead in theory can actually result in less input lag than even real hardware. Use [https://www'''3.libretro2.com/index.php/retroarch-1-9-13-automatic-frame-delay/ Automatic Frame Delay] if you don't want to manually give a value '' Another option for Frame Delaylag-mitigating technique known as Preemptive Frames.**Predictive waiting may also be forced with any DirectX based program through See [https://communitywww.pcgamingwikiyoutube.com/files/file/897-gedosato/ GeDoSaTowatch?v=NDYqRoyOKI4 this video]for information.
''Realistically, Frame Delay '4.''' Always make sure that your [https://youtu.be/7DPqtPFX4xo?t=72 GPU is underutilized] for preventing [https://youtu.be/K_k1mjDeVEo?t=83 render queue bottleneck] which causes considerable amount of input lag. If that is the last thing to configurecase use framerate capping such as "in-game frame capping" or equivalent option from [https://www.pcgamingwiki.com/wiki/Category:Graphics_Adaptor GPU driver control panel].:'''4.1.''' [https://youtu.be/7DPqtPFX4xo?t=650 NVIDIA Reflex feature] from in-game option will prevent this, after but unfortunately not all other sync GPUs and buffer settings and Run[https://www.nvidia.com/en-gb/geforce/technologies/reflex/supported-Ahead frames products/ games supports this feature].:'''4.2.''' If you have been configured a VRR capable display another option for your you to prevent this is simply using both [[Vsync|V-SYNC]] and "Low Latency Mode: ULTRA" or "AMD Anti-Lag+" options '''from [https://www.pcgamingwiki.com/wiki/Category:Graphics_Adaptor GPU driver control panel]'''; this will automatically prevent "render queue bottleneck".<ref name=renderqueueandvsyncbackpressure>[https://www.nvidia.com/en-us/geforce/guides/gfecnt/202010/system-latency-optimization-guide/ Nvidia: System latency optimization guide], [https://forums.blurbusters.com/viewtopic.php?t=8645 BlurBusters thread: Nvidia Reflex and low latency mode]</ref>::''s performance'4.2.1.''' Keep in mind that if you are using [[Vsync|V-SYNC]] on non-VRR capable display, as it gives the least will result "V-SYNC backpressure" which will cause additional input lag reduction bang for your CPU load buck[https://youtu.be/L07t_mY2LEU?t=530 (especially if it includes triple buffering)].::'''4.2.2. It is possible on systems ''' If you have a VRR capable display and using "AMD Anti-Lag+" and also want to eliminate tearing completely with performance much higher than is required all of these: [https://youtu.be/K_k1mjDeVEo?t=727 you need to run at full speeduse framerate limiter again, because it does not keep the framerate inside the variable refresh rate range of the display] unlike Nvidia's "Low Latency Mode: ULTRA" solution.''
''It cannot be understated how much system requirements increase the more lag reduction measures are employed'5. 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''' Some graphics drivers enforce excessive frame buffering, which may necessitate foregoing some of thembe eliminated with GPU commands. 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 donRetroArch't hamper the game significantly, that is), or switching to faster, less accurate emulators [[Vsync#Hard_GPU_Sync|Synchronization Fences/cores altogether, as the less CPU intensive an emulator is, the more performance overhead is left over Hard Sync]] for lag reductionOpenGL does this. An example would If you're using Vulkan backend, be switching from bsnes sure to SNES9X, which trades cycle accuracy and compatibility with a handful of games for far greater set the [https://arm-software.github.io/vulkan_best_practice_for_mobile_developers/samples/performance and thus more room to reduce input lag/swapchain_images/swapchain_images_tutorial. Also, as implied before, if you have html max swapchain images] parameter to choose between Run-Ahead and Frame Delay2, you should almost always choose Run-Ahead. Of coursethough weaker GPUs (especially Intel iGPUs), if your system is powerful enough to run the most accurate emulators along can struggle with all the input lag reduction techniques all at oncethis, go ahead and do soparticularly if using intensive [[Shader_Presets|shader presets]] or increasing [[Resolution|internal or rendering resolution]].''
*There are some emulators '''6.''' Some emulator frontends like [[RetroArch]] or [[GroovyMAME]] have the option named "threaded presentation" OR "backend multithreading[https://www.libretro.com/index.php/retroarch-1-9-13-automatic-frame-delay/ Frame Delay]" to delay the processing of emulation for Vulkan video renderer backend and some people claim that this technique adds a few milliseconds until right before the given V-SYNC frame period is over, which causes inputs to be polled quickly before your display refreshes instead at the beginning of input lagthe newer V-SYNC frame period. (e.gThe amount of time you can use Frame Delay without dropping frames is dependent on the performance of the emulator on your machine. Use [https://githubwww.libretro.com/libretroindex.php/flycast/issuesretroarch-1-9-13-automatic-frame-delay/738 Flycast_libretroAutomatic Frame Delay]if you don't want to manually give a value for Frame Delay. Keep in mind that realistically, Frame Delay is the last thing to configure, after all other "sync and buffer settings" and "Input lag mitigation techniques" have been configured for your system's performance, as it gives the least lag reduction bang for your CPU load buck. ''Also "Predictive waiting" may also be forced with any DirectX based program through'' [https://oldcommunity.redditpcgamingwiki.com/r/RetroArch/commentsfiles/vwktz2file/pcsx2_turned_off_vsync_to_reduce_input_lag_but897-gedosato/ifqkbux/ LRPS2GeDoSaTo]). This option has actually existed for some time in various emulators ----;SummaryIt 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 Vulkan renderer backend, especially once Run-Ahead and Frame Delay come into play, which may necessitate foregoing some of them. What it actually does is when Some ways to alleviate the CPU wants to make something draw it has to issue a "draw call" which takes up CPU timeload and unlock more lag mitigation potential include making sure performance options are enabled, turning on old APIs this was nearly all done on one thread, speed hacks or dynarecs if applicable (to the reason for extent that is different threads canthey don't access other threads data (quicklyhamper the game significantly, that is) if it's being updated , or switching to faster, less [[Emulation_accuracy|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 [[Emulation_accuracy|cycle accuracy]] and because compatibility with a handful of how it used games for far greater performance and thus more room to be donereduce input lag. Also, as implied before, if you needed have to synchronise threads a lot choose between Run-Ahead and that meant that using lots of threads ended up not Frame Delay, you should almost always being too helpfulchoose Run-Ahead. Of course, in Vulkan because if your system is powerful enough to run the person using most [[Emulation_accuracy|accurate]] emulators along with all the API is more explicit about how they want their memory and what have you allocated input lag reduction techniques all at once, go ahead and used it's easier to submit "draw calls" on multiple threads do 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>
==References==
==External Links==
*[https://inputlag.science/ inputlag.science] - repository of knowledge about input lag in gaming<br/>*[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]<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.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/@RocketJumpNinja/videos Rocket Jump Ninja] - YouTube channel dedicated to mouse reviews</br>*[https://www.youtube.com/@BattleNonSense/videos Battle(non)sense] - YouTube channel dedicated to analysing netcode performance of games and testing input lag, system responsiveness etc.<br/>*[https://www.youtube.com/@FR33THY/videos FR33THY] - YouTube channel dedicated to computer hardware and peripherals for testing input lag and system responsiveness etc.<br/>*[https://github.com/hrydgard/ppsspp/issues/17685 PPSSPP: Input lag too high - , ideas for improvement]*[https://forums.libretro.com/t/an-input-lag-investigation/4407 Brunnis: An input lag investigation]*[https://sites.google.com/view/noodallsinputlagtestingresults/video-interrupt-method-results noodalls Input Lag Testing Results]
[[Category:FAQs]]
11,185
edits

Navigation menu