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.
hmukos
Posts: 30
Joined: 16 Apr 2020, 15:41

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

Post by hmukos » 10 Jul 2020, 15:11

jorimt wrote:
10 Jul 2020, 14:59
1) Your monitor model?
Acer XB271HU
jorimt wrote:
10 Jul 2020, 14:59
2) Your capture program must V-SYNC, because I'm not seeing any tearing in that video.
I'm not using capture, linked footage is a phone recording. Go to 0:09 and press ">" to view video frame by frame.
Tear.png
Tear.png (402.29 KiB) Viewed 1640 times
UPD: actually, tearing starts even at 0:05

User avatar
jorimt
Posts: 1312
Joined: 04 Nov 2016, 10:44
Location: USA

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

Post by jorimt » 10 Jul 2020, 15:56

hmukos wrote:
10 Jul 2020, 15:11
Acer XB271HU
Th IPS version? Because that's my primary, so I'm well familiar with its characteristics and G-SYNC behavior. I can't remember, but I don't think you ever shared your specs, which can make a difference for how severe (or not severe) tearing is in this scenario.
hmukos wrote:
10 Jul 2020, 15:11
I'm not using capture, linked footage is a phone recording. Go to 0:09 and press ">" to view video frame by frame.

Tear.png

UPD: actually, tearing starts even at 0:05
Yeah, I spaced out, I see it's a camera video now. Still, that tearing (as depicted in the video) is extremely difficult to spot in the video. Is that the RTSS scanline sync test pattern flashing on the left?

Do you happen to have Overwatch? Because there's a really easy way to exhibit tearing in this scenario:

phpBB [video]


And getting back to this:
hmukos wrote:
10 Jul 2020, 14:42
as you can see RTSS frametime graph is flat
It doesn't matter. The RTSS frametime graph basically only tracks game/simulation/present time, not actually what ultimately ends up on the display (you'd need the likes of FCAT to track for that), so it could read as perfectly flat, and there could still be large enough frametime spikes (no matter how minor or brief) that could trigger a full tear like that with G-SYNC on + V-SYNC off within the G-SYNC range.

120 FPS @144Hz w/G-SYNC on + V-SYNC off is only tear-free when frametime spikes aren't occurring.

As explained in entry #2 of my Closing FAQ:
https://blurbusters.com/gsync/gsync101- ... ttings/15/
Wait, why should I enable V-SYNC with G-SYNC again? And why am I still seeing tearing with G-SYNC enabled and V-SYNC disabled? Isn’t G-SYNC suppose to fix that?

The answer is frametime variances.

“Frametime” denotes how long a single frame takes to render. “Framerate” is the totaled average of each frame’s render time within a one second period.

At 144Hz, a single frame takes 6.9ms to display (the number of which depends on the max refresh rate of the display, see here), so if the framerate is 144 per second, then the average frametime of 144 FPS is 6.9ms per frame.

In reality, however, frametime from frame to frame varies, so just because an average framerate of 144 per second has an average frametime of 6.9ms per frame, doesn’t mean all 144 of those frames in each second amount to an exact 6.9ms per; one frame could render in 10ms, the next could render in 6ms, but at the end of each second, enough will hit the 6.9ms render target to average 144 FPS per.

So what happens when just one of those 144 frames renders in, say, 6.8ms (146 FPS average) instead of 6.9ms (144 FPS average) at 144Hz? The affected frame becomes ready too early, and begins to scan itself into the current “scanout” cycle (the process that physically draws each frame, pixel by pixel, left to right, top to bottom on-screen) before the previous frame has a chance to fully display (a.k.a. tearing).

G-SYNC + V-SYNC “Off” allows these instances to occur, even within the G-SYNC range, whereas G-SYNC + V-SYNC “On” (what I call “frametime compensation” in this article) allows the module (with average framerates within the G-SYNC range) to time delivery of the affected frames to the start of the next scanout cycle, which lets the previous frame finish in the existing cycle, and thus prevents tearing in all instances.

And since G-SYNC + V-SYNC “On” only holds onto the affected frames for whatever time it takes the previous frame to complete its display, virtually no input lag is added; the only input lag advantage G-SYNC + V-SYNC “Off” has over G-SYNC + V-SYNC “On” is literally the tearing seen, nothing more.

