Blur Buster's G-SYNC 101 Series Discussion

[hmukos]

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

Yes, I have. I understand that scanout happens from top to bottom and takes 1/"refresh rate" time.

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

Yes, I understand that. But doesn't tearline occurence at the bottom of the screen imply that our input was much later than if tearline appeared at the top?

I've drawn quick picture to illustrate how I thought it should happen (2000fps @ 60hz). Can you point to where is this picture wrong?

Example 1.png (15.01 KiB) Viewed 5047 times

Example 2.png (15.14 KiB) Viewed 5047 times

[jorimt]

Yes, I understand that. But doesn't tearline occurence at the bottom of the screen imply that our input was much later than if tearline appeared at the top?

No, with V-SYNC off, it just means the offsets of all the various factors in play were different at the point you made the input.

I've drawn quick picture to illustrate how I thought it should happen (2000fps @ 60hz). Can you point to where is this picture wrong?
Example 1.png
Example 2.png

It's wrong because it doesn't take into consideration the additional (oft randomized) delay input devices, the game engine/system, and the display incur at any given point, and appears to skips straight to frame render/scan in.

With this 2000 FPS 60Hz V-SYNC off scenario, you have...

- A randomized range of delay caused by your input device
- A randomized range of processing delay caused by the game engine/system
- A randomized range of processing delay caused by the display (separate of scanout)
- A randomized point in the 0ms - 16ms vertical range of a single 60Hz scanout cycle where the tearline reflecting the input will ultimately appear depending on A) how far along the existing scanout was when you clicked, B) the amount of delay the above factors add after the click is made, and C) how far along the current scanout is when the tearline reflecting the input ultimately appears.

[hmukos]

It's wrong because it doesn't take into consideration the additional (oft randomized) delay input devices, the game engine/system, and the display incur at any given point, and appears to skips straight to frame render/scan in.

I've put 12ms as an approximate baseline that includes those factors (you gave this approximate number in earlier answer). Frame render in this case is just 0.5ms.

- A randomized range of delay caused by your input device
- A randomized range of processing delay caused by the game engine/system
- A randomized range of processing delay caused by the display (separate of scanout)

Aren't those factors the same for 60hz and 240hz case? In your case those summed into 12ms plus some really small error margin.

- A randomized point in the 0ms - 16ms vertical range of a single 60Hz scanout cycle where the tearline reflecting the input will ultimately appear depending on A) how far along the existing scanout was when you clicked, B) the amount of delay the above factors add after the click is made, and C) how far along the current scanout is when the tearline reflecting the input ultimately appears.

So we clicked at A, waited for delay in B, frame was rendered in 0.5ms. Shouldn't we see the tearline right away? (I didn't quite understand the C to be honest. The scanout position should be the sum of A and B and the tearline should appear right after this scanout position, no?)

[jorimt]

I've put 12ms as an approximate baseline that includes those factors (you gave this approximate number in earlier answer). Frame render in this case is just 0.5ms.

That 12ms was an approximation of additional input lag added from the mouse/display to the single 27ms reading I mentioned though.

Aren't those factors the same for 60hz and 240hz case?

This is were we keep getting caught. Yes, but the scanout is now not the same. At 240Hz, the scanout now occurs 180 times more per second AND the individual cycles are 12.4ms faster per when directly compared to 60Hz. This affects all other factors.

So we clicked at A, waited for delay in B, frame was rendered in 0.5ms. Shouldn't we see the tearline right away? (I didn't quite understand the C to be honest. The scanout position should be the sum of A and B and the tearline should appear right after this scanout position, no?)

The display doesn't register the input first, the system does. The display doesn't "register" input until it appears via a tearline.

We have the point in which the existing scanout cycle was when you clicked, then the amount of scanout cycles that occur between the time you clicked and any additional time the input devices/system/display processing add to it (which again, can be randomized within a certain range per input read), and then the point in which the input reflects in the current scanout, which may be just starting, or half finished, or nearly finished.

