- Open-source low_latency_layer exposes NVIDIA Reflex and AMD Anti-Lag 2 on any Vulkan-capable GPU in Linux.
- The project emulates VK_NV_low_latency2 and VK_AMD_anti_lag to cut input lag even without official driver support.
- Early tests on demanding titles show latency on Linux matching or beating Windows on the same hardware.
- Setup requires technical know-how with Vulkan, CMake, Proton and environment variables, so it targets advanced users.
For years, Linux gamers chasing the lowest possible input lag have had to live with a frustrating limitation: cutting-edge latency reduction tools were tightly tied to specific GPU brands and proprietary drivers on Windows. If your graphics card, operating system or driver stack fell outside that sweet spot, you were usually out of luck.
That landscape is starting to shift thanks to a new open-source initiative called low_latency_layer. Instead of waiting for each GPU vendor to roll out flawless Linux support for their own low-latency tech, this project uses Vulkan to expose the same kind of features across different graphics cards, making it possible to benefit from NVIDIA Reflex-style and AMD Anti-Lag 2-style behavior on hardware that was never officially meant to use them.
What low_latency_layer Actually Does
At its core, low_latency_layer is an implicit Vulkan layer written in modern C++23 that sits between games and the graphics driver. It implements the Vulkan device extensions VK_NV_low_latency2 and VK_AMD_anti_lag in a vendor-agnostic way, so applications that look for these capabilities can use them even if the underlying GPU and drivers do not support them natively.
In practical terms, that means a title with built-in NVIDIA Reflex support can be tricked into seeing that feature on an AMD or Intel GPU running Linux. The same goes for AMD Anti-Lag 2: games expecting that extension can access a compatible path, regardless of the vendor. The layer intercepts and translates the relevant Vulkan calls, managing command queues and frame timing to reduce the delay between input and on-screen response.
The project is developed by Korthos Software, with Nicolas James as the lead author. His motivation came from observing that existing Linux implementations of Anti-Lag, particularly the one in Mesa, were often disabled by default, could behave unstably, and delivered less impressive latency cuts than their proprietary Windows counterparts. Instead of waiting for all of that to be fixed, he set out to build a generic solution on top of Vulkan.
Because this is an implicit layer, games do not need to be patched or rebuilt. Any Vulkan title that tries to use these latency-related extensions can, in principle, benefit as soon as the layer is installed and activated, as long as the rest of the software stack cooperates.
Breaking the Vendor Lock on Latency Features
One of the biggest attractions of low_latency_layer is that it undercuts the traditional exclusivity surrounding latency technologies. Historically, NVIDIA Reflex and AMD Anti-Lag 2 have been marketed as brand-specific solutions: use an NVIDIA GPU if you want Reflex, grab an AMD card to take advantage of Anti-Lag 2. Linux users were often further constrained by weaker or delayed support compared to Windows.
This new layer takes a different approach. By emulating the Vulkan extensions behind those systems, it lets games enable their low-latency paths without checking whether the hardware is an exact match. That means an AMD Radeon or Intel integrated GPU can leverage the same Reflex-style behavior a title would normally expose only when it sees an NVIDIA card, and vice versa.
In practice, this helps fix a long-standing asymmetry: many competitive shooters and fast-paced games offer robust Reflex integration, while Anti-Lag 2 support is rarer. With low_latency_layer in place, Linux users on non-NVIDIA GPUs can still tap into the Reflex route that developers ship most frequently, rather than being stuck with less common options or older techniques.
Importantly, this is done without relying on proprietary driver paths. The layer uses standard Vulkan hooks and environment variables, fitting naturally into the existing Linux gaming ecosystem built around Proton, DXVK and related tools and benefiting from Wayland gaming improvements.
How It Works with Vulkan, Proton and DXVK
By design, low_latency_layer is tightly coupled to the Vulkan API. Games that support Vulkan natively on Linux can tap into the layer directly. According to the project documentation, the default behavior is to expose the AMD Anti-Lag 2-style extension (VK_AMD_anti_lag), which is enough for some native titles such as Counter-Strike 2 to recognize and use a low-latency mode.
For titles where the NVIDIA Reflex path is better integrated or more fully tested, users can adjust environment variables to steer the layer. A key one is LOW_LATENCY_LAYER_REFLEX=1, which forces the Reflex route. In certain cases, there is also an option to spoof an NVIDIA GPU to the application, letting the game believe it is running on supported hardware even when it is not.
On the Proton side, the picture is a bit more involved but still manageable for experienced users. When running Windows titles through Proton and DXVK, low_latency_layer can work together with dxvk-nvapi, a component that exposes NVIDIA-specific APIs to games. To make sure the game sees what it expects, users often need to enable PROTON_FORCE_NVAPI=1, ensuring the Reflex-related calls are forwarded correctly.
This means the stack, in a typical competitive shooter, might look like: game → DXVK/dxvk-nvapi → Vulkan → low_latency_layer → GPU driver, which in turn depends on kernel support in Linux 7.0.
The downside is that this is not a plug-and-play solution for casual players. It involves understanding Proton environment variables, knowing how to configure Vulkan layers, and sometimes tweaking per-title launch options. For users comfortable with Linux internals and gaming tools, though, the approach fits well with the existing culture of manual tuning.
Measured Performance: Linux Keeping Up with, or Beating, Windows
The project would be much less interesting if it only worked on paper. The developers have invested effort into quantitatively measuring latency with a fairly high-end test bench: an AMD Radeon RX 7900 XTX, a Ryzen 7 9800X3D CPU and 64 GB of RAM. To track input-to-display delay, they used a monitor with built-in NVIDIA Reflex Analyzer, specifically an ASUS PG248QP, and logged results manually after repeated input tests.
Across several modern titles, low_latency_layer reportedly achieves latency reductions comparable to, or better than, Windows running vendor-provided implementations on the same hardware. That is a bold claim, but it aligns with the project’s stated goal of not just matching, but in some cases surpassing, official solutions.
Games cited in the tests include THE FINALS, Counter-Strike 2, Cyberpunk 2077, Resident Evil Requiem, Marvel Rivals and Overwatch 2. In Counter-Strike 2, for example, the collected data suggests that under specific conditions, Linux with low_latency_layer edges out Windows in terms of raw latency numbers, shaving off a few milliseconds that can matter to competitive players.
In other titles, such as Resident Evil Requiem and Overwatch 2, the Reflex-based path implemented through the layer is shown as outperforming alternatives like AMD Anti-Lag 1. The developers also note that the Anti-Lag implementation in Mesa, tested under the same scenarios, delivers negligible improvement in some of these games, which partially explains why Nicolas James decided to pursue a fresh design.
Overall, the early benchmarks underline a simple point: Linux can be a first-class citizen for low-latency gaming when the right middleware is in place, rather than an afterthought lagging behind Windows.
A Technical Tool Aimed at Experienced Linux Gamers
Even with those promising results, the project is clearly aimed at users who are comfortable digging into the technical side of Linux gaming. Installing low_latency_layer is not yet a one-click process wrapped in a friendly GUI; it typically involves grabbing the source code, using CMake to configure and compile it, and then setting up Vulkan layer configuration files correctly on your system.
On top of the build process, you have to handle environment variables both for the layer itself and for components like Proton and dxvk-nvapi. That might mean editing per-game launch options in Steam, experimenting with which combinations trigger Reflex or Anti-Lag 2 paths, and occasionally troubleshooting when a specific title behaves unexpectedly.
To help bridge that gap, Nicolas James has published a detailed setup guide on the project’s GitHub page. It walks through prerequisites, compilation steps and environment configuration, targeting users who have at least basic familiarity with the Linux terminal and package management. While it is not designed for total beginners, it does aim to keep the process systematic rather than leaving people to guess.
For now, that makes low_latency_layer more of a tool for enthusiasts and competitive players than for the average person installing a game and hitting Play. But the open-source nature of the project leaves the door open for future packaging efforts, graphical front ends, or distribution-specific integrations that could streamline adoption.
What stands out is how this fits into a broader trend: Linux gaming improvements increasingly come not just from big-name companies, but from community-driven layers and compatibility projects. Proton, DXVK and now low_latency_layer all share the idea of filling gaps that proprietary driver stacks leave open, particularly in areas like performance and latency that are crucial to how games feel.
Altogether, low_latency_layer highlights a shift in how low-latency tech reaches players: instead of being locked behind brand-specific drivers on a single operating system, these capabilities are being reimplemented in an open, cross-vendor way on Linux. It is not a magic bullet for everyone yet, but for users willing to tinker, it shows that input lag on Linux can stand shoulder to shoulder with, and occasionally surpass, what is available on Windows, regardless of whether there is an NVIDIA, AMD or Intel logo on the GPU box.
