Nvidia LDAT & PCAT – What Are They?

What are the Stages of Latency?

It’s far more complicated than you might think, but it starts with something as simple as a mouse click or a keystroke, and it ends when you see the action played out on screen. Plus the trigger, see the shot, but today, it’s everything that happens between those two events that are of interest. If you can improve and measure that improvement throughout the whole chain of peripheral, PC and display latency, you’ll get your all-important end-to-end system latency figure. LDAT is designed to give you that number, much like a traditional benchmark, it’ll simply spit out a number at the end of testing, and then you can see if you can improve that number.

Nvidia’s LDAT has this lovely list of stages, and as I said, you can see how complicated this can be. Any one of these stages could be your problem area (if you have one) and all could be improved in one way or another.

• Mouse HW – This is defined as the first electrical contact when the mouse is ready to send the event down the wire. In the mouse, there are a few routines (such as debounce) that add latency to your mouse button press.
• Mouse USB HW – The mouse has to wait on the next poll to send the packets down the wire. This time is reflected in USB HW.
• Mouse USB SW – Mouse USB SW is the time the OS and mouse driver handle the USB packet.
• Sampling – This section can grow or shrink based on your CPU framerate. Clicks can come into the OS based on a polling rate of 1000Hz (typically). This means that the click may have to wait for the next opportunity to be sampled by the game. That waiting time is called sampling latency.
• Simulation – Games constantly have to update the state of the world. This update is called Simulation. Simulation includes things like animations, the game state, and changes due to player input. Simulation is where your mouse inputs are applied to the game state.
• Render Submission – As the simulation figures out where to place things in the next frame, it will start to send rendering work to the graphics API runtime. The runtime in-turn hands off rendering commands to the graphics driver.
• Graphics Driver – The driver is responsible for communicating with the GPU and sending it groupings of commands. Depending on the graphics API, the driver does this grouping for the developer or the developer is responsible for grouping rendering work.
• Render Queue – Once the driver submits the work, it enters the Render Queue. The render queue is designed to keep the GPU constantly fed by always having work for the GPU to do. However, this comes at the cost of latency.
• Render – The time it takes for the GPU to render all the work associated with a single frame.
• Composition – Depending on your display mode (Fullscreen, borderless, windowed), Desktop Windows Manager (DWM) has to submit some additional rendering work to composite the rest of the desktop for a particular frame. This can add latency.
• Scanout – finally, the flip occurs (the currently displayed frame buffer is swapped to the newly completed frame buffer) and scanout is scheduled. Scanout feeds the display line by line based on the Hz of the display. Which is why we have included it into display latency.
• Display Processing – Display Processing is the time the display takes to process the incoming scanlines and initiate the pixel response.
• Pixel Response – This is the time it takes from when the pixel received the new color value to the first detectable change by LDAT. See the note below.