--------

I also have another reply before you edited your post...

than why does the gap between Min and Max tighten for higher refresh rates?

Because the individual scanout cycles are faster and are occurring more frequently per second at higher than 60 refresh rates, so the scanout itself becomes less and less of a contributing factor to accumulative input lag, and you're progressively left with the remaining factors in the latency chain.

E.g. we're reducing the maximum contributing variance of the scanout factor from a range of 0 - 16.6ms (60Hz) to 0 - 10ms (100Hz), or 0 - 6.9ms (144Hz), or 0 - 4.2ms (240Hz), and so forth.

If you look at the "V-SYNC off + 0 FPS (2000+ FPS)" in each of the graphs here:
https://blurbusters.com/gsync/gsync101- ... ettings/9/

You'll see the min/max ratio is relatively proportionate to just under a single refresh cycle across the respective refresh rates:

- 60Hz min/max range = 13ms (of 16.6ms scanout)
- 100Hz min/max range = 8ms (of 10ms scanout)
- 120Hz min/max range = 6ms (of 8.3ms scanout)
- 144hz min/max range = 5ms (of 6.9ms scanout)
- 200Hz min/max range = 3ms (of 5ms scanout)
- 240Hz min/max range = 3ms (of 4.2ms scanout)

[BTRY B 529th FA BN]

Was curious about the functional difference between the On/Off Adaptive-Sync switch on my NVIDIA certified Gsync monitor, and what changing 'Monitor Technology' type (G-sync Compatible/Fixed Refresh) does. E.G. If I have Adaptive-Sync turned on with the monitor but Fixed Refresh enabled through NVCP is it the same thing has Adaptive-Sync on the monitor 'Off', or does the motion picture still route through the G-sync module and it's double buffer?

[jorimt]

Was curious about the functional difference between the On/Off Adaptive-Sync switch on my NVIDIA certified Gsync monitor, and what changing 'Monitor Technology' type (G-sync Compatible/Fixed Refresh) does. E.G. If I have Adaptive-Sync turned on with the monitor but Fixed Refresh enabled through NVCP is it the same thing has Adaptive-Sync on the monitor 'Off', or does the motion picture still route through the G-sync module and it's double buffer?

Is this a G-SYNC Compatible FreeSync monitor or a G-SYNC monitor with hardware module?

[BTRY B 529th FA BN]

Was curious about the functional difference between the On/Off Adaptive-Sync switch on my NVIDIA certified Gsync monitor, and what changing 'Monitor Technology' type (G-sync Compatible/Fixed Refresh) does. E.G. If I have Adaptive-Sync turned on with the monitor but Fixed Refresh enabled through NVCP is it the same thing has Adaptive-Sync on the monitor 'Off', or does the motion picture still route through the G-sync module and it's double buffer?

Is this a G-SYNC Compatible FreeSync monitor or a G-SYNC monitor with hardware module?

Omen X 25F so I think it's a G-SYNC Compatible FreeSync monitor?

[jorimt]

Was curious about the functional difference between the On/Off Adaptive-Sync switch on my NVIDIA certified Gsync monitor, and what changing 'Monitor Technology' type (G-sync Compatible/Fixed Refresh) does. E.G. If I have Adaptive-Sync turned on with the monitor but Fixed Refresh enabled through NVCP is it the same thing has Adaptive-Sync on the monitor 'Off', or does the motion picture still route through the G-sync module and it's double buffer?

Is this a G-SYNC Compatible FreeSync monitor or a G-SYNC monitor with hardware module?

Omen X 25F so I think it's a G-SYNC Compatible FreeSync monitor?

Yeah, I checked, it's an officially G-SYNC Compatible FreeSync monitor (no module, driver-side VRR).

So...

Was curious about the functional difference between the On/Off Adaptive-Sync switch on my NVIDIA certified Gsync monitor, and what changing 'Monitor Technology' type (G-sync Compatible/Fixed Refresh) does.

