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.
User avatar
jorimt
Posts: 2481
Joined: 04 Nov 2016, 10:44
Location: USA

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

Post by jorimt » 19 May 2020, 15:59

hmukos wrote:
19 May 2020, 14:42
But wouldn't the first/second tearline since input reveal changes already (considering other factors don't increase lag)? What is the case where we should wait for all 5 tearlines to be scanned to get the on-screen reaction since input?
Wait, are we still talking about how I measured (which is the first movement spotted on screen), or are we talking about why 60Hz is laggier than 240Hz at the same framerate with V-SYNC off?
hmukos wrote:
19 May 2020, 14:42
I can't understand how does VSYNC OFF in this case defeat G-SYNC.
V-SYNC off can show parts of multiple frames in a single frame scan, G-SYNC can only show one complete frame within a single frame scan.
hmukos wrote:
19 May 2020, 14:42
Isn't the moment in time when lower part of "frame 2" in VSYNC OFF starts to appear (left image) the same as moment when the G-SYNC starts to scan the "frame 2" (right image)? Cause both situations in my understanding happen right when the "frame 2" was rendered.
In that diagram, you're seeing part of frame 2 (and ultimately frame 3) sooner than you are with G-SYNC, because it's being scanned into the current, not next, refresh cycle.

As I said in "G-SYNC 101: G-SYNC vs. V-SYNC OFF":
https://blurbusters.com/gsync/gsync101- ... ettings/9/
the true advantage comes when V-SYNC OFF can allow not just two, but multiple frame scans in a single scanout. Unlike syncing solutions, with V-SYNC OFF, the frametime is not paced to the scanout, and a frame will begin scanning in as soon as it’s rendered, regardless whether the previous frame scan is still in progress.
(jorimt: /jor-uhm-tee/)
Author: Blur Busters "G-SYNC 101" Series

Displays: ASUS PG27AQN, LG 48CX VR: Beyond, Quest 3, Reverb G2, Index OS: Windows 11 Pro Case: Fractal Design Torrent PSU: Seasonic PRIME TX-1000 MB: ASUS Z790 Hero CPU: Intel i9-13900k w/Noctua NH-U12A GPU: GIGABYTE RTX 4090 GAMING OC RAM: 32GB G.SKILL Trident Z5 DDR5 6400MHz CL32 SSDs: 2TB WD_BLACK SN850 (OS), 4TB WD_BLACK SN850X (Games) Keyboards: Wooting 60HE, Logitech G915 TKL Mice: Razer Viper Mini SE, Razer Viper 8kHz Sound: Creative Sound Blaster Katana V2 (speakers/amp/DAC), AFUL Performer 8 (IEMs)

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

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

Post by hmukos » 19 May 2020, 16:34

