A couple of weeks ago, NVIDIA provided us with the second iteration of their Latency Display Analysis Tool (LDAT), a small device that is strapped onto a monitor, measures brightness changes, and provides us with end-to-end system latency data—the so-called mouse to photon latency. This nifty little gadget allows us to put the NVIDIA Reflex technology through its paces, and we intend to integrate it into our monitor-testing methodology as it’s an excellent replacement for our existing high-speed camera setup, but more on that later in this article.
For starters, let’s focus on NVIDIA Reflex, an interesting latency-reduction technique NVIDIA released with their RTX 30-series “Ampere” graphics cards, but also fully supported in their GeForce RTX 20-series “Turing,” as well as older GeForce 9 and 10-series GPUs. In fact, as you’ll soon see from my test results, NVIDIA Reflex makes the biggest difference in GPU-bound scenarios, so if you’re running a high-end graphics card at non-4K resolution, you’re unlikely to reap any benefit from it. At the same time, it will massively improve your gaming experience on mainstream graphics cards if the game in question supports it.
As some of you surely know, NVIDIA collaborated with ASUS and Dell on their 360 Hz Full HD G-Sync monitors, the ROG Swift PG259QN and Alienware AW2521H. Both are equipped with the Reflex Latency Analyzer (RLA), an in-display hardware tool that has to be combined with the GeForce Experience software and a supported mouse. At this time, the following mice are supported: Logitech G Pro Wireless, ASUS ROG Chakram Core, Razer DeathAdder V2 Pro, and SteelSeries Rival 3. All of them have a familiar and low click latency, which is why they were chosen. You can then measure data like mouse latency, PC + display latency, and whole system latency inside of a performance overlay. Even though RLA and the aforementioned monitors are part of the Reflex ecosystem, it is important to point out that I won’t be focusing on them in my review. The LDAT v2, a device I’ve described above, is a reviewer-only tool that works with any monitor. It can be used in many different scenarios and for several different tests, including monitor input lag and potentially even mouse click latency testing. Of course, NVIDIA provided it primarily to show off its Reflex technology, so this is what I’ll be discussing going forward.
In essence, NVIDIA Reflex is a driver-driven framerate limiter. When you find yourself in a GPU-bound scenario, a situation in which your graphics card is overwhelmed with incoming data, the incoming frames have to wait in a render queue for GPU resources to become available. This is of course a massive simplification of the rendering process, but it’s exact enough to explain why gamers not only have to deal with lower framerates but also increased system latency in GPU-bound scenarios. The idea behind NVIDIA Reflex is to establish a deep level of CPU and GPU synchronization, which would result in the CPU providing the GPU with only as many frames as it can render at any given moment. With no frames stuck in the proverbial waiting line, the maneuvers you do on your mouse pad would find their way to the screen significantly faster.
In their Reflex-related press materials, NVIDIA spends a dubious amount of time pointing out the importance of latency as a key gaming performance metric, up there with frames per second. Their point is valid; I too feel that latency doesn’t get enough credit when discussing the performance of a system. We’re not talking about network latency, the time it takes data to reach a game server and come back (often referred to as “ping”). Pretty much everyone understands what ping is and how it impacts their multiplayer gaming experience. What NVIDIA is talking about is system latency—the latency introduced by your mouse, USB interface, CPU, game engine, GPU, and display. Here’s a nice chart, followed by NVIDIA’s detailed explanation of the system latency chain, to which I don’t have anything meaningful to add.
Many components contribute to overall system latency, not only physical components, such as the peripheral (mouse), PC (system), and display, but also software components, such as the game running on the OS and the rendering operations of the GPU. Once a user presses the mouse in a game, that event data is sent to the PC, where it is processed by many components and subsystems inside the PC including the CPU, operating system (Windows), game application, render queue, GPU, and then the OS compositor. Next, it goes through scan-out, which technically happens on the GPU, but is initiated by the display before it’s finally processed and displayed on screen.
The time it takes for this to happen is called the pixel response time. The preceding diagram shows a high-level and medium-level view of all the various components that contribute to latency in a system. PC gaming includes processing by a complex system of serial and parallel pipes, but we will do our best to break down the basic concepts. If a game feels laggy, it’s likely because you are experiencing high system latency due to any of the smaller latency areas shown above, which is exactly what we’ll measure with the LDAT. It measures the complete “mouse-to-photon” timing, which includes processing by all of the above hardware and software systems.