AMD Anti-Lag steps out of its comfort zone — tech arrives on Vulkan 1.3.291, bringing Anti-Lag benefits outside of DirectX for the first time

News
By
published

The Vulkan Graphics API brings AMD Anti-Lag outside of the confines of DirectX.

AMD Anti-Lag
AMD Anti-Lag (Image credit: AMD)

As of earlier today, a recent Vulkan spec update— version 1.3.291, to be specific— went live on GitHub, and besides miscellaneous fixes and the such, a new "VK_AMD_anti_lag" extension has been added to Vulkan, bringing full AMD Anti-Lag support outside the boundaries of the recent DirectX graphics APIs. Nvidia Reflex is also already supported with Vulkan in select titles, though some users have reported issues with that functionality under Vulkan. This update for adding Anti-Lag to Vulkan also addresses an existing "VK_NV_low_latency2" extension, as well.

For those unfamiliar with AMD Anti-Lag or Nvidia Reflex, the best way to think of these options when they are available in your game is "automated FPS capping." Traditionally, users may set FPS caps in games with unlocked FPS to stabilize visuals, performance, or GPU usage at a certain level without buffering frames (increasing latency) using V-Sync. In-engine FPS caps are almost always the best way to reduce input lag in a game, so long as that capped FPS target can be consistently met.

However, there are many caveats to FPS capping—namely, it's a very manual process, and it usually can't be easily adjusted during gameplay. For many gamers, doing it at all may be too difficult—or they're worried about maximum FPS losses. However, it's worth noting that a slightly lower, more consistent FPS target will nearly always "feel" smoother than a higher average with regular dips.

So, the greatest benefit of AMD Anti-Lag and Nvidia Reflex technologies is that they entirely automate the FPS capping process according to end-user latency and GPU utilization. Since fully maximizing GPU utilization can increase latency and the severity of FPS dips, both technologies tend to cap GPU utilization around ~95% while dynamically adjusting the framerate cap to ensure the smoothest image and lowest latency.

As a side note, the Steam Deck's built-in Refresh Rate/FPS Limiter toggle is one of the few ways to dynamically adjust an FPS cap without restarting the game, using external applications, relying on Anti-Lag, etc.

The most exciting implication of Vulkan adding support for AMD Anti-Lag is that this may lead to Anti-Lag being natively supported on Linux. As-is, there are already some efforts from Nvidia to get Reflex working on Linux through Proton extensions, though users have given mixed reports on how well this works. There's also an open-source, vendor-neutral LatencyFleX solution, but since it works akin to the canned AMD Anti-Lag+ (game engine hooking), it can trigger bans in games with anti-cheat, so it's far from perfect.

For now, only time will tell if these Vulkan updates lead to native AMD Anti-Lag or AMD Anti-Lag 2 support being added to native Linux games or at least AMD Linux systems running the Proton compatibility later, like Steam Deck. Since AMD FSR 3 Frame Generation can be made to work through Proton and there are already efforts to get Reflex working, we're cautiously optimistic.

See more GPUs News
Christopher Harper
Christopher Harper
Contributing Writer

Christopher Harper has been a successful freelance tech writer specializing in PC hardware and gaming since 2015, and ghostwrote for various B2B clients in High School before that. Outside of work, Christopher is best known to friends and rivals as an active competitive player in various eSports (particularly fighting games and arena shooters) and a purveyor of music ranging from Jimi Hendrix to Killer Mike to the Sonic Adventure 2 soundtrack.

1 Comment Comment from the forums
  • edzieba
    Reflex/Anti-Lag are not 'FPS capping'. What they are doing is talking to the game engine and telling it "the previous frame has not started scanout yet, wait before you submit another frame". This means that the render ideally never exists, as there is no render to buffer - as soon as the previous frame starts canning out, the engine can then take the most recent input sample (mouse position etc), computer the frame, submit the frame to the GPU, and render the frame. The caveat is that for this to work, the engine has to be sure that the end-to-end frame delivery time will always be shorter than the interval between frame deliveries - the basic reciprocal of the monitor refresh rate, e.g. 16.67ms at 60Hz. If it takes longer, you mish the next scanout start and get a 1-frame stutter. This makes reflex/anti-lag great if you can hold minimum FPS (really maximum frametime) well above the monitor refresh rate, but not much use if you are ever dipping below that.
    In effect, this clamps latency to the reciprocal of the monitor refresh rate.

    For VR, you can do 'late latching', which is where you not only wait for the next startwait to even start generating that frame until the absolute last possible moment before it would result in a render miss. This means the minimal latency can be BELOW the reciprocal of the refresh rate, e.g. if you could render 240FPS but your monitor can only display at 60Hz, rather than uncapped framerate (4-frame tearing across screen) or VSYNC (60FPS), the game will pause render start until 4.17ms before the finished frame needs to start readout, and only start rendering then. The tradeoff is that in the event of a render miss, the 'stutter' impact is not a BIG spike in latency (going from your low-latency target to double your refresh rate reciprocal - 4.17ms to 33.33ms for our example). VR tackles this by reprojecting every single rendered frame such that head movement always has the minimum possible latency regardless of render latency, even though world objects may be subject to latency in motion. For flat games, this would correspond to having rock solid low mouse movement latency, but character animations still subject to latency judder.
    Reply