G-SYNC 101: In-game vs. External FPS Limiters


Closer to the Source*

*As of Nvidia driver version 441.87, Nvidia has made an official framerate limiting method available in the NVCP; labeled “Max Frame Rate,” it is a CPU-level FPS limiter, and as such, is comparable to the RTSS framerate limiter in both frametime performance and added delay. The Nvidia framerate limiting solutions tested below are legacy, and their results do not apply to the “Max Frame Rate” limiter.

Up until this point, an in-game framerate limiter has been used exclusively to test FPS-limited scenarios. However, in-game framerate limiters aren’t available in every game, and while they aren’t required for games where the framerate can’t meet or exceed the maximum refresh rate, if the system can sustain the framerate above the refresh rate, and a said option isn’t present, an external framerate limiter must be used to prevent V-SYNC-level input lag instead.

In-game framerate limiters, being at the game’s engine-level, are almost always free of additional latency, as they can regulate frames at the source. External framerate limiters, on the other hand, must intercept frames further down the rendering chain, which can result in delayed frame delivery and additional input latency; how much depends on the limiter and its implementation.

RTSS is a CPU-level FPS limiter, which is the closest an external method can get to the engine-level of an in-game limiter. In my initial input lag tests on my original thread, RTSS appeared to introduce no additional delay when used with G-SYNC. However, it was later discovered disabling CS:GO’s “Multicore Rendering” setting, which runs the game on a single CPU-core, caused the discrepancy, and once enabled, RTSS introduced the expected 1 frame of delay.

Seeing as the CS:GO still uses DX9, and is a native single-core performer, I opted to test the more modern “Overwatch” this time around, which uses DX11, and features native multi-threaded/multi-core support. Will RTSS behave the same way in a native multi-core game?

Blur Buster's G-SYNC 101: Input Latency & Optimal Settings
Blur Buster's G-SYNC 101: Input Latency & Optimal Settings
Blur Buster's G-SYNC 101: Input Latency & Optimal Settings

Yes, RTSS still introduces up to 1 frame of delay, regardless of the syncing method, or lack thereof, used. To prove that a -2 FPS limit was enough to avoid the G-SYNC ceiling, a -10 FPS limit was tested with no improvement. The V-SYNC scenario also shows RTSS delay stacks with other types of delay, retaining the FPS-limited V-SYNC’s 1/2 to 1 frame of accumulative delay.

Next up is Nvidia’s FPS limiter, which can be accessed via the third-party “Nvidia Inspector.” Unlike RTSS, it is a driver-level limiter, one further step removed from engine-level. My original tests showed the Nvidia limiter introduced 2 frames of delay across V-SYNC OFF, V-SYNC, and G-SYNC scenarios.

Blur Buster's G-SYNC 101: Input Latency & Optimal Settings
Blur Buster's G-SYNC 101: Input Latency & Optimal Settings
Blur Buster's G-SYNC 101: Input Latency & Optimal Settings

Yet again, the results for V-SYNC and V-SYNC OFF (“Use the 3D application setting” + in-game V-SYNC disabled) show standard, out-of-the-box usage of both Nvidia’s v1 and v2 FPS limiter introduce the expected 2 frames of delay. The limiter’s impact on G-SYNC appears to be particularly unforgiving, with a 2 to 3 1/2 frame delay due to an increase in maximums at -2 FPS compared to -10 FPS, meaning -2 FPS with this limiter may not be enough to keep it below the G-SYNC ceiling at all times, and it might be worsened by the Nvidia limiter’s own frame pacing behavior’s effect on G-SYNC functionality.

Needless to say, even if an in-game framerate limiter isn’t available, RTSS only introduces up to 1 frame of delay, which is still preferable to the 2+ frame delay added by Nvidia’s limiter with G-SYNC enabled, and a far superior alternative to the 2-6 frame delay added by uncapped G-SYNC.



3525 Comments For “G-SYNC 101”

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Sort by:   newest | oldest | most liked
BloodyNZ
Member
BloodyNZ

Hey jorimt, thanks for this amazing article and all the research put into it.
My question is if everything present here still applies nowadays with all the new technology and it’s evolution, or anything changed.
I’m rocking a 5060ti but still on a 1080p 144hz display, so I’m trying to optimize it. I play a different range of games, from competitive to single-player. I just want a stable and consistent experience everywhere.

Treeplex
Member
Treeplex

Hello Dear jorimt! I am interested in one question, I will be grateful for the answer. In the game Fall Guys without vertical synchronization limit FPS 300, but with synchronization enabled FPS is equal to 360, what to do in this case?

KasaiRyujin
Member
KasaiRyujin

Hello jorimt, thanks for all the info.

I read almost all the pages of this post, but I’m still not sure what to set in my case.

I have a RTX 4090 + R7 7800X3D. I play on 1440p ~180Hz, so most games run at refresh rate. But I see that the frametime is unstable in some games.

I enabled G-SYNC and set V-Sync to “On”. Also set max framerate to 175 on NVIDIA App.

What should I do with Reflex and Low Latency Mode when I’m hitting refresh rate constantly?
I realized V-Sync has an option called “Fast”, should I use it?

Thanks in advance.

mike-lesnik
Member

Hello jorimt!
For what purpose did Nvidia choose such a significant frame limit for Reflex and LLM Ultra (for example 224 for 240Hz), if you prove that 2-3 frames are enough?

rundown
Member
rundown

Great series, thank you!

Sorry for yet another question about v-sync! 🙂 I do believe that screen tearing occurs with VRR on and v-sync off, but I’m trying to understand on a technical level how it happens with an FPS cap under the max refresh rate? Suppose a 144hz refresh and 140 fps cap.

My understanding is, the display waits in vertical blank until the new frame arrives and immediately scans it out in 1/144 seconds. If the frame limiter is doing its job, a new one shouldn’t arrive until 1/140 seconds after the first one, so the display should be in vblank again.

What am I missing — imperfections in the frame limiter?

wpDiscuz