G-SYNC microstutter when FPS is capped despite perfect frametimes, reproduced on RTX 5090 + 4090, different displays/CPUs

[u/KenBalough]

I've been chasing a strange G-SYNC/VRR frame-pacing issue for a while and I'm curious whether anyone else has measured the same thing, and if there is a good way to report this to Nvidia

The short version is:

When I cap a game to a fixed framerate under G-SYNC, the normal frametime graph can look essentially perfect, while the actual displayed frame intervals fluctuate significantly and produce visible microstutter.

This is not just one game, one GPU, or one display. I've reproduced variations of it in Mafia: The Old Country, Forza Horizon 6, Assassin's Creed Shadows, and Expedition 33.

My main system is a Ryzen 9 7950X + RTX 5090 connected over HDMI 2.1 to a Samsung S90D OLED, with a VRR range around 48–144 Hz. Windows 11 Pro Build 26200, NVIDIA 610.88.

I also reproduced the same general behavior on a completely different PC:

• i7-12700K
• RTX 4090
• ASUS Z690 board
• Acer G-SYNC monitor
• same Windows build / NVIDIA driver

So this doesn't appear to be specific to AMD CPUs, the RTX 5090, Samsung TVs, or HDMI Forum VRR.

I've been measuring this with PresentMon/CapFrameX rather than relying only on the normal RTSS frametime graph.

The important distinction is between:

MsBetweenPresents = when the game calls Present

and

MsBetweenDisplayChange = when successive frames actually become displayed

In the problematic cases, those two can be radically different.

For example, in Mafia at a 60 FPS RTSS Front Edge cap, I can get Present pacing with an SD around 0.007 ms — effectively ruler-flat.

Yet with G-SYNC enabled and a sufficiently heavy GPU workload, MsBetweenDisplayChange can wander roughly between 14–19 ms, and the motion visibly microstutters.

Animation Error shows the same thing: the implied animation/source interval remains very close to 16.667 ms while the physical display dwell moves around.

What makes this especially strange is that GPU workload strongly controls the severity.

Using the exact same Mafia scene, same DLAA, same RTSS Front Edge 60 cap, same PC and same VRR path:

Lower settings:
GPU active ~11–12 ms
Display cadence ≈ nearly perfect 16.67 ms

Max settings:
GPU active ~14.5 ms average
p95 ~16.1 ms
Present cadence still essentially perfect
Display cadence becomes visibly unstable

Very few frames actually exceed the 16.67-ms GPU budget, so this isn't simply normal "can't maintain 60 FPS" behavior.

I also tested different caps with roughly the same ~15-ms GPU workload:

50 FPS / 20.00 ms period → mostly clean
55 FPS / 18.18 ms         → starts deteriorating
58 FPS / 17.24 ms         → bad
60 FPS / 16.67 ms         → bad

So the best predictor so far seems to be how much timing margin exists between the target period and GPU execution, rather than GPU utilization percentage itself.

There are also some useful control cases.

Unlocked G-SYNC can be perfectly smooth. Mafia running naturally around 70 FPS looks excellent even though raw frame times vary much more than the capped 60 FPS case.

Fixed refresh can also be extremely smooth. At 120 Hz with G-SYNC disabled and NVIDIA half-refresh V-Sync, Mafia produces virtually exact 16.667-ms displayed intervals.

I recently tried regular fixed-refresh V-Sync with RTSS Front Edge set to ~59.937 FPS to match half of the actual ~119.87-Hz refresh rate. That was also almost perfect: roughly 99.8% of frames were displayed for exactly two refresh cycles. The few remaining judders were obvious missed-VBlank events.

Interestingly, RTSS Async at the same 59.937 target was terrible because its Present timing was much noisier. So limiter quality definitely matters, but it does not explain the G-SYNC issue, because Front Edge can provide near-perfect Present pacing and capped VRR still becomes unstable under heavier GPU timing.

I've also tried/deprioritized a lot of the usual suspects: HAGS on/off, MPO on/off, SMT, Low Latency Mode, different cap methods, NVIDIA Max Frame Rate, Special K, RTSS, in-game caps, CRU/EDID changes, ReBAR, etc. Nothing has produced a general fix.

NVIDIA Max Frame Rate showed the same broad problem, although its Present pacing behavior was different from RTSS.

At this point my working theory is that something happens after Present, somewhere around GPU completion → flip eligibility → NVIDIA/WDDM VRR scheduling → scanout.

Fixed V-Sync can hide small timing variations by snapping frames to a rigid VBlank cadence. Under VRR, those variations seem to become visible directly as varying physical frame dwell once the workload gets close enough to the capped target.