For further explanations on this subject see part 1 “Control Panel,” part 4 “Range,” and part 6 “G-SYNC vs. V-SYNC OFF w/FPS Limit” of this article
(jorimt: /jor-uhm-tee/)
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

hmukos
Posts: 30
Joined: 16 Apr 2020, 15:41

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

Post by hmukos » 10 Jul 2020, 16:43

jorimt wrote:
10 Jul 2020, 15:56
Th IPS version?
Yes.
jorimt wrote:
10 Jul 2020, 15:56
I can't remember, but I don't think you ever shared your specs, which can make a difference for how severe (or not severe) tearing is in this scenario.
- Intel Core i7-8700K
- Nvidia GeForce GTX 1080
- Gigabyte Z370M D3H-CF
- Samsung SSD 850 EVO 500GB
- 16 GB RAM <s>2133MHz</s> (actually it is 3000Mhz, but task manager show only 2133Mhz, that's strange)
jorimt wrote:
10 Jul 2020, 15:56
Still, that tearing (as depicted in the video) is extremely difficult to spot in the video. Is that the RTSS scanline sync test pattern flashing on the left?
Yes, it is the frame color indicator in RTSS.
jorimt wrote:
10 Jul 2020, 15:56
Do you happen to have Overwatch?
Unfortunately not. :(
I'll try to make a video in CS:GO that makes it more obvious. But I myself see tears quite often (every couple of seconds).
jorimt wrote:
10 Jul 2020, 15:56
It doesn't matter. The RTSS frametime graph basically only tracks game/simulation/present time, not actually what ultimately ends up on the display (you'd need the likes of FCAT to track for that), so it could read as perfectly flat, and there could still be large enough frametime spikes (no matter how minor or brief) that could trigger a full tear like that with G-SYNC on + V-SYNC off within the G-SYNC range.

120 FPS @144Hz w/G-SYNC on + V-SYNC off is only tear-free when frametime spikes aren't occurring.
I see. So in my case it means that spikes happen quite often and they derive from ideal frametime by 1-2ms. When I used scanline sync in the same game, it was able to make tearline variance very minuscule (when I moved tearline into VBI, it never got out of there). Why can't regular frame limiter get the same result in this case?

User avatar
jorimt
Posts: 1312
Joined: 04 Nov 2016, 10:44
Location: USA

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

Post by jorimt » 10 Jul 2020, 16:58

hmukos wrote:
10 Jul 2020, 16:43
- Intel Core i7-8700K
- Nvidia GeForce GTX 1080
- Gigabyte Z370M D3H-CF
- Samsung SSD 850 EVO 500GB
- 16 GB RAM 2133MHz
You're fine there, especially for CS:GO then.
hmukos wrote:
10 Jul 2020, 16:43
I see. So in my case it means that spikes happen quite often and they derive from ideal frametime by 1-2ms. When I used scanline sync in the same game, it was able to make tearline variance very minuscule (when I moved tearline into VBI, it never got out of there). Why can't regular frame limiter get the same result in this case?
That's because scanline sync adheres to the VBLANK (this is what you steer the tearline into) + uses an RTSS FPS Limit, whereas other FPS limiters don't have a VBLANK component, and if they did, they'd be scanline sync or a syncing method again.

G-SYNC + V-SYNC is effectively doing the same thing as scanline sync (adhering to the VBLANK to 100% prevent tearing), but it's doing it better and at any framerate within the refresh rate.
(jorimt: /jor-uhm-tee/)
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

hmukos
Posts: 30
Joined: 16 Apr 2020, 15:41

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

Post by hmukos » 10 Jul 2020, 19:24

jorimt wrote:
10 Jul 2020, 16:58
You're fine there, especially for CS:GO then.
Turns out I forgot to enable XMP after updating BIOS. Now I set RAM frequency to 3000MHz. I can't tell for sure but it appears that there are much less tearlines at 120fps after enabling XMP (but they still persist).
jorimt wrote:
10 Jul 2020, 16:58
That's because scanline sync adheres to the VBLANK (this is what you steer the tearline into) + uses an RTSS FPS Limit, whereas other FPS limiters don't have a VBLANK component, and if they did, they'd be scanline sync or a syncing method again.

G-SYNC + V-SYNC is effectively doing the same thing as scanline sync (adhering to the VBLANK to 100% prevent tearing), but it's doing it better and at any framerate within the refresh rate.
So this 1-2ms fluctuating behaviour of regular RTSS limiter is normal then? I am using G-SYNC + V-SYNC ON normally but I thought that if it fluctuates so much with V-SYNC OFF, than there would be uneven framepacing with V-SYNC ON. But actually you are saying that G-SYNC + V-SYNC ON will give the same even frametimes as Scanline Sync, right?

User avatar
jorimt
Posts: 1312
Joined: 04 Nov 2016, 10:44
Location: USA

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

Post by jorimt » 10 Jul 2020, 20:08

hmukos wrote:
10 Jul 2020, 19:24
So this 1-2ms fluctuating behaviour of regular RTSS limiter is normal then?
No software on the system side is perfectly stable, as the system itself isn't. RTSS can set a render target for the game, but it's up to the system to comply, and ultimately, there is overshoot here and there. Not the fault of RTSS, just a limitation of system stability (and, to a point, physics).

I also honestly don't know why everyone is so fixated on perfectly flat frametime graphs; it's simply not practical to achieve on modern systems in modern games, and so long as the display rate is matching the refresh rate (aka VRR), and the game in question has proper frame pacing, small frametime fluctuations are not harmful, only frametime spikes are (and those aren't 100% avoidable either).
hmukos wrote:
10 Jul 2020, 19:24
I am using G-SYNC + V-SYNC ON normally but I thought that if it fluctuates so much with V-SYNC OFF, than there would be uneven framepacing with V-SYNC ON. But actually you are saying that G-SYNC + V-SYNC ON will give the same even frametimes as Scanline Sync, right?
G-SYNC + V-SYNC, as I explained in that entry of my closing FAQ, compensates for those fluctuations, that's why I call it "frametime compensation" in my article. Within the G-SYNC range, the V-SYNC "option" (it's not actually V-SYNC in this instance) is part of G-SYNC; when you disable it, you're removing G-SYNC functionality.

And any "uneven framepacing" in these instances would be coming from the game itself, not G-SYNC (as it's basically a mirror of the GPU output).

Scanline Sync is genuinely a great method, but it's pretty much a poor man's fixed refresh version of G-SYNC. Again, G-SYNC + V-SYNC (putting aside any semantics), is effectively steering the tearline into the VBLANK the same way, but automatically, and at any framerate within the refresh rate.

That said, you and anyone else is free to use G-SYNC + V-SYNC off, just don't expect a tear-free experience, and know that the input lag between it and G-SYNC + V-SYNC is virtually the same within the refresh rate, the only difference being the former can tear, and the latter can't.

The tearing is your literal and only input lag "savings."
(jorimt: /jor-uhm-tee/)
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

hmukos
Posts: 30
Joined: 16 Apr 2020, 15:41

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

Post by hmukos » 11 Jul 2020, 04:53

Thanks, jorimt. It was just bothering me if my PC's behaviour is normal.

User avatar
jorimt
Posts: 1312
Joined: 04 Nov 2016, 10:44
Location: USA

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

Post by jorimt » 11 Jul 2020, 07:21

hmukos wrote:
11 Jul 2020, 04:53
Sure thing @hmukos ;)
(jorimt: /jor-uhm-tee/)
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

moep
Posts: 2
Joined: 03 Aug 2020, 08:05

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

Post by moep » 03 Aug 2020, 08:09

How normal is it to have flickering outside of the G-Sync range on G-Sync compatible monitors?

I just went from an old monitor with a G-Sync module to one that's just compatible. The former had 0 flickering over 5+ years, the latter flickers like crazy outside of the VRR range (VA).

User avatar
jorimt
Posts: 1312
Joined: 04 Nov 2016, 10:44
Location: USA

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

Post by jorimt » 03 Aug 2020, 09:09

moep wrote:
03 Aug 2020, 08:09
How normal is it to have flickering outside of the G-Sync range on G-Sync compatible monitors?

I just went from an old monitor with a G-Sync module to one that's just compatible. The former had 0 flickering over 5+ years, the latter flickers like crazy outside of the VRR range (VA).
Model?
(jorimt: /jor-uhm-tee/)
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