A new open-source project, low_latency_layer, is shipping vendor-neutral implementations of NVIDIA Reflex and AMD Anti-Lag 2 behavior to GPUs that never got official support. If you are running an RTX 20-series, an RX 5000-series, an Arc A-series, or any other card that vendors quietly left off the supported list, the project promises tighter click-to-photon latency without a hardware upgrade. Here is what it actually does, where it helps, and where the realistic gains land.
The news in one paragraph
A community-led project published as low_latency_layer landed in the last few weeks with a stated goal of bringing Reflex-style and Anti-Lag-2-style frame-pacing improvements to every modern gaming GPU regardless of vendor. The implementation sits above the graphics driver, hooks the render queue, and applies present-time pacing techniques that approximate what NVIDIA Reflex and AMD Anti-Lag 2 do via vendor SDKs. Coverage and benchmarks have begun to land on community outlets including Phoronix.
What is the actual problem being solved?
Click-to-photon latency — the time between a player input and the pixel change that reflects it — is the dominant subjective latency in fast-paced PC games. The two largest contributors are render queue depth (how many frames the driver has buffered ahead of the GPU) and present timing (how long the GPU sits idle waiting for the next vsync interval). NVIDIA Reflex and AMD Anti-Lag 2 both address those two contributors by limiting queue depth and pacing the present call to occur as late as possible while still meeting the frame budget. The catch is that both technologies require game-engine cooperation through a vendor SDK, and GPUs not on the supported hardware list see no benefit.
The new low_latency_layer project tries to deliver most of the same benefit without the SDK dependency. It works above the driver, hooks DXGI and Vulkan present paths, measures CPU and GPU frame times, and inserts pacing waits to close the render-to-photon gap. None of this is new conceptually — the per-game tuning community has been shipping similar techniques as Special K plug-ins for years. The contribution is packaging the technique as an installable, vendor-neutral component that just works on most modern titles.
Who benefits most?
Three buyer profiles see the largest real-world delta. First, the competitive esports player on a "previous-gen-but-still-fine" GPU like the RTX 2070 Super or RX 5700 XT. Those cards have plenty of raster headroom but never got an official Reflex or Anti-Lag 2 toggle. Second, the 1080p high-refresh-rate player whose game runs at 240+ FPS but who still feels mushy input because the render queue keeps frames buffered. Third, anyone on an Intel Arc card who has been quietly left out of both vendors' latency story entirely. For all three, low_latency_layer is an obvious experiment.
The crowd that benefits least is the player already on current-gen NVIDIA or AMD hardware with vendor Reflex or Anti-Lag 2 enabled in supported titles. There, the official SDK has tighter engine integration and the latency floor is already close to optimal. The shim cannot beat the vendor's first-party path; it can only reach approximate parity.
How it actually works under the hood
Per the project's published technical notes (and matching what longer-running tools like Special K have done for years), the layer operates in three steps.
- Hook the present path. The shim intercepts the application's present call to DXGI or Vulkan and inserts itself between the application and the swapchain.
- Measure frame budget. It tracks CPU frame time and GPU frame time on a rolling basis to predict how long the next frame will take.
- Pace the present. Instead of letting the application queue frames as fast as it can, the shim delays present until the GPU is ready, then issues it tight against the refresh window. That tightening is what closes the click-to-photon gap.
The end result is similar to the official Reflex behavior: render queue depth approaches one, the GPU is rarely idle waiting on vsync, and the input poll happens later in the frame so the pixel reflects newer input.
Realistic latency numbers
There is no independent benchmark study yet, but per the community measurements posted alongside the release, expected click-to-photon latency improvements in the 8-20 ms range are typical on titles that previously buffered two to three frames. That is meaningful — the difference between feeling "responsive" and "snappy" — but it is not a magic-bullet upgrade. The realistic comparison table reads roughly:
| Configuration | Click-to-photon (ms, 240 Hz monitor) |
|---|---|
| Default driver settings, no FPS cap | 35-55 |
| FPS cap at 95% refresh, V-Sync off | 22-34 |
| FPS cap + low_latency_layer | 16-26 |
| Vendor Reflex / Anti-Lag 2 (where supported) | 14-22 |
| Wired esports baseline (RTX 5080 + Reflex + 480 Hz) | 9-14 |
These figures are aggregated community measurements, not lab data. They line up with what the original Reflex SDK documentation reports as typical improvement deltas, which is the right sanity check.
How to try it
Per the project documentation, the path of least resistance is:
- Install the layer via a portable binary or community installer. Avoid version-pinned bundled installers from forks; use the project's own releases.
- Identify the executable for the game you want to tune. The layer needs to know which process to attach to.
- Set a frame rate cap in the game or via RTSS at roughly 95-97% of your monitor refresh.
- Disable V-Sync in the game settings.
- Launch with the layer enabled and verify the overlay or log confirms hooking.
- Measure with an in-game latency monitor (NVIDIA's overlay, AMD's hardware reporter, or LDAT if you own one).
If a game refuses to hook or crashes on launch, the most common cause is anti-cheat compatibility — disable for offline modes or skip the title.
Anti-cheat compatibility
This is the practical hazard. Kernel-level anti-cheats (EAC, BattlEye, Vanguard, Ricochet) are aggressive about flagging any process injection that touches the rendering pipeline. The low_latency_layer project's posture is that the layer does not modify game memory and limits its activity to standard DXGI and Vulkan APIs, but anti-cheats do not always read intent — they pattern-match. Until major anti-cheats publish compatibility statements, treat the layer as a single-player and casual-multiplayer tool. Do not use it in tournament play and do not use it in any title where a ban risks an account or rank.
When it beats a simple FPS cap
The FPS-cap-plus-V-Sync-off recipe gets you about 60-70% of the way to vendor Reflex behavior. The remaining 30-40% comes from the present-time pacing that low_latency_layer adds. That extra delta is most visible in titles with variable frame times — open-world games, anything CPU-bound at the wrong moment, anything with shader compile stutter. In a pure esports engine that already runs at locked 360+ FPS, an FPS cap alone is the bulk of the win and the shim is incremental.
When it is the wrong tool
- You are on supported hardware with vendor Reflex or Anti-Lag 2 enabled. Stick with the first-party implementation.
- You play kernel-anti-cheat-protected competitive titles. Risk is not worth the ms savings.
- Your monitor is 60-75 Hz. The latency floor is already dominated by the refresh interval; the shim's gains shrink to near-noise.
- You run windowed-mode with desktop composition active. The compositor adds latency that the shim cannot remove.
Common pitfalls
- Stale game profiles. Per-title pacing profiles drift as games update. If a game suddenly feels worse, recheck the profile.
- CPU bottlenecks masquerading as latency. Low_latency_layer cannot help if the CPU is the binding constraint. Profile before blaming the shim.
- Mixed-vendor systems. Hybrid laptops and certain Optimus setups complicate the present path. Expect more setup pain on laptops than desktops.
- Overlay conflicts. Stacking the layer on top of Discord overlay, Steam overlay, RTSS, and an in-game capture utility eventually produces crashes. Strip overlays until you find the stable minimum.
- Driver upgrades stomping the hook. A major driver release can break the layer until the project ships a compatibility update. Pin your driver until the layer's changelog confirms support.
Hardware that pairs well
For the latency-conscious 1080p high-refresh-rate setup the layer is built around, three pieces of hardware pull most of the weight. A 165 Hz or higher monitor is the foundation — the layer can shave milliseconds, but you need refresh headroom to perceive the result. A precision esports mouse with a sub-1 ms sensor latency keeps the input side of the equation honest. And a GPU with enough headroom to lock above your monitor refresh is the third leg of the triangle. Without all three, the layer's gains either cannot be perceived or cannot be realized.
Real-world measurement methodology
If you want to evaluate the shim's gains yourself rather than trust community numbers, the right setup uses NVIDIA's free LDAT-equivalent counters in their overlay (Performance > Latency), AMD's Hardware Reporter in the Adrenalin overlay, or a high-speed camera pointed at the screen and mouse together. The camera method is the most accurate but the most fiddly; the in-driver counters are good enough for comparative measurements as long as you keep the test setup identical between baseline and shim-enabled runs.
A reasonable test protocol: run an esports title in offline practice mode, target an identical frame rate cap in both runs, take 30-second samples of click-to-photon latency under typical input load, and average. Run each condition five times to filter outliers. The shim's gain should land in the 8-20 ms range described above; if you see no gain at all, the title's render queue was probably already shallow and the shim has nothing to optimize.
The bigger picture
The interesting part of this story is not the immediate latency delta. It is the precedent. Vendor SDKs have been the gating mechanism for advanced latency features for half a decade. A vendor-neutral, open-source layer that approximates that behavior changes the competitive dynamic. Either NVIDIA and AMD respond by opening Reflex and Anti-Lag 2 more broadly, or the community implementation steadily improves and the official SDKs lose relevance for the long tail of titles that never got official support. Either way, players win.
The risk is that the layer's success draws vendor pushback that closes hooks the project depends on. Special K has lived in that tension for years and survived. Low_latency_layer is positioned similarly. Realistic expectation: it is here to stay, it will improve, and it will not displace vendor implementations on supported hardware — but it will keep a couple of GPU generations from feeling obsolete for another year.
Game-by-game expected impact
Treat the per-game gain as a rough function of the title's pre-existing latency profile.
- Counter-Strike 2: Already heavily latency-optimized; expect 3-6 ms improvement. Worth it for competitive play.
- Valorant: Anti-cheat sensitivity is the risk; do not run the shim in ranked.
- Apex Legends: 8-14 ms improvement reported by community measurements; meaningful in close-range gunfights.
- Overwatch 2: 6-10 ms; helps with hitscan precision more than projectile timing.
- Fortnite: 5-12 ms; most variable because frame times in this engine swing wildly with shader compilation.
- PUBG: 10-18 ms; one of the larger gains because the engine never invested heavily in render-queue tuning.
- Single-player AAA (Cyberpunk, Spider-Man, Alan Wake 2): 12-22 ms; gain shows up most when the GPU is running near its frame budget.
These numbers are aggregated community measurements; treat them as ballpark guidance, not lab data.
Compatibility with frame-generation tools
Layered on top of NVIDIA DLSS 3 Frame Generation or AMD FSR 3 Frame Generation, the shim's effect compounds in surprising ways. Frame-generation techniques add 5-12 ms of input latency in exchange for higher displayed FPS; tightening the present path with the shim partially offsets that latency penalty. For non-competitive titles where you want both the smoother display and the lower input latency, the combination is interesting. For competitive titles, frame generation is the wrong tool regardless of whether the shim is involved.
Related guides
Citations and sources
- NVIDIA Reflex official page
- AMD Adrenalin Anti-Lag page
- Phoronix — Linux and open-source hardware coverage
This piece is editorial synthesis based on publicly available information. No independent first-party benchmarking is reported.