jorimt wrote:
19 May 2020, 15:59
Wait, are we still talking about how I measured (which is the first movement spotted on screen), or are we talking about why 60Hz is laggier than 240Hz at the same framerate with V-SYNC off?
I understood why 60hz feels laggier than 240hz at the same framerate after Chief's post. I didn't get why it also applied to first on-screen reaction metric (and still don't, read my question lower).
jorimt wrote:
19 May 2020, 15:59
V-SYNC off can show parts of multiple frames in a single frame scan, G-SYNC can only show one complete frame within a single frame scan.

In that diagram, you're seeing part of frame 2 (and ultimately frame 3) sooner than you are with G-SYNC, because it's being scanned into the current, not next, refresh cycle.
Yeah, I got this part, makes perfect sense.
jorimt wrote:
19 May 2020, 15:59
As I said in "G-SYNC 101: G-SYNC vs. V-SYNC OFF":
https://blurbusters.com/gsync/gsync101- ... ettings/9/
the true advantage comes when V-SYNC OFF can allow not just two, but multiple frame scans in a single scanout. Unlike syncing solutions, with V-SYNC OFF, the frametime is not paced to the scanout, and a frame will begin scanning in as soon as it’s rendered, regardless whether the previous frame scan is still in progress.
So my question is: if the results of input are shown in the first or second frame rendered after the input and frame render takes us only 0.5ms and a frame is being scanned as soon as it's rendered than why does "first on-screen reaction" metric vary so much (16ms input lag difference between Min and Max @ 60hz and not 1ms)? Shouldn't Max in this situation be always bigger than Min only by no more than 1ms?

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

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

Post by jorimt » 19 May 2020, 17:12

hmukos wrote:
19 May 2020, 16:34
So my question is: if the results of input are shown in the first or second frame rendered after the input and frame render takes us only 0.5ms and a frame is being scanned as soon as it's rendered than why does "first on-screen reaction" metric vary so much (16ms input lag difference between Min and Max @ 60hz and not 1ms)? Shouldn't Max in this situation be always bigger than Min only by no more than 1ms?
Sometimes the tearline appears at the top of the display, sometimes the bottom, sometimes somewhere in the middle. Positional tearline appearance is entirely unpredictable and randomized due to the random input (e.g. the mouse click roughly every second).

Again, the test isn't a constantly moving image, it's still until I make an input, at which point I wait for a "first" reaction on screen. Also, to be clear here, even though the image is otherwise still up until that point, the scanout is constantly occuring regardless, so my input randomly falls on a certain point in the given scanout, randomizing things further.
(jorimt: /jor-uhm-tee/)
Author: Blur Busters "G-SYNC 101" Series

Displays: ASUS PG27AQN, LG 48CX VR: Beyond, Quest 3, Reverb G2, Index OS: Windows 11 Pro Case: Fractal Design Torrent PSU: Seasonic PRIME TX-1000 MB: ASUS Z790 Hero CPU: Intel i9-13900k w/Noctua NH-U12A GPU: GIGABYTE RTX 4090 GAMING OC RAM: 32GB G.SKILL Trident Z5 DDR5 6400MHz CL32 SSDs: 2TB WD_BLACK SN850 (OS), 4TB WD_BLACK SN850X (Games) Keyboards: Wooting 60HE, Logitech G915 TKL Mice: Razer Viper Mini SE, Razer Viper 8kHz Sound: Creative Sound Blaster Katana V2 (speakers/amp/DAC), AFUL Performer 8 (IEMs)

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

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

Post by hmukos » 19 May 2020, 17:47

jorimt wrote:
19 May 2020, 17:12
Sometimes the tearline appears at the top of the display, sometimes the bottom, sometimes somewhere in the middle.
I'm talking about 2000fps @ 60hz case hence 0.5ms number for frame render. I understand that input falls on a random point in scanout but shouldn't the game react in the one of the next two tearlines right after that point? E. g. there are 30 tearlines in scanout, input fell on point when scanout is at 25th tearline. Shouldn't the result be shown in 1ms when scanout will get to 26th or 27th tearline (assuming that game engine reacts to input instantly)?

Is there any place where I can watch your test videos (especially the VSYNC OFF 2000 fps @ 60hz at Min and at Max case)? Cause I think that I misunderstand something very obvious and the videos would hopefully clear things up.

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

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

Post by hmukos » 19 May 2020, 19:09

By "tearlines" I meant potential tearlines (parts of image that would tear if there was constant moving). Sorry for messing up terminology.

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

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

Post by jorimt » 19 May 2020, 20:37

hmukos wrote:
19 May 2020, 17:47
shouldn't the game react in the one of the next two tearlines right after that point? E. g. there are 30 tearlines in scanout, input fell on point when scanout is at 25th tearline.
The game reacting is the tearline in this case though. In other words, we're only counting (and initially seeing) the tearline that was caused by the input. All proceeding tearlines don't count for the purpose of that single sample, thus the need to wait for the screen to become stationary again, repeat.
hmukos wrote:
19 May 2020, 17:47
Is there any place where I can watch your test videos (especially the VSYNC OFF 2000 fps @ 60hz at Min and at Max case)? Cause I think that I misunderstand something very obvious and the videos would hopefully clear things up.
There are 17.5GB worth of 508 videos total. Each of those only include 10 samples (clicks), and they are extremely low-res, and in very slow motion. I'm not sure you'd know what you were looking for (or at) without some context and practice. That, and I'd have to host them somewhere (they aren't right now).