From looking at the manual, I'm guessing you have to have the Adaptive-Sync switched on in your monitor OSD to be able to enable the G-SYNC option in the NVCP, correct?

Anyway, adaptive-sync is just another name for VRR (variable refresh rate), aka FreeSync or G-SYNC. Since you mentioned G-SYNC, I assume you're using an Nvidia GPU.

If I have Adaptive-Sync turned on with the monitor but Fixed Refresh enabled through NVCP is it the same thing has Adaptive-Sync on the monitor 'Off', or does the motion picture still route through the G-sync module and it's double buffer?

Maybe, maybe not. It can depend on the monitor model. I do know that overdrive presets sometimes work differently with adaptive-sync mode enabled on certain FreeSync models. Not sure about the Omen.

As for it "routing" through the G-SYNC module, no, as your monitor has a software-only variant of VRR, thus no dedicated module. That said, the experience is typically comparable between the two (G-SYNC Compatible vs. G-SYNC module), especially on official G-SYNC Compatible displays.

[hmukos]

This is were we keep getting caught. Yes, but the scanout is now not the same. At 240Hz, the scanout now occurs 180 times more per second AND the individual cycles are 12.4ms faster per when directly compared to 60Hz. This affects all other factors.

Yes, it refreshes the screen much faster and many more times per second. But in our case the number of frameslices scanned would be the same (2000). At 240hz our frameclices would be just bigger on screen but the time to scan the fixed amount of them is the same, no?

The display doesn't register the input first, the system does. The display doesn't "register" input until it appears via a tearline.

But if our system made a change (rendered changed frame based on earlier input), than shouldn't tearline appear at the closest frameslice from the current scanout? (In both 60hz and 240hz cases the closest frameslice should be not farther than 0.5ms). Shouldn't the difference between system reaction and on-screen reaction be minuscule (0.5ms)?

[jorimt]

Shouldn't the difference between system reaction and on-screen reaction be minuscule (0.5ms)?

No, again, you're not counting the delay added, you're going straight to frame render. It's frame render (0.5ms) PLUS input device, game engine/system, and display lag. E.g. the 0.5ms number only comes in once the input finally triggers a render.

27ms, for instance (the maximum sample in my 60Hz graph) does not = 0.5ms. the 0.5ms is part of that total number for the single sample.

Yes, it refreshes the screen much faster and many more times per second. But in our case the number of frameslices scanned would be the same (2000). At 240hz our frameclices would be just bigger on screen but the time to scan the fixed amount of them is the same, no?

Firstly, not sure if you meant to say there are 2000 frameslices at 2000 FPS @60Hz in a single scanout, but there's actually about 33 (0.5 x 33.2 = 16.6), and that's if we're talking a perfect, constant 2000 FPS; the slice count could fluctuate a bit at any given point in reality.

Secondly, let's try looking at your own example images...

For both examples, ignore the "input" line, and look at the tearline placement only. Your own graphic is showing you exactly what you claim to fail to grasp yet in regards to the min/max range across refresh rates.

Here, the tearline is appearing around the 2ms mark of the scanout:



Here, the tearline caused by that same input is instead appearing around the 15ms mark of the scanout:



That's a 13ms difference in position for the same input, just as my min/max numbers in the test graphs show.

So yes, at 2000 FPS, the screen is updating around 33 times in a single scanout with V-SYNC off @60Hz, but that 33 times is across a fixed (and linear) 16.6ms, and only one of those updates is going to contain our sample, and said sample may appear right near the beginning of that scanout or right near the end. The higher it appears, the less "delay," the lower it appears the more "delay" within that scanout.

However, at 240Hz, 2000 FPS, the screen is only updating around 8 times (0.5 x 8.4 = 4.2) in a single scanout, so the span between top of scanout and bottom of scanout is reduced. As such, the possible difference in "delay" between the input appearing at the top or bottom of the scanout is smaller, thus a reduced min/max range.