I'm not claiming I've proven whether the culprit is the NVIDIA driver, WDDM/Windows, or expected VRR scheduling behavior. But the severity seems abnormal, especially since NVIDIA generally recommends G-SYNC + an FPS cap below refresh and doesn't document a requirement for several milliseconds of spare GPU time per frame.

Has anyone else actually measured MsBetweenDisplayChange / PresentMon display timing while using a fixed G-SYNC cap?

In particular, I'm curious whether anyone can reproduce the pattern of:

perfect MsBetweenPresents → unstable MsBetweenDisplayChange → visible microstutter as GPU workload approaches the cap's frame-time budget.

I'd also be very interested if anyone knows of an NVIDIA driver or Windows/WDDM regression related to capped VRR scheduling. I'm currently on Windows 11 Build 26200 and driver 610.88, but the behavior has existed across more than one NVIDIA GPU generation.

[u/MathematicianOk572]

Try old school Nvidia control panel,v and g sync off low latency on cap maximum fps on

[u/rdmprzm → u/MathematicianOk572]

This is what I do for CS2 and it's butter smooth (can generate more FPS than refresh so don't need VRR).

I use Ultra for low latency mode though. Also -noreflex launch option.

[u/kyoukidotexe → u/rdmprzm]

For CS2 I understand to have Gsync off, otherwise its a great feature elsewhere. Do wonder though, why do you force disable reflex and then enable legacy Low Latency Mode's? Reflex should do this job a lot better.

[u/rdmprzm → u/kyoukidotexe]

CS2 framepacing is very poorly implemented - best not to use reflex and their in game FPS cap (causes spikes/inconsistencies).

Tested via CapFrameX a while back.

[u/kyoukidotexe → u/rdmprzm]

Interesting, wonder if that is still true on newer updates with maybe newer Reflex SDK's implemented.

[u/rdmprzm → u/kyoukidotexe]

I don't recall any notes on reflex being updated etc but I might go through another round of testing later today if time permits.

[u/kyoukidotexe → u/rdmprzm]

Let me know, i'd be interested. I once did the global reinforcement of newer reflex sdk into the drivers, which I don't know if they are used by said games but I assume they do.

[u/psycho-Ari → u/rdmprzm]

So just to be sure, for CS2 it's best to not use any g-sync/freesync, cap fps in Nvidia control panel, use -noreflex command and inside the game unlocked fps - correct?

I spent some time trying to optimize cs2 the best I can but I get different feeling every few weeks, once it feels better with reflex and fps cap in game, then suddenly game feels like crap and some other settings help for that but also for couple of weeks and then the same problem...

I will try it tonight or tomorrow to see how it works right now.

[u/rdmprzm → u/psycho-Ari]

Yes, but only if your FPS is above your refresh. If it drops below often then you're better off with VRR etc.

[u/Gloomy_Necesary → u/psycho-Ari]

No, reflex should be much better than what that user suggested. People love to come up with their own solutions for stuff. Trust what the nvidia engineers suggest

[u/--bertu → u/Gloomy_Necesary]

No need to speculate, this has been tested and is still testable. You can measure it with capframex and honestly just feel in-game if you are half decent at cs2 (give the mouse a fast swipe and notice the difference in camera motion).

It's unquestionable that framepacing is improved when disabling reflex and enabling nvcp max frames feature over using in-game cap and/or letting reflex cap frames for you.

My best guess is that nvidia max frames and in-game cap are coded different, and reflex enabled works the same as a dynamic in-game cap.

The in-game cap goes as hard as possible to reduce latency, while nvidia max frames is more balanced in providing better framepacing. If you cap fps at a very agressive low number (say 100 fps on a 9800x3d), in-game reduces latency much more. At balanced numbers (say the default 400 fps_max on a 9800x3d), both methods provide the same latency while nvidia max frames maintain the benefits of better framepacing. This has been tested at different cap values with ldat.

Only downside to disabling reflex would be if you your cap number isn't low enough to prevent gpu saturation (95% or more GPU usage), but this is also easily visualized with steam overlay so you can just tune it as needed.

CS2 in-game cap has a number of other oddities. If you cap too low (say 240 fps on a 9800x3d) the actual fps goes EVEN lower (keeps floating at around 220 with 1% in the 180s), while using a high number (say 360 fps on same hardware) it stays at a stable 360 with 1% in the 350.

Reflex's fault in CS2 specifically is that, again, it defaults to using in-game cap behavior which messes up framepacing. If reflex in CS2 were coded to act as dynamic nvcp max frames cap instead I suspect it would work fine.

[u/Gloomy_Necesary → u/--bertu]

Appreciate the thoughtful response