That said, there are a couple example clips on the below page:
https://blurbusters.com/gsync/gsync101- ... ettings/3/

Also, here's the spreadsheet containing all the numbers from each of those videos:
https://onedrive.live.com/view.aspx?cid ... 50hiq4wuf8&
hmukos wrote:
19 May 2020, 19:09
By "tearlines" I meant potential tearlines (parts of image that would tear if there was constant moving).
Right.
(jorimt: /jor-uhm-tee/)
Author: Blur Busters "G-SYNC 101" Series

Displays: ASUS PG27AQN, LG 48CX VR: Beyond, Quest 3, Reverb G2, Index OS: Windows 11 Pro Case: Fractal Design Torrent PSU: Seasonic PRIME TX-1000 MB: ASUS Z790 Hero CPU: Intel i9-13900k w/Noctua NH-U12A GPU: GIGABYTE RTX 4090 GAMING OC RAM: 32GB G.SKILL Trident Z5 DDR5 6400MHz CL32 SSDs: 2TB WD_BLACK SN850 (OS), 4TB WD_BLACK SN850X (Games) Keyboards: Wooting 60HE, Logitech G915 TKL Mice: Razer Viper Mini SE, Razer Viper 8kHz Sound: Creative Sound Blaster Katana V2 (speakers/amp/DAC), AFUL Performer 8 (IEMs)

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

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

Post by hmukos » 20 May 2020, 04:07

jorimt wrote:
19 May 2020, 20:37
In other words, we're only counting (and initially seeing) the tearline that was caused by the input.
So we know that the tearline will show as soon as frame with new camera position is rendered. Doesn't that mean that the input was received by game engine just 1 frame before that? (The scanout line during input receive time was just 1-2ms higher than where the resulting tearline will show)

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

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

Post by jorimt » 20 May 2020, 07:58

hmukos wrote:
20 May 2020, 04:07
Doesn't that mean that the input was received by game engine just 1 frame before that? (The scanout line during input receive time was just 1-2ms higher than where the resulting tearline will show)
Not necessarily, depends on the game engine, the system running it, the input device(s), display, etc.

You seem to be wanting to predict the tearline position/occurrence after input solely in your head for the given scenario, but if that we're possible (or, at least, practical), we wouldn't need to test.

Did you fully read my test methodology?
https://blurbusters.com/gsync/gsync101- ... ettings/3/

I was using an LED connected to the mouse to determine when the click actually occurred, and then watching the display to see how much longer it took to actually reflect it on-screen:

Image
(jorimt: /jor-uhm-tee/)
Author: Blur Busters "G-SYNC 101" Series

Displays: ASUS PG27AQN, LG 48CX VR: Beyond, Quest 3, Reverb G2, Index OS: Windows 11 Pro Case: Fractal Design Torrent PSU: Seasonic PRIME TX-1000 MB: ASUS Z790 Hero CPU: Intel i9-13900k w/Noctua NH-U12A GPU: GIGABYTE RTX 4090 GAMING OC RAM: 32GB G.SKILL Trident Z5 DDR5 6400MHz CL32 SSDs: 2TB WD_BLACK SN850 (OS), 4TB WD_BLACK SN850X (Games) Keyboards: Wooting 60HE, Logitech G915 TKL Mice: Razer Viper Mini SE, Razer Viper 8kHz Sound: Creative Sound Blaster Katana V2 (speakers/amp/DAC), AFUL Performer 8 (IEMs)

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

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

Post by hmukos » 20 May 2020, 09:16

jorimt wrote:
20 May 2020, 07:58
hmukos wrote:
20 May 2020, 04:07
Doesn't that mean that the input was received by game engine just 1 frame before that? (The scanout line during input receive time was just 1-2ms higher than where the resulting tearline will show)
Not necessarily, depends on the game engine and the system running it.

