How Much Performance Does DLSS Give? Measure the Gain Correctly
Oct 30, 2026 · Sourajit Saha
DLSS has no fixed performance gain. Super Resolution can improve frame rate when lower-resolution rendering saves more GPU time than reconstruction costs, while Frame Generation increases displayed frame counts through a different mechanism. A result from one game or GPU is not a promise for yours.
I would measure reconstruction and generation separately, using the same scene and settings. That tells you whether the gain comes from faster rendering, additional displayed frames, or both—and whether the improvement is useful on your monitor.
01The performance result starts with the bottleneck
A frame can be limited by GPU rendering, CPU simulation and submission, memory pressure, or a cap. Lowering the internal pixel count mainly targets work that depends on rendering resolution. It does not automatically make a CPU finish simulation faster or remove a fixed refresh-rate limit.
For that reason, a demanding high-resolution scene can show a larger reconstruction benefit than an already CPU-limited low-resolution scene. This is a workload explanation, not a percentage prediction. You need measurements under your own settings to establish the magnitude.
Reconstruction itself also takes GPU time. More sophisticated models can trade extra processing for better stability or image quality. I would not assume that a newer model is a free performance upgrade, especially when moving between GPU generations with different capabilities.
NVIDIA’s resolution scaling explanation describes how supported modes change input resolution. That explains the lever you are moving; it does not establish a universal FPS multiplier.
02Input-pixel reductions are not FPS predictions
A mode that halves each dimension renders one quarter as many input pixels. For example, 1920 × 1080 contains about 2.07 million pixels and 3840 × 2160 contains about 8.29 million. This is arithmetic about image dimensions, not a benchmark claim that the entire game becomes four times faster.
The frame still includes other work: simulation, geometry handling, synchronization, reconstruction, interface composition, and tasks that do not scale proportionally with pixel count. If much of the frame time lies elsewhere, removing input pixels cannot remove all of that cost.
Consider a clearly hypothetical GPU frame containing 10 milliseconds of resolution-sensitive work and 6 milliseconds of other work. Even an imaginary perfect removal of half the first category would leave 11 milliseconds, not 8. Real reconstruction adds its own cost, so this example is deliberately a reasoning aid rather than an estimate for a particular game.
This is why “it renders fewer pixels” is a useful explanation but an incomplete performance answer. Measure the time actually saved, and decide whether the image trade-off is acceptable.
03Calculate and report the gain transparently
For an ordinary rendered-FPS comparison, percentage gain equals the difference between the new and baseline FPS, divided by baseline FPS, multiplied by 100. If a hypothetical baseline is 50 FPS and the new result is 70 FPS, the gain is 40 percent. Those numbers are an illustration, not a test result from this site.
Frame time tells another part of the story. In that hypothetical example, average frame time changes from 20 milliseconds to about 14.29 milliseconds. A 40 percent FPS increase is not a 40 percent reduction in frame time. Be clear about which quantity you are reporting.
Keep the baseline visible in your notes: game build, GPU, driver, output resolution, graphics preset, ray tracing, reconstruction mode, and whether generation was enabled. “DLSS doubles FPS” without those conditions is not a reusable result.
If a chart includes generated frames, label it as displayed FPS and keep it separate from an evaluation of input response. Combining these measurements under one ambiguous performance label is how a visually smoother result gets mistaken for a proportionally faster simulation.
04Run a comparison that answers your actual question
Warm up the scene and use a repeatable route or built-in benchmark. Keep output resolution and every unrelated graphics option fixed. Disable dynamic resolution and generation for the initial reconstruction comparison, and check whether an FPS cap is hiding the difference.
Record several runs rather than relying on one momentary counter. Compare average performance, frame-time consistency, and noticeable stalls. A higher average that still contains disruptive spikes may not solve the complaint that brought you to the settings menu.
Next, test a different reconstruction mode only if you need more headroom. Inspect fine details and moving objects at the same time. A performance setting that makes important text unstable or creates distracting trails may not be a good trade for your game.
Then test Frame Generation separately, if supported. Watch camera motion and control feel, and check whether the display can actually present the increased output rate. Generated frames can improve smoothness without providing the same input-update cadence as an equally high newly rendered rate.
If you are using a cloud service, identify the remote rendering settings and the local stream limits before interpreting the counter. Our cloud optimization guide explains why network jitter and decoding delay are not repaired by a local DLSS profile.
05Use the result instead of chasing an advertised multiplier
If reconstruction produces little gain, check the bottleneck before assuming it is broken. A CPU ceiling, active cap, very low input resolution, or added model overhead can limit the improvement. Increasing an unrelated setting merely to make a benchmark comparison look larger is not a useful optimization.
If you gain performance but dislike the picture, try a higher-quality mode or lower one expensive effect instead. You can spend saved GPU time on better lighting, a quieter machine, or more stable delivery rather than maximizing the counter.
If generation raises displayed FPS but controls still feel slow, improve the base render rate and investigate latency separately. Do not expect interpolation to fix a simulation bottleneck or a long input queue by itself.
My recommendation is to keep a small per-game record with a baseline, one reconstruction candidate, and one optional generation test. Choose the configuration that reaches your actual display and responsiveness target with acceptable image quality. The meaningful gain is the one you can explain and use.
Frequently asked questions
Does DLSS always double performance?
No. Results depend on the workload, GPU, mode, model, and any bottleneck or frame-rate cap. Marketing examples do not establish a minimum gain.
Should I compare native FPS with generated FPS?
You can report both, but label the conditions and distinguish rendered performance, displayed output, and responsiveness. They do not measure the same thing.
Why does a lower input resolution sometimes barely help?
The frame may be limited by CPU work, a cap, or another cost that does not fall proportionally with pixel count. Reconstruction overhead also remains.