Enabling G-sync has hidden impacts even when frame rate is uncapped?

[Arx]

Not sure I am crazy or G-sync is crazy.
Recently I observed a weird behavior on using G-sync.

In the past month, I played a lot of Aimlab. I played it with G-sync off for a long time. One day, I turned on G-sync in the Nvidia control panel, and immediately my performance in Aimlab increased! I thought that must be an accident of performance variance.
(Because even though G-sync is enabled in the Nvidia control panel, my Aimlab runs at 900 fps uncap, which will automatically suspend the G-sync feature.)

But after switching between G-sync on and off, I kept getting the same feeling that enabling G-sync boosts my performance in Aimlab, even though I am 100% sure the G-sync is not affecting the refresh rate of my monitor.
(My monitor can display the current refresh rate, and if VRR is active, the displayed value will change dynamically. It shows 240Hz constantly, so the G-sync is not affecting refresh rate)

Finally, I started a serious experiment, and collected my score data after each round. To make an apple to apple comparison between G-sync on and off, I carefully performed this experiment.
(For example, having 5 rounds per each setting alternatively to avoid bias from variance of my body fatigue. And enabling G-sync will reduce the aggressiveness of the overdrive setting on my monitor, I also took care of this and equalized the effect of overdrive.)
After enough data collected, I can conclude that:
Enalbing G-sync, in Aimlab, with 900 fps, with my monitor AW2720HF, did boost my average score in motionshot ultimate mode, increased for 5%. And the occurrence of my peak scores, which is the "chance" of getting scores higher than 120k, increased for ~125%.

(Background information: I am currently at the rank 1st of motionshot, you can think of me playing Aimlab competitively, and my score is quite consistent.)
-------------------------------------------------------------------------

Just enabling G-sync in the NV control panel would bring advantage in a frame rate uncapped game, looks crazy to me.
This result reminds me of one of Chris's input lag analysis, which disables G-sync on a G-sync compatible monitor introducing increased input lag.
https://www.youtube.com/watch?v=L42nx6ubpfg&t=835s

I assume such advantage is brought by reduced input lag, but I don't have a high speed camera to measure it myself. Also I am not sure whether this is game related, or monitor related.
I also send this to the Chris (channel owner of Battlenonsense) requesting a new video regarding this, but I haven't seen him doing input lag analysis for a long time.

Meanwhile, I am still thinking something is crazy here, and I will continue doing my experiment and collecting more data in Aimlab.

[senny22]

For what it's worth, I've tested the input lag difference in CS:GO with freesync enabled / disabled at the same frame rates (235 and 300) and there wasn't any difference on my XF252QX.

[deama]

A friend of mine disabled his gsync on his predator z35p and got about 20ms less input lag (measured using a 240fps camera), games felt smoother to him too.

[jorimt]

Enalbing G-sync, in Aimlab, with 900 fps, with my monitor AW2720HF, did boost my average score in motionshot ultimate mode

Your display is a G-SYNC Compatible FreeSync model. VRR typically needs an instantaneous scanout transmission to function properly, so it's possible enabling G-SYNC Compatible (which also enables FreeSync mode on the display) on your particular model causes a decrease in actual monitor processing lag compared to off.

This probably wouldn't apply to all G-SYNC Compatible monitors, some of which may be in the lower lag mode with G-SYNC Compatible/FreeSync enabled or disabled, and could depend on the given panel scaler, etc.

This also shouldn't apply to native G-SYNC monitors at all, since everything runs through the G-SYNC module whether G-SYNC is enabled or disabled (another reason native G-SYNC displays tend to have lower processing lag).

A friend of mine disabled his gsync on his predator z35p and got about 20ms less input lag (measured using a 240fps camera), games felt smoother to him too.

As I replied to you in the other thread, your statement is too general. What was the G-SYNC "off" scenario, and what was the G-SYNC "on" scenario?

Also, for reference, 240 FPS slow-mo capture is fine for casual testing, but it's highly limited, and will only give you a vague idea on whether you're getting another frame or so of input lag; it won't give you an exacting enough measurement to rely on in most instances, as its error margin is simply too large.

