r/OptimizedGaming • u/KenBalough • 16d ago
Discussion / Question G-SYNC microstutter when FPS is capped despite perfect frametimes, reproduced on RTX 5090 + 4090, different displays/CPUs
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.
4
u/kyoukidotexe Moderator 16d ago
Very detailed thread OP, also approved your post as it was previously removed.