You seem to be wanting to predict the tearline position/occurrence after input solely in your head for the given scenario, but if that we're possible (or, at least, practical), we wouldn't need to test.
I understand that but I tried to make a thought experiment to understand why tests showed exactly these results. I don't understand how does scanout speed affect the Min Max input lag cases for "VSYNC OFF 2000fps @ 60hz" if frame scanout happens at the same time the frame was rendered regardless of refresh rate. So suppose lag between input (LED lighting up) and actually rendering (but not scanning out yet) the frame based on that input is t ms. Intuitively that t should be more or less fixed. How does it vary by about 1/"refresh rate"?
jorimt wrote:
20 May 2020, 07:58
Did you fully read my test methodology?
https://blurbusters.com/gsync/gsync101- ... ettings/3/

I was using an LED connected to the mouse to determine when the click actually occurred, and then watching the display to see how much longer it took to actually reflect it on-screen:

Image
Yes, I have read it and for G-SYNC+V-SYNC that animation makes a lot of sense to me.

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

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

Post by jorimt » 20 May 2020, 09:50

hmukos wrote:
20 May 2020, 09:16
I don't understand how does scanout speed affect the Min Max input lag cases for "VSYNC OFF 2000fps @ 60hz" if frame scanout happens at the same time the frame was rendered regardless of refresh rate.
Because we're not counting all the tearlines sequentially from top to bottom within a single scanout, only the one triggered by the input, which, with V-SYNC off, could be anywhere on-screen. So since 60Hz has a 16.6ms scanout, it has a 16.6ms min/max range when testing V-SYNC off like this, whereas 240Hz only has a 4.2ms min/max range.

Have you seen an actual video of the scanout on an LCD display?

phpBB [video]


The individual "sweeps" from top to bottom (which contain all possible tearlines per cycle) at 60Hz are slower than they are at higher refresh rates, so if my click happens to register when the current scanout just started, and it ultimately reflects in the scanout 1, 2, or 3 (what have you) after it, the tearline could appear at the top, middle or bottom of the display.

If it appears at the bottom @60Hz, it's potentially up to 16.6ms slower than a tearline occurring closer to the top of the screen in that same scanout because you're eyeballs simply aren't going to see that tearline occur until the scanout is nearly complete, and regardless of framerate, sync or no sync, a single 60Hz scanout cycle takes 16.6ms. It's as simple as that.

Also, I will note I was measuring the differences between scenarios at the same refresh rate (per) here, not the base input lag numbers themselves, because that will vary depending on the given test equipment:
https://blurbusters.com/gsync/gsync101- ... ettings/9/
In fact, at 240Hz, first on-screen reactions became so fast at 1000 FPS and 0 FPS, that the inherit delay in my mouse and display became the bottleneck for minimum measurements.
I'd estimate combined mouse/display delay was up to 12ms. But yes, that still leaves us with a 13ms (nearly 1 frame) difference between min/max @60Hz, which again, scales proportionately with the given refresh rate; 240Hz had a 3ms difference between min/max readings.
hmukos wrote:
20 May 2020, 09:16
Yes, I have read it and for G-SYNC+V-SYNC that animation makes a lot of sense to me.
Good, because it's the same thing with V-SYNC off, except the reaction can occur at any point on the display's vertical axis (instead of just the top).
(jorimt: /jor-uhm-tee/)
Author: Blur Busters "G-SYNC 101" Series

Displays: ASUS PG27AQN, LG 48CX VR: Beyond, Quest 3, Reverb G2, Index OS: Windows 11 Pro Case: Fractal Design Torrent PSU: Seasonic PRIME TX-1000 MB: ASUS Z790 Hero CPU: Intel i9-13900k w/Noctua NH-U12A GPU: GIGABYTE RTX 4090 GAMING OC RAM: 32GB G.SKILL Trident Z5 DDR5 6400MHz CL32 SSDs: 2TB WD_BLACK SN850 (OS), 4TB WD_BLACK SN850X (Games) Keyboards: Wooting 60HE, Logitech G915 TKL Mice: Razer Viper Mini SE, Razer Viper 8kHz Sound: Creative Sound Blaster Katana V2 (speakers/amp/DAC), AFUL Performer 8 (IEMs)

Post Reply