Blur Buster's G-SYNC 101 Series Discussion

Talk about NVIDIA G-SYNC, a variable refresh rate (VRR) technology. G-SYNC eliminates stutters, tearing, and reduces input lag. List of G-SYNC Monitors.
ilzed
Posts: 2
Joined: 03 Dec 2019, 06:14

Re: Blur Buster's G-SYNC 101 Series Discussion

Post by ilzed » 03 Dec 2019, 08:25

I'm very interested in the gsync "on" vsync "off" case.

The article states that tearing can be seen within the gsync range due to frametime varianses. In the example videos the fps is capped close to the max hz so the variance might take the fps out of the gsync range and cause tearing.

If I cap fps to 150 and have a 240 hz monitor, how big would the frametime variance has to be in order to see tearing? Will I see tearing if for example the fps toggles between 150 an 200 in every frame?

User avatar
jorimt
Posts: 824
Joined: 04 Nov 2016, 10:44

Re: Blur Buster's G-SYNC 101 Series Discussion

Post by jorimt » 03 Dec 2019, 10:18

ilzed wrote:
03 Dec 2019, 08:25
If I cap fps to 150 and have a 240 hz monitor, how big would the frametime variance has to be in order to see tearing? Will I see tearing if for example the fps toggles between 150 an 200 in every frame?
To your specific question here, discounting instances of partial tearing in the very upper G-SYNC range with G-SYNC + V-SYNC "Off" (where tearing from such frametime variances can't be avoided without the V-SYNC option enabled, and not even RTSS can make frametime steady enough to prevent the partial tearing seen in that range), the variance must be very sudden and very large, like from 150 instantly to 0 and back (e.g. frametime spikes).

With any gradual or steady climb/descent of framerate, you won't experience tearing with G-SYNC + V-SYNC "Off."

That said, few games (or systems) allow for this sort of steady frametime performance 100% of the time, thus the need for G-SYNC + V-SYNC to prevent tearing in these instances at all times.
Author: Blur Busters "G-SYNC 101" Series

Display: Acer Predator XB271HU OS: Windows 10 Pro MB: ASUS ROG Maximus X Hero CPU: i7-8700k GPU: EVGA GTX 1080 Ti FTW3 RAM: 32GB G.SKILL TridentZ @3200MHz

ilzed
Posts: 2
Joined: 03 Dec 2019, 06:14

Re: Blur Buster's G-SYNC 101 Series Discussion

Post by ilzed » Yesterday, 06:41

The article states that tearing may occur inside the gsync range when gsync is "on" and vsync is "off". If frametime variance takes the fps out of the gsync range we're not anymore within the gsync range. Thus tearing does not actually happen inside the gsync range.

For example tearing is not seen in the gsync range if frametime variance is 0 and the fps stays between the upper and lower gsync limits.

As a summary my point is that tearing does not happen inside the gsync range. It does happen when when the upper or lower limit is reached for example due to frametime variance.

User avatar
jorimt
Posts: 824
Joined: 04 Nov 2016, 10:44

Re: Blur Buster's G-SYNC 101 Series Discussion

Post by jorimt » Yesterday, 10:37

ilzed wrote:
Yesterday, 06:41
For example tearing is not seen in the gsync range if frametime variance is 0 and the fps stays between the upper and lower gsync limits.
Frametime variance is never "0"; it's either within the refresh rate's scanout or it isn't. Even with 60 FPS @144Hz on a G-SYNC monitor, frametime varies constantly, it's just that a 16.6ms frametime is well within the display time of a 6.9ms (144Hz) scanout cycle, whereas a 6.8ms or lower frametime is not.
ilzed wrote:
Yesterday, 06:41
As a summary my point is that tearing does not happen inside the gsync range. It does happen when when the upper or lower limit is reached for example due to frametime variance.
You'd be right if tearing happened with G-SYNC + V-SYNC "On" as well in these instances, but it doesn't.

Again, it tears in the very "upper" range because the frametime of some individual frames exceed the refresh rate due to (unavoidable) render time variance, while the average framerate itself still actually stays within the G-SYNC range at the same time, a reason why G-SYNC + V-SYNC "On" (when paired with an appropriate FPS limit) can keep it in range in these instances, due to the frametime compensation mechanism explained several times in my article and Closing FAQ.

As for the "lower" range, which actually represents a sudden instance of 0 to x framerate (or visa-versa), since G-SYNC + V-SYNC "Off" isn't what could be called a "complete" form of G-SYNC, it will simply tear, whereas G-SYNC + V-SYNC "On" won't in the same instances.

Let's ignore the upper frametime variances for a moment and focus on the "lower" frametime variances. Again, these are due to frametime "spikes." So what happens during a spike?

In an ideal world, this is what you get with G-SYNC:

frame 1 > frame 2 > frame 3 > frame 4 > frame 5 ...

But what happens when the system and/or game engine crunches on a single frame for more than a single scanout cycle? There's nothing new to show for the next frame. So what must G-SYNC do? It must repeat the previous frame for however many cycles it takes for the next frame to be ready:

frame 1 > frame 2 > frame 2 > frame 3 > frame 4 > frame 5 ...

The difference between G-SYNC + V-SYNC "Off" and G-SYNC + V-SYNC "On" is what happens in these instances once the new frame is finally ready to be delivered:

frame 1 > frame 2 > frame 2 > (here) frame 3 > frame 4 > frame 5 ...

With G-SYNC + V-SYNC "Off" when transitioning from the previous (repeating) frame to the new frame, it will immediately start scanning in the new frame over the previous frame somewhere around the middle of the screen. In fact, all "tearing" means is that parts of more than one frame are visible in a single scanout cycle at a time.

With G-SYNC + V-SYNC "On," instead of doing this, it will wait for that previous (repeating) frame to fully complete in the current scanout cycle, and align the new frame to the top/beginning of the very next scanout cycle, thus preventing tearing in the same instance.

So your literal input lag "reduction" with G-SYNC + V-SYNC "Off" over "On" is up to a half frame per spike due to the literal, visible tear.

This is similar to what happens in the upper range, but instead of a frame being ready too late, the frame is ready too early, and your literal input lag "reduction" with G-SYNC + V-SYNC "Off" over "On" in this specific (and very limited) range is a tiny fraction of a frame per instance due to the literal, visible tear.

When neither of these instances are occuring, there is no behavioral difference between G-SYNC + V-SYNC "Off" / "On."

Since the very purpose of G-SYNC is 100% tear-free frame delivery, G-SYNC + V-SYNC "On" is the obvious (and original) choice for this purpose. Whether the oft minuscule input lag "reduction" of G-SYNC + V-SYNC "Off" due to the tearing it introduces in these instances is "worth it," is up to the individual user to decide, which is why the (apparent endlessly confusing and needlessly worrying) option was made available in the first place.
Author: Blur Busters "G-SYNC 101" Series

Display: Acer Predator XB271HU OS: Windows 10 Pro MB: ASUS ROG Maximus X Hero CPU: i7-8700k GPU: EVGA GTX 1080 Ti FTW3 RAM: 32GB G.SKILL TridentZ @3200MHz

jorma
Posts: 1
Joined: Today, 02:52

Re: Blur Buster's G-SYNC 101 Series Discussion

Post by jorma » Today, 05:14

Hi, I've been following this recent discussion and I think I share the same confusion as ilzed.

jorimt: First I want to say that I totally agree with G-sync 101 guide and I thank you for it. I also understand why V-SYNC should be "On" while using G-SYNC as you very thoroughly explain in your guide and in the previous message.

Now this confusion is very technical and kind of unnecessary, but I just want to understand what V-SYNC actually does here. What I understand ilzed has been saying - isn't that one individual frame, which causes tearing without V-SYNC, technically out of the G-SYNC range? And in the case of that individual frame technically V-SYNC acts as it traditionally does and prevents tearing from happening.

Theoretically, if we would have a perfect FPS-limiter -program that would keep framerate inside the G-SYNC range in the upper limit, and a system that never freezes, so that framerate is always withing the G-SYNC range in the lower limit, then V-SYNC would be unnecessary? Theoretically.

Or does V-SYNC also something else when paired with G-SYNC what I don't understand? Here's a couple of comments from jorimt that led to my confusion:
"With G-SYNC enabled, "V-SYNC" is not "V-SYNC." It is instead (as far as can be figured) effectively a flag at the driver level that permits G-SYNC to allow itself to compensate for sudden frametime variances." (neogaf.com forums)
"V-SYNC does do something in the G-SYNC range, which is primarily adhering to the VBLANK at all times (something that G-SYNC + V-SYNC “Off” does not do)." (G-SYNC 101 comment section)"
Again, wouldn't that individual frametime be actually out of G-SYNC range but what V-SYNC then prevents from happening?

User avatar
jorimt
Posts: 824
Joined: 04 Nov 2016, 10:44

Re: Blur Buster's G-SYNC 101 Series Discussion

Post by jorimt » Today, 11:55

jorma wrote:
Today, 05:14
Now this confusion is very technical and kind of unnecessary, but I just want to understand what V-SYNC actually does here.
It's not traditional, standalone "V-SYNC" during "upper" (early frame) and "lower" (late frame) frametime variations in these specific instances, but a direct function of G-SYNC that V-SYNC "Off" disables. I'm not sure how many more times or ways I can say this.

I guess I should ask, do you know the actual, technical difference between G-SYNC and V-SYNC, and why traditional V-SYNC causes input lag? Because the way you're both presenting your questions tells me you might not. This is important if you fully want to understand the difference between G-SYNC with the V-SYNC option enabled, and standalone V-SYNC.

Suffice to say, using an FPS limiter prevents the traditional form of V-SYNC input lag both with G-SYNC + V-SYNC and standalone V-SYNC. So what we're talking about here is when we're already preventing V-SYNC input lag, and what the V-SYNC option does with G-SYNC once that's off the table.
jorma wrote:
Today, 05:14
What I understand ilzed has been saying - isn't that one individual frame, which causes tearing without V-SYNC, technically out of the G-SYNC range? And in the case of that individual frame technically V-SYNC acts as it traditionally does and prevents tearing from happening.
No, it's actually out of the monitor's physical "range" to otherwise display tear-free, which is why I call the V-SYNC option with G-SYNC frametime "compensation."

"Render" time (aka frametime) of a frame is entirely separate of display time. A frame can be rendered, fully completed, and ready to deliver to the display, and theoretically sit in the buffer forever.

In other words, the frame first has to render, which takes x amount of (frame)time, and then the display has to scan it in, which takes a separate x amount of time; a reason why most forms of sync run on a double buffer, including G-SYNC; one buffer has a frame rendering while the other buffer has an already rendered frame scanning into the display simultaneously. Once the rendered frame has completely scanned into the display in buffer A, buffer B's frame is now fully rendered and ready to start scanning in, at which point the two buffers swap positions, repeat.

With the V-SYNC option enabled, G-SYNC will sync any frame, be it too late or too early, to the display's scanout time, as to completely avoid tearing.

With the V-SYNC option disabled, G-SYNC will only sync frames that are within the display's scanout time, and let any frame that is ready too late or too early, tear.

To put it another way, both G-SYNC and any form of standalone V-SYNC use the VBLANK (the span between the previous and next frame scan) to determine the starting point of each scanout cycle, and time delivery of the frame to the beginning/top of that scanout cycle, all the way to the end/bottom of that scanout cycle as to prevent tearing, repeat.

The V-SYNC option controls in what conditions G-SYNC will adhere to the VBLANK.
jorma wrote:
Today, 05:14
Theoretically, if we would have a perfect FPS-limiter -program that would keep framerate inside the G-SYNC range in the upper limit, and a system that never freezes, so that framerate is always withing the G-SYNC range in the lower limit, then V-SYNC would be unnecessary? Theoretically.
Correct, but in that case, G-SYNC would be unnecessary, in fact, all forms of sync would be, because no frametime fluctuation means no framerate fluctuation, which effectively means an unlimited framerate that can be perfectly capped to any desired limit, and thus you could steer the tearline anywhere you'd like and keep it there permanently.

What you're suggesting is very similar to RTSS Scanline Sync, yet that runs into the same limitations in the real world, as frametime and system performance varies at any given time, and if it drops below your limit, you'd need something like G-SYNC again to avoid tearing.
jorma wrote:
Today, 05:14
Or does V-SYNC also something else when paired with G-SYNC what I don't understand? Here's a couple of comments from jorimt that led to my confusion:
"With G-SYNC enabled, "V-SYNC" is not "V-SYNC." It is instead (as far as can be figured) effectively a flag at the driver level that permits G-SYNC to allow itself to compensate for sudden frametime variances." (neogaf.com forums)
"V-SYNC does do something in the G-SYNC range, which is primarily adhering to the VBLANK at all times (something that G-SYNC + V-SYNC “Off” does not do)." (G-SYNC 101 comment section)"
Again, wouldn't that individual frametime be actually out of G-SYNC range but what V-SYNC then prevents from happening?
Again, when you disable the V-SYNC option with G-SYNC, you're actually removing part of G-SYNC's core functionality. G-SYNC + V-SYNC "Off" is a still functional, but not "complete" form of G-SYNC.
Author: Blur Busters "G-SYNC 101" Series

Display: Acer Predator XB271HU OS: Windows 10 Pro MB: ASUS ROG Maximus X Hero CPU: i7-8700k GPU: EVGA GTX 1080 Ti FTW3 RAM: 32GB G.SKILL TridentZ @3200MHz

Post Reply