G-SYNC 101: G-SYNC Ceiling vs. FPS Limit


How Low Should You Go?

Blur Busters was the world’s first site to test G-SYNC in Preview of NVIDIA G-SYNC, Part #1 (Fluidity) using an ASUS VG248QE pre-installed with a G-SYNC upgrade kit. At the time, the consensus was limiting the fps from 135 to 138 at 144Hz was enough to avoid V-SYNC-level input lag.

However, much has changed since the first G-SYNC upgrade kit was released; the Minimum Refresh Range wasn’t in place, the V-SYNC toggle had yet to be exposed, G-SYNC did not support borderless or windowed mode, and there was even a small performance penalty on the Kepler architecture at the time (Maxwell and later corrected this).

My own testing in my Blur Busters Forum thread found that just 2 FPS below the refresh rate was enough to avoid the G-SYNC ceiling. However, now armed with improved testing methods and equipment, is this still the case, and does the required FPS limit change depending on the refresh rate?

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
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

As the results show, just 2 FPS below the refresh rate is indeed still enough to avoid the G-SYNC ceiling and prevent V-SYNC-level input lag, and this number does not change, regardless of the maximum refresh rate in use.

To leave no stone unturned, an “at” FPS, -1 FPS, -2 FPS, and finally -10 FPS limit was tested to prove that even far below -2 FPS, no real improvements can be had. In fact, limiting the FPS lower than needed can actually slightly increase input lag, especially at lower refresh rates, since frametimes quickly become higher, and thus frame delivery becomes slower due to the decrease in sustained framerates.

As for the “perfect” number, going by the results, and taking into consideration variances in accuracy from FPS limiter to FPS limiter, along with differences in performance from system to system, a -3 FPS limit is the safest bet, and is my new recommendation. A lower FPS limit, at least for the purpose of avoiding the G-SYNC ceiling, will simply rob frames.



3752 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
Noidy
Member
Noidy

Hello!

Im getting lost in the sauce… I Have an AMD gpu with a freesync premium pro display (msi maq 1440p oled 240hz). I play mainly overwatch but I like to play with a tear free screen. So with -3 fps limit, Freesync + v-sync i only add 1 ms of delay compared to freesync/vsync off and fps unlimited?

wttrbb
Member
wttrbb

Hey man thanks for the detailed guide! I’m sorry if this is been mentioned anywhere I just couldn’t find it. What would your recommended settings for frame generation in games be? Is there anything to keep in mind when using that?
Kind regards

schustez
Member
schustez

does using reflex on + boost or ultra low latency always cap your fps below the max refresh rate of your monitor when you can sustain a higher fps or only when you are gpu bound?

higorhigorhigor
Member
higorhigorhigor

In my tests with the AMD RX 6750 XT, an LG 180hz IPS monitor, on both Linux and Windows 11, I noticed that when I cap the FPS at 60, for example, in scenarios that could deliver 160 uncapped, what happens is that my GPU significantly reduces its clock speeds, and this creates instability in frame production, causing the refresh rate to fluctuate widely.

On Linux, in LACT (a program for managing GPUs on Linux), I created a profile for the specific game and activated a performance level option that keeps the clock speeds higher. This completely solved the problem that occurs when I limit the FPS far below what my GPU can produce.

On Windows, I haven’t found a similar option to this, but I also haven’t looked much since I’m not using Windows a lot. I came here to comment, so that in case you weren’t aware of this, it might help other users who feel they have this VRR disengagement issue even when the FPS seems stable in RTSS.

COLEDED
Member
COLEDED

Thanks for the detailed guide. Sorry if this is a mostly unrelated question, I ask because the power plan is mentioned in the conclusion section.

My default Window’s “High performance” plan puts my minimum processor state at 0% for some reason.

Is it a good idea to just use Bitsum’s highest performance plan from park control, which sets the Minimum processor state at 100%, all of the time? I haven’t seen an increase in idle CPU power consumption or utilization after changing to this profile

Does this setting actually changes anything?

wpDiscuz