Frame generation is a rendering technique that synthesizes additional frames between those the game engine actually renders, so the display shows a higher frame rate than the GPU produces through normal rendering. Among graphics settings, it is the option that raises visual smoothness without raising the simulation rate, and it is offered in implementations such as DLSS Frame Generation, FSR Frame Generation and XeSS Frame Generation.
The key point is that generated frames are not real game updates. They are predictions built from motion data, so they improve how fluid motion looks but do not make the game react faster to input. Used well, frame generation turns a solid 60 fps into roughly 100 to 120 fps on screen; used on a weak base frame rate, it can amplify latency and artifacts.
How frame generation creates frames
Current implementations use frame interpolation: the game renders frame A and frame B, and the generator creates one or more intermediate frames that are shown between them. To do that, it needs to know how each part of the image moved, so it combines engine motion vectors, the depth buffer and an optical flow estimate that captures motion the engine does not report, such as shadows, reflections and particles.
Because the generator must wait for frame B before it can show anything between A and B, interpolation holds back the newest rendered frame. That is the source of the added latency. To offset it, vendors pair frame generation with a latency reduction technology that shortens the render queue, such as NVIDIA Reflex, AMD Anti-Lag or Intel XeLL.
The heads-up display is a special problem. Text and menus do not move with the scene, and interpolating them produces smeared or doubled UI elements. Integrated implementations therefore receive the HUD separately or mask it, while driver-level solutions that see only the final image are more prone to UI artifacts.
Frame generation implementations
Several vendors offer frame generation, and they differ in hardware requirements, generated frame count and integration level. The table summarizes the main families as they are commonly deployed.
| Implementation | Integration | Generated frames | Hardware scope |
|---|---|---|---|
| DLSS Frame Generation | In-game, through the DLSS SDK | One per rendered frame | NVIDIA RTX 40 series and newer |
| DLSS Multi Frame Generation | In-game, through the DLSS SDK | Up to three per rendered frame | NVIDIA RTX 50 series |
| FSR Frame Generation | In-game, open source | One per rendered frame | Broad support across GPU vendors |
| AMD Fluid Motion Frames | Driver level | One per rendered frame | Supported AMD Radeon GPUs |
| XeSS Frame Generation | In-game, through XeSS 2 | One per rendered frame | Intel Arc GPUs |
| Third-party interpolation tools | Applied to the final image | One or more | Most GPUs, lower image quality |
In-game integrations generally look better because they receive motion vectors and depth directly from the engine. Driver-level and external tools work in games without native support, but they must estimate motion from finished images alone, which produces more visible errors around fast motion and on-screen text.
Frame generation compared with upscaling
Frame generation is often bundled with DLSS, FSR and XeSS upscaling, but the two features solve different problems. Upscaling reduces the cost of each real frame by rendering at a lower resolution, while frame generation adds synthetic frames between real ones.
| Aspect | Upscaling | Frame generation |
|---|---|---|
| What it changes | Pixels per rendered frame | Number of displayed frames |
| Effect on input latency | Usually lowers it | Raises it slightly |
| Effect on simulation rate | Can raise it | None |
| Typical artifacts | Softness, shimmering | Ghosting, UI smearing, warped edges |
| Best use | GPU-limited scenes | Smoothing an already playable frame rate |
The two are complementary. A common setup uses upscaling first to reach a stable base frame rate, then frame generation to fill a high refresh rate display. Frame generation also helps in CPU bottleneck situations, because generated frames do not require new game logic or draw calls.
When to enable frame generation
The most important rule is that frame generation works best on a base frame rate of about 60 fps or more. Below that, each generated frame must bridge a larger motion gap, so artifacts become visible, and the added latency is felt more because each real frame already takes longer.
| Situation | Recommendation | Reason |
|---|---|---|
| Base 60 to 90 fps, 144 Hz or faster display | Enable | Smoother motion with modest latency cost |
| Base 30 to 40 fps | Avoid or test carefully | Artifacts and sluggish controls |
| Competitive shooter | Usually disable | Lowest latency matters more than smoothness |
| Slow single-player game | Enable | Smoothness improves presentation |
| Output above display refresh rate | Cap the frame rate | Prevents tearing and wasted frames |
Frame generation interacts with display sync. With VRR technologies such as G-SYNC and FreeSync, the output should stay inside the display’s variable refresh range, which usually means capping the frame rate a few frames below the maximum refresh rate. Turning on V-Sync without a cap can add further latency.
Limitations and misconceptions
The most common misconception is that a frame counter showing doubled numbers means doubled performance. The game still samples input and updates physics at the base rate, so responsiveness tracks the rendered frame rate, not the displayed one.
- Benchmark comparisons that mix generated and rendered frame rates are not like-for-like.
- Disocclusion artifacts appear when objects reveal background areas that neither source frame showed.
- Fine repeated patterns such as fences and foliage can confuse optical flow.
- Frame pacing problems arise if real frames arrive unevenly, producing judder despite high averages.
- Video memory use rises slightly, which matters on GPUs with limited VRAM.
In simple terms
A game draws a series of pictures every second. Frame generation adds a guessed picture between each pair of real ones. The motion on screen then looks smoother, a bit like an animator drawing in-between frames.
The catch is that the guessed pictures do not come from the game itself. The game does not react any faster to the controller. It simply looks more fluid. That is why it works best when the game already runs reasonably well.
A practical example
A player runs a demanding single-player action game on a 165 Hz monitor. With upscaling in quality mode, the game renders about 70 fps, which feels responsive but looks less fluid than the display allows.
The player enables frame generation together with the vendor’s latency reduction setting and caps the output at 158 fps to stay inside the monitor’s variable refresh range. The displayed frame rate rises to around 130 to 140 fps, and camera pans look clearly smoother.
Latency measured by the overlay increases by only a few milliseconds compared with the same setup without frame generation. When the player later tries the same settings in a fast online shooter, the slightly heavier feel of aiming leads to a different choice: frame generation off, lower settings and the highest rendered frame rate.