I know, because I initially did many 240 FPS tests with a phone camera in some of my first threads on this forum years ago before switching to a 1000 FPS camera for further forum tests and ultimately the G-SYNC 101 article, and the 240 FPS tests in like-for-like scenarios showed far less reliable and accurate results.

[deama]

Enalbing G-sync, in Aimlab, with 900 fps, with my monitor AW2720HF, did boost my average score in motionshot ultimate mode

Your display is a G-SYNC Compatible FreeSync model. VRR typically needs an instantaneous scanout transmission to function properly, so it's possible enabling G-SYNC Compatible (which also enables FreeSync mode on the display) on your particular model causes a decrease in actual monitor processing lag compared to off.

This probably wouldn't apply to all G-SYNC Compatible monitors, some of which may be in the lower lag mode with G-SYNC Compatible/FreeSync enabled or disabled, and could depend on the given panel scaler, etc.

This also shouldn't apply to native G-SYNC monitors at all, since everything runs through the G-SYNC module whether G-SYNC is enabled or disabled (another reason native G-SYNC displays tend to have lower processing lag).

A friend of mine disabled his gsync on his predator z35p and got about 20ms less input lag (measured using a 240fps camera), games felt smoother to him too.

As I replied to you in the other thread, your statement is too general. What was the G-SYNC "off" scenario, and what was the G-SYNC "on" scenario?

Also, for reference, 240 FPS slow-mo capture is fine for casual testing, but it's highly limited, and will only give you a vague idea on whether you're getting another frame or so of input lag; it won't give you an exacting enough measurement to rely on in most instances, as its error margin is simply too large.

I know, because I initially did many 240 FPS tests with a phone camera in some of my first threads on this forum years ago before switching to a 1000 FPS camera for further forum tests and ultimately the G-SYNC 101 article, and the 240 FPS tests in like-for-like scenarios showed far less reliable and accurate results.

We played with different settings in the control panel, disabling gsync, enabling it, vsync options, going through the guide here on blur busters, it was all worse than having gsync off.

I know that there's a decent amount of margin of error, but 20ms (that's like 5 frames) is a decent mount and I wouldn't say it's a margin of error, if it was 4ms, or maybe even 8ms, then sure, but 20ms is a pretty large difference.

Maybe his gsync implementation was just bad? I have no clue, he bought his monitor I believe in 2017 and it was the acer predator z35p.
He did say that disabling gsync and then configuring scanline sync on RTSS made it look noticeably smoother than when his computer had gsync on.

[jorimt]

We played with different settings in the control panel, disabling gsync, enabling it, vsync options, going through the guide here on blur busters, it was all worse than having gsync off.

I know that there's a decent amount of margin of error, but 20ms (that's like 5 frames) is a decent mount and I wouldn't say it's a margin of error, if it was 4ms, or maybe even 8ms, then sure, but 20ms is a pretty large difference.

Maybe his gsync implementation was just bad? I have no clue, he bought his monitor I believe in 2017 and it was the acer predator z35p.
He did say that disabling gsync and then configuring scanline sync on RTSS made it look noticeably smoother than when his computer had gsync on.

It was either user error or faulty G-SYNC on his particular display then, because when properly configured, that amount of input lag with G-SYNC vs. G-SYNC off isn't possible.

A 4-5 frames increase of input lag can only be achieved with G-SYNC + V-SYNC + uncapped fps sustained above the refresh rate, which isn't a proper configuration, as G-SYNC isn't even engaged in that scenario (I'm attaching my 120Hz results because the model you listed has an overclock of 120Hz, but I'm obviously not sure if was running at its base 100Hz during the testing):
https://blurbusters.com/gsync/gsync101- ... ettings/5/



Optimal G-SYNC configuration can be found here for repeat reference:
https://blurbusters.com/gsync/gsync101- ... ttings/14/

As for Scanline Sync, it's a great non-VRR solution, but it's basically a poor man's fixed refresh version of G-SYNC + V-SYNC + -3 FPS limit, which effectively does the same thing as Scanline Sync (keeps tearline off-screen by adhering to the VBLANK within its range), but G-SYNC does it automatically, and at any framerate within the refresh rate.

[Arx]

Enalbing G-sync, in Aimlab, with 900 fps, with my monitor AW2720HF, did boost my average score in motionshot ultimate mode

