Frame generation: why doubling FPS does not halve latency

Frame generation can turn a 60 FPS reading into something close to 120 FPS, but that does not mean the game is calculating input, physics, and animation twice as quickly. Technologies such as NVIDIA DLSS Frame Generation, AMD FSR Frame Generation, and Intel XeSS-FG insert intermediate images between frames produced by the engine. The result can look smoother while control response remains tied mainly to the pace of the frames that are actually rendered.

This difference explains why two games reporting 120 FPS can respond differently. One may be rendering 120 complete states every second; the other may render roughly 60 and present approximately 60 synthesized images between them. The counter measures how many images are displayed, but it does not explain how each image was created or how much time passed between an input and its visible consequence.

How an intermediate frame is created

The generator compares sequential frames and receives engine data such as motion vectors and depth. NVIDIA’s implementation also uses optical flow, which estimates the apparent displacement of pixels. With this information, the system predicts a plausible image for the instant between two rendered frames.

The process does not run the entire simulation again. Enemies, physics, the camera, and input continue to update on the original frames. The synthesized frame visually represents an intermediate position based on known data. Calling these images only “fake frames” hides a useful distinction: they are real images presented by the display, but they do not correspond to a complete new step in the game state.

Upscaling is not the same thing

Commercial names often bundle different features. Super Resolution, FSR Upscaling, and XeSS Super Sampling render a frame at a lower internal resolution and reconstruct it for the output resolution. Frame generation instead adds images between temporal frames. Both can be used together: upscaling raises the base rate, while interpolation multiplies the number presented.

This combination also complicates comparisons. A result advertised as “four times the performance” may combine a lower internal resolution with multiple generated frames. Motion becomes smoother, but the gain is not equivalent to quadrupling the GPU’s raw capability. A configuration should be evaluated through its pre-generation rate, image quality, and latency rather than the final counter alone.

Why the base rate determines quality

The wider the time gap between original frames, the more the algorithm must predict. Fast movement, newly revealed areas after occlusion, particles, transparency, and interface elements can provide incomplete or conflicting information. The result may include unstable edges, duplicated details, or deformation that lasts only milliseconds but becomes visible in motion.

AMD recommends an input of at least 60 FPS before interpolation for its FSR 3 and 3.1 implementations and advises against input below 30 FPS. That guidance is not a universal rule for every version and vendor, but it illustrates the principle: frame generation works better as a multiplier for an already playable experience than as a rescue for a very low base rate.

Higher FPS does not guarantee lower latency

Latency is the time between player input and the corresponding change appearing on the display. The path includes device polling, CPU processing, simulation, the render queue, GPU work, and screen refresh. A generated frame can reduce the visual interval between images, but it does not contain a fresh mouse or controller sample taken halfway through that path.

Interpolation also normally needs to analyze temporal data before presenting its intermediate image. Vendors pair it with low-latency systems to control that cost. NVIDIA Reflex synchronizes CPU and GPU work to reduce queues. AMD Anti-Lag 2 aligns work from both processors. Intel requires XeLL for XeSS-FG integration and uses its timing data to organize presentation pacing.

These systems can offset some waiting and, in certain configurations, produce lower total latency than poorly queued native rendering. That does not change the generated frame’s nature: responsiveness and smoothness remain related but distinct measurements.

When to enable it and when to prioritize rendered frames

In adventures, simulators, and games with demanding effects, a stable base near or above 60 FPS can use frame generation to better fill a 120 Hz or faster display. The added fluidity helps camera movement and animation without requiring every image to be calculated in full.

Competitive games usually change the priority. When immediate response matters more than cinematic smoothness, lowering resolution, ray tracing, or graphics quality to raise the rendered rate is generally more useful. Frame generation is also less attractive when the base rate fluctuates heavily, the CPU limits simulation, or interface artifacts become distracting.

The accurate framing is therefore not a choice between “real frames” and “fake frames.” It is to separate three questions: how often the game updates its state, how many images reach the display, and how long an input takes to become visible. Frame generation mainly improves the second measurement; the others depend on the rest of the pipeline.