For fixed DLSS Frame Generation on a VRR display, start with the game’s supported Reflex and synchronization setup, then use a single effective limit that keeps displayed FPS below the refresh ceiling and within performance you can sustain. If an automatic limit already does that, an additional manual cap may be unnecessary.
There is no universal “refresh rate minus three” setting for every game. Dynamic Multi Frame Generation needs its own approach, and a fixed-refresh 60 Hz screen needs different expectations from a 144 Hz G-SYNC display. I would identify the display and generation mode before choosing any number.
01Choose the target your display can use
A frame cap sets a ceiling; it cannot make the system reach it. The useful ceiling depends on the monitor’s refresh rate, whether variable refresh rate is active, the frame rate the game can maintain and how its limiter interacts with generated frames.
Variable refresh rate, or VRR, allows the screen to adjust its refresh timing within a supported range. When displayed FPS repeatedly reaches or crosses its upper boundary, synchronization behaviour can change. Keeping output below that ceiling gives a conventional VRR setup room to operate.
| Configuration | Where I would start |
|---|---|
| Fixed FG with G-SYNC / VRR | Enable supported Reflex and sync settings. Check whether an automatic limit already stays below refresh. |
| Fixed FG, no automatic limit | Test one compatible limiter with an output target below the VRR ceiling and within sustainable performance. |
| Dynamic MFG | Start with its own refresh-rate or custom target. Confirm the installed integration’s support before adding another limiter. |
| Fixed-refresh screen | Compare supported synchronized FG with FG off. A below-refresh cap alone cannot create VRR or guarantee tear-free output. |
I would prioritize a stable result in a demanding gameplay section over a cap selected from an empty room. A target the game reaches only occasionally is not a pacing solution.
02Separate rendered FPS from displayed FPS
Frame Generation inserts additional images into the output stream. The resulting displayed FPS is different from the rate at which the engine renders new frames. When someone recommends a cap of 120, you need to know which rate their setting actually controls.
A limiter may operate on the game’s rendering cadence or through a Frame Generation-aware integration. Do not assume the number in its menu always means the final output rate. Read the available metrics and check what changes when generation is enabled.
As a hypothetical example, a base rate of 60 rendered frames with one inserted image per frame suggests roughly 120 presented frames per second. That is arithmetic describing a 2X stream, not a benchmark prediction. Generation overhead, scheduling and dropped generated frames can change the observed result.
Do not automatically halve your preferred cap. First establish the limiter’s behaviour. If a setting already controls final output, halving it again can unnecessarily lower the game’s rendering rate and make control feel worse.
03Use refresh-minus-three as a trial, not a rule
For a conventional manual VRR experiment, values such as 141 on a 144 Hz screen or 162 on a 165 Hz screen are reasonable starting candidates. They are examples of leaving a small margin, not official universal DLSS targets. The correct result is observed output that stays below the ceiling without avoidable loss of responsiveness.
Limiter overshoot, automatic Reflex behaviour and the specific integration can change the margin required. If the output already holds at a lower automatic limit, entering another higher number does not necessarily change anything. If a candidate cap still crosses the refresh ceiling, a slightly lower target may be more useful.
144 Hz example
Try a compatible output target below 144 only when a manual cap is needed. Verify the actual rate; do not assume a 141 setting limits the final generated stream.
Performance-limited example
If a hypothetical game repeatedly falls below 100 displayed FPS, a 141 ceiling cannot stabilize those dips. Improve the underlying workload or compare a lower sustainable target.
The relevant margin is a control decision, not a performance gain. I would keep the highest sustainable target that remains within the intended synchronization range and feels consistent in normal play.
04Let Reflex and the game cooperate before adding caps
NVIDIA’s latency guidance describes G-SYNC with V-Sync and Reflex as a route to automatically limiting FPS below refresh in supported configurations. For fixed FG, that makes a sensible first comparison when your priority is tear-free presentation. Confirm the behaviour in the actual game instead of assuming every integration uses the same ceiling.
Enable the game’s supported Reflex option and check its synchronization guidance. The separate driver Low Latency Mode is not an additional layer of Reflex performance. The Cubetoons latency settings guide explains how to choose between those controls.
Keep one deliberate limiter for the initial test. Record and temporarily remove redundant manual caps from the game, driver and third-party tools, while retaining the supported synchronization configuration. Automatic scheduling remains part of the integration; the point is to avoid several unrelated manual ceilings obscuring what controls the result.
If the automatic setup already produces stable output below refresh, my recommendation is to leave the extra limiter off. Add a manual cap for a defined reason, such as a lower sustainable target or power preference, then compare against that baseline.
05Dynamic Multi Frame Generation has version-specific rules
Dynamic MFG adjusts the multiplier toward a display-refresh or custom target on supported RTX 50-series configurations. Start with that built-in target rather than immediately combining it with an external limiter. If the mode is unavailable, use the sister-site Frame Generation availability checks before investigating pacing.
Older NVIDIA launch guidance says Dynamic mode is incompatible with V-Sync and frame-rate limiters. That statement needs a version qualifier now: Streamline SDK 2.14.1 added support for those combinations. An SDK capability does not establish that every shipped game or NVIDIA app override path has adopted it.
NVIDIA’s current Frame Generation integration guide specifies a Reflex-aware limiter for Dynamic mode and cautions that other limiting techniques may behave unexpectedly. Follow documentation for the installed game and override path; do not translate “limiter support added” into “every external limiter works.”
For an uncertain installation, I would begin with Dynamic’s own target and no additional manual cap, using its documented synchronization configuration. If that fails to give the pacing you want, compare a supported fixed mode rather than forcing several competing controls.
06Improve the base frame rate before increasing the multiplier
A larger output number does not give generated frames new game-simulation or input updates. If the base rendering cadence is slow or uneven, adding more intermediate images cannot turn it into equally responsive native high-FPS play.
I would first lower the settings responsible for the limiting workload. Ray tracing, render resolution and CPU-heavy settings deserve separate comparisons; changing all of them together hides what helped. Keep the generation mode unchanged during that workload check.
On a fixed-refresh 60 Hz screen, compare FG off before assuming FG is worthwhile. If the game already maintains a responsive 60 rendered FPS, extra generated output may offer little practical benefit for that display. If it cannot, a generated 60 FPS result can look smoother while still feeling different from native 60.
High multipliers also deserve caution on low-refresh displays. NVIDIA documents increased queuing latency with some high-multiplier V-Sync combinations. I would reduce the multiplier before lowering the base rendering target just to preserve a larger advertised output figure.
07Judge pacing with a repeatable gameplay comparison
Use a short route with camera movement, steering or aiming and one demanding area. Keep resolution, upscaling, graphics settings, display mode and generation multiplier steady. Change only the limiter or target you are evaluating.
- Confirm the display. Check its active refresh rate and whether VRR is actually enabled for the gameplay mode.
- Record the baseline. Note rendered and displayed FPS where available, synchronization, Reflex, mode and every active manual cap.
- Test one target. Use a supported limiter for fixed FG, or Dynamic’s own target for the initial Dynamic comparison.
- Repeat the route. Look for ceiling crossings, persistent uneven motion and changes in control response. Separate those observations from isolated loading hitches.
- Keep or revert. Retain the change only if it improves the result you care about. Relaunch when the game requires it.
For technical captures, choose presentation-aware tooling. NVIDIA distinguishes actual display-change timing from internal Present-call timing; a generic frametime graph may not fully represent generated-frame delivery. Treat an unclear metric as limited evidence rather than proof that the cap failed.
A cap also cannot resolve every source of stutter. If the same location produces a long hitch with several reasonable targets, investigate the workload or game behaviour separately instead of endlessly adjusting a ceiling.
08Frequently asked questions
Should I cap at half my monitor’s refresh rate?
Only if you have established that the specific control acts on the pre-generation rendering rate and that the resulting response is acceptable. Do not apply a half-refresh rule to an output-aware limiter.
Is RTSS always the best limiter for DLSS FG?
No universal recommendation fits every integration. Start with the game’s documented supported control and compare one alternative at a time. Dynamic MFG particularly needs compatibility checks.
Can I eliminate tearing by capping a fixed-refresh screen below refresh?
A cap alone does not synchronize scanout. Use a supported synchronization option when tear-free presentation matters, then assess its latency trade-off.
What should I try first on an RTX 4090?
Use supported ordinary DLSS FG with Reflex, identify the display’s VRR behaviour and check the effective ceiling. Official Dynamic MFG requires RTX 50 hardware; its setup is not the starting point for a 4090.
09Keep the simplest configuration that stays consistent
For fixed FG, verify the automatic Reflex and synchronization result before adding a manual cap. For Dynamic MFG, begin with its own target and check integration-specific compatibility. Choose a sustainable output rate, preserve a responsive base cadence and judge the same gameplay sequence each time.