Your display is a G-SYNC Compatible FreeSync model. VRR typically needs an instantaneous scanout transmission to function properly, so it's possible enabling G-SYNC Compatible (which also enables FreeSync mode on the display) on your particular model causes a decrease in actual monitor processing lag compared to off.

This probably wouldn't apply to all G-SYNC Compatible monitors, some of which may be in the lower lag mode with G-SYNC Compatible/FreeSync enabled or disabled, and could depend on the given panel scaler, etc.

This also shouldn't apply to native G-SYNC monitors at all, since everything runs through the G-SYNC module whether G-SYNC is enabled or disabled (another reason native G-SYNC displays tend to have lower processing lag).

A friend of mine disabled his gsync on his predator z35p and got about 20ms less input lag (measured using a 240fps camera), games felt smoother to him too.

As I replied to you in the other thread, your statement is too general. What was the G-SYNC "off" scenario, and what was the G-SYNC "on" scenario?

Also, for reference, 240 FPS slow-mo capture is fine for casual testing, but it's highly limited, and will only give you a vague idea on whether you're getting another frame or so of input lag; it won't give you an exacting enough measurement to rely on in most instances, as its error margin is simply too large.

I know, because I initially did many 240 FPS tests with a phone camera in some of my first threads on this forum years ago before switching to a 1000 FPS camera for further forum tests and ultimately the G-SYNC 101 article, and the 240 FPS tests in like-for-like scenarios showed far less reliable and accurate results.

I am thinking this input lag might be introduced in software layer, which is likely the "Nvidia video driver combining with certain implementation of games", and happens before video signal sent to the monitor. (instead of signal processing inside the monitor)

Reason 1:
According to Rtings' review on the same monitor, native resolution has 2.8 ms video signal to photon delay, and VRR has 3.0 ms. (Almost the same) https://www.rtings.com/monitor/reviews/ ... e-aw2720hf

Reason 2:
From Chris's video, he measured extra input lag when G-sync compatible is disabled with his Asus VG258
https://www.youtube.com/watch?v=L42nx6ubpfg&t=837s
I then searched his model, and the reviews did not show extra video signal to photon delay in fixed refresh rate mode for his monitor.
Also when Chris tested it with AMD card and free-sync, the extra input lag did not present.

But I could be wrong on my AW2720HF case, and the whole performance boost conclusion might be an extreme variance accident from the data I collected.
For Chris's case, I don't know if he can still reproduce such behavior, or it was a bug and has been fixed.
(btw, I am using windows 10 v1909 with nvidia video driver 451.48, which is an almost latest version for the video driver.)

[jorimt]

I am thinking this input lag might be introduced in software layer, which is likely the "Nvidia video driver combining with certain implementation of games", and happens before video signal sent to the monitor. (instead of signal processing inside the monitor)

Also plausible, as the driver is responsible for the majority of the behavior for software-side VRR.

My suggestion was just one of many potential causes, if there is a measurable difference to what you're witnessing. Hard to say.

According to Rtings' review on the same monitor, native resolution has 2.8 ms video signal to photon delay, and VRR has 3.0 ms. (Almost the same) https://www.rtings.com/monitor/reviews/ ... e-aw2720hf

Yeah, that's error margin, so no measurable difference.

That said, they didn't note if those input lag test numbers covered both FreeSync mode w/AMD GPU and G-SYNC mode w/Nvidia GPU, or only one or the other, so that doesn't rule out any possible differences in driver implementation between the two on that same display.

From Chris's video, he measured extra input lag when G-sync compatible is disabled with his Asus VG258
https://www.youtube.com/watch?v=L42nx6ubpfg&t=837s
I then searched his model, and the reviews did not show extra video signal to photon delay in fixed refresh rate mode for his monitor.
Also when Chris tested it with AMD card and free-sync, the extra input lag did not present.

Yeah, I remember when that video was first released. I didn't know the cause then, and I don't now. May indeed be driver related, which would mean the behavior could vary depending on the given version.

But I could be wrong on my AW2720HF case, and the whole performance boost conclusion might be an extreme variance accident from the data I collected.

I don't like to pull out the "placebo" argument, and I won't now, but what I will say is that it's up in the air without extensive high-speed tests or the like, unfortunately.

[pellson]

I have been saying this for almost a year now to deaf ears. All responses I get is "Well, you need to turn off vsync, or cap your FPS -3 under max" bla bla bla. I know all these things already and it's not even what I'm taking about. Uncapped with vsync off and VRR off in the OSD feels a little snappier that VVR on in the osd and still uncapped (should be disaganed in theory, but isn't)

Just by disabling VRR on my VG27AQ in the OSD give me a very small decrease in input lag. It's barely noticeable, but enough do drive someone with OCD for these things insane in CS:Go competitively.

Any comments to this?

[Chief Blur Buster]

Chief Blur Buster Summary:
(Written for critical "milliseconds matter" audience)

1. VSYNC OFF can still have some tiny latency advantage when it comes to high-end esports
VSYNC OFF is still king for ultra high framerate games like CS:GO

2. VRR (G-SYNC) is the world's lowest lag "non-vsync-off" sync technology, as long as panel correctly implements it without other penalty.
If you hate tearing/microstutters, it's hard to beat VRR

3. If you use VRR / G-SYNC in esports, you should use absolute minimum 240Hz+ G-SYNC. Don't play esports with <240Hz G-SYNC even if framerate is only 100fps. VRR has a bit of scanout-related latency which goes down at higher "max Hz" even for low framerates.
100fps@240Hz VRR is lower lag than 100fps@144Hz VRR.
100fps@360Hz VRR is lower lag than 100fps@240Hz VRR

4. For competitive lag-priority G-SYNC performs best with your games whose framerates are within VRR range without needing frame rate capping. For example, if your game is a 100-200fps framerate range, then use a 240Hz VRR panel. If your game is 100fps-300fps framerate range, than use a 360Hz VRR panel (or at least 280Hz).
For esports VRR, make sure your VRR max Hz is well above your game's max framerate

5. For competitive lag-priority purposes, VSYNC OFF perform best with games whose framerates are almost always perpetually above refresh rate.
If you consistently get framerate well beyond Hz, it may be best to use VSYNC OFF for that game

6. There can be panel-specific VRR quirks (specific bad overdrive, specific worse-than-it-should-be lag, etc).
Avoid panels that have more than half a refresh cycle average latency increase for VRR

7. Capping is simply a trade for lesser-evil lag. You're trading (worse) VSYNC ON latency with (lesser) increased-frametime latency from lower framerate. But if your framerate range is completely within VRR range *AND* the scanout latency is ultralow, lagfeel of VRR feels much better.
Know why capping is necessary; right tool for right job

8. Lagfeel consistency during framerate=Hz crossing events (e.g. framerates gyrating above and below Hz) is more consistent with VSYNC OFF than with VRR. Therefore if you want to use VRR in esports, make sure uncapped framerate range is completely within VRR range, *and* a very high max-Hz, if you want esports-quality VRR.
For games whose uncapped framerates frequently crosses above/below Hz, lagfeel changes is an issue with VRR; use a cap to avoid this. The changing latency yo-yo effect of framerate=Hz crossing events is more noticeable than consistent added latency.

9. Some games benefit more from VSYNC OFF (e.g. CS:GO) while some other games may be helped with VRR (e.g. PUBG).
Try VRR to stabilize latency of games that have a very erratic latency yo-yo effect. Higher-but-stable lag can sometimes help aiming in specific games that have erratic stutters + erratic latency yo-yo effects even during VSYNC OFF. Right sync technology for the right game! Ideally, for competitive VRR, make sure your refresh rate is above max framerate.

10. Different games/software have different VRR behaviours that can add/remove lagfeel problems. Even overdrive differences can change latency, and different panels have different VRR overdrive which can be different speeds for different pixel colors. In an ideal world, for perfectly framepaced games, with no overdrive GtG differences, with properly implemented panels, the average added latency for VRR (if all pixels are measured on the ENTIRE screen surface and averaged) is half a max-Hz refreshtime lag for VRR, regardless of frame rate. In practice, this can be better/worse in different software.
VRR feels better in some games than others, and feels better on some panels than others.

I've been saying this for years (in bits and pieces), for those "milliseconds-critical" situations.
I simply summarize this compactly, to reduce misunderstandings.

Jorim is correct in quite a large number of things. That said, understanding context is supremely important -- it is easy to misunderstand latency when different pixels on the screen have different latences. Alas, the latency universe is much bigger than this thread. This thread metaphorically talks about only one solar system's worth of latency topics, when there's an entire Milky Way Galaxy of latency complexity.

Crossposting:

Your only "reactive" advantage over G-SYNC with G-SYNC off in that range is the visible tearing; when it tears, there's your one and only "advantage." Otherwise, there's no difference between the two performance/input lag-wise during normal operation.

I have the Vg27aq and it 100% has an extremely small increase in input lag just by enabling the VRR in the OSD. No, I don't want to hear "that's because you have to cap fps beneath max bla bla" I know all this stuff already how vsync works.

So depending on interpretation/language barrier, both YOU *and* Jorim is right.

Terminologically, language-barrier-wise, there isn't much difference between the two. It is in a matter of interpretation, given the English language (and its strange nuances), and there can be confusion that arises when the writer is non-English.

I think there's a misunderstanding. "When it tears, there's your one and only advantage" -- is the lower latency that jorim is agreeing with you on, as a tradeoff of the tearing.

There is a slight sync-technology-related average absolute latency penalty for VRR versus VSYNC OFF corresponding to one scanout halftime (e.g. 0.5/155sec latency penalty), given randomized tearline placement along the scanout.

The whole screen is a veritcal latency gradient that is typically [0....1/maxHz] on most gaming monitors, at least the ones that has realtime synchronization between cable scanout and panel scanout.

For esports-friendly VRR, I highly recommend higher Hz such as 240Hz or 360Hz, since the scanout halftime (0.5/360) begins to create an almost-negligible VRR-induced scanout latency penalty.

That said, VRR is the world's lowest "non-vsync-OFF" sync technology, generally lower lag than everything else other than VSYNC OFF.

Not all pixels on a display panel refresh at the same time. Both VSYNC OFF and VRR are same latency for scanline number #001 (top edge for VRR, and first scanline of a frameslice for VSYNC OFF). During VSYNC OFF, each frameslice is a latency gradient of [0...frametime] milliseconds, while for any other sync technology, the whole screen surface is a [0...1/maxHz] latency gradient. So the beginning of the latency gradient is identical (+0 adder), but the beginning of the latency gradient (+0) can be closer to the center of the screen, thanks to a tearline occuring right above crosshairs, for example. That's the advantage that tearing gives you.

However, given over 180 countries read Blur Busters and many people's languages aren't the same, and not everyone realizes that latency is not a single number -- it's true we sometimes need to give a bit more detailed answers nowadays. Given devices such as LDAT and other testers often don't account for the latency gradient effect, as single-pixel photodiode tests aren't good at measuring latency gradients of a random VSYNC OFF frameslice, but it is very visible in things like high speed videos (of Slo Mo Guys fame) or when putting multiple photodiodes simultaneously all over the screen.

First, screens refresh from top-to-bottom, as seen in high speed videos, which creates interesting behaviours for GSYNC versus VSYNC OFF.

Example of VSYNC OFF sub-divided latency gradients



Scanout: GSYNC 100fps at 144Hz



Scanout: VSYNC OFF 100fps at 144Hz



As you can see, the latency gradients are different [0...1/maxHz] versus [0...frametime] for VRR versus VSYNC-OFF. So minimum latency adder (+0) is identical for both (Jorim is correct), but maximum is different (pellson is correct).

Remember: Not All Pixels Refresh At The Same Time!!
Remember: Not All Pixels Are The Same Latency!!

Sorry for bad English, and also writing on mobile.

Many forum members here are not English-language-first.

I'm kind of a stickler about terminology around here to minimize disagreements, given the international nature of our audience, since latency is not a single number, nor for each pixel on the entire screen surface.

VSYNC OFF is more responsive for esports use because of its reliance on lower average latency (midpoint MIN...MAX) at the cost of motion fluidity / tearing. For average absolute latency, VSYNC OFF is hard to beat (especially great in games such as CS:GO), while G-SYNC (at extreme refresh rates) can still help give advantage in different games that are stutter-prone enough to interfere with aiming.