Some observations on Scanline Sync

Everything about latency. Tips, testing methods, mouse lag, display lag, game engine lag, network lag, whole input lag chain, VSYNC OFF vs VSYNC ON, and more! Input Lag Articles on Blur Busters.
deama
Posts: 368
Joined: 07 Aug 2019, 12:00

Re: Some observations on Scanline Sync

Post by deama » 26 Sep 2021, 12:50

dustine79 wrote:
26 Sep 2021, 02:08
deama wrote:
14 Jun 2020, 13:45
Do the various scanline sync values have any affect on input lag? E.g. is there a difference between +1 and +500 or -1 and -500?

EDIT: Alright so I think I found out the answer, and it appears to be yes. I used the presentmon program to measure and found out some info, I posted in the thread:
I know the post is a year old but I have used this solution, Which you have given in your post and I have not succeeded in it

Can you share it with more details?
I experimented with it some more and found out it was due to the DWM, if you don't have the DWM active then input lag is pretty much the same no matter the value, barring the same fps.

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: Some observations on Scanline Sync

Post by Chief Blur Buster » 11 Oct 2021, 17:36

deama wrote:
14 Jun 2020, 13:45
Do the various scanline sync values have any affect on input lag? E.g. is there a difference between +1 and +500 or -1 and -500?

EDIT: Alright so I think I found out the answer, and it appears to be yes. I used the presentmon program to measure and found out some info, I posted in the thread:
viewtopic.php?f=10&t=5552&p=53520#p53520
A very minor effect.

Latency from scanline sync offsets (from the SAME reference point, e.g. beginning of VBI or end of VBI) is based on the horizontal scanrate. Now remember, it's the same reference point. If the VBI is 300 lines, then 200 from beginning of VBI is identical to -100 from end of VBI. Same virtual tearline location in VBI = same latency. Imagine a splice in a filmreel in the VBI between frames -- that's why we use the filmreel metaphor to explain tearingless VSYNC (RTSS Scanline Sync).

So don't forget to set your reference point.

1. The latency is always lowest immediately below a tearline, and highest immediately above a tearline.
There is a latency gradient from top edge to bottom edge of a VSYNC OFF frameslice.

2. Remember.... not all pixels have the same input lag!
The lag numbers you see are simply relative numbers for a fixed reference point (e.g. photodiode in middle of screen), even if latency is different in different area of the screen. Always consider latency numbers as relative, and don't compare latency numbers from different measuring methods.

No two lag measurement methodologies are alike. For example, RTINGS method versus HardwareUnboxed method. Both measuring methods are legitimate but they use different stopwatch start and stop triggers, e.g. which pixel is measured, whether all pixels are averaged, and what LCD GtG % completion to trigger at -- lag is lowest at GtG10% but highest at GtG90%, and super high at GtG100%. But human eyes sees pixels appearing even at 10%)

Tearingless VSYNC OFF is simply putting the tearlines inside the blanking interval between refresh cycles. It's like when the video cable is simply transmitting comma separators between refresh cycles.

First, unsynchronized VSYNC OFF roughly resembles this.

Image

You're splicing multiple frames into the same frame. That's what would happen if you spliced a real filmreel mid-frame and glued multiple frames together -- you'll get analog tearing on a 35mm filmreel if you spliced multiple frames of moving images mid-frame into the same frame -- it's like cutting the top half of a photograph and gluing together the bottom half of the next photograph taken a fraction of a second later. You'll see a physical tearline for real, in a physical photograph if you did that.

Now, metaphorically these diagrams makes it easier to imagine RTSS Scanline Sync latencies -- aka tearingless VSYNC OFF algorithms -- by a wide margin. (Technically it's sort of rolling your own custom low-lag VSYNC ON algorithm on top of the GPU & graphics driver's VSYNC OFF feature).

There is one fundamental difference -- there's a per-pixel-row latency involved (that doesn't exist for film), but we still used the filmreel metaphor anyway because it makes it easier for the average layperson to understand tearing latencies, and thus, easier to understand RTSS Scanline Sync latencies.

In this image, there is a 1/432sec latency difference between top edge of a frameslice (first pixel row, just below a tearline) and bottom edge of a frameslice (last pixel row, just above a tearline). Not all pixel rows are ever the same latency for VSYNC OFF on a sample-and-hold sequential-scanout display, each pixel row has its own separate latency from the scanout latency. This is the time differential between the global frame render being presented, and the sequential trickle of pixel rows being transmitted one at a time from the GPU to the monitor. VSYNC OFF is simply splicing mid-scanout. That is why we like to use the filmreel metaphor to help explain scanout latencies.

Now, given the SAME reference point, a bigger value (or, rather, a smaller-digits negative number) is less lag, until you hit the stability threshold.

RTSS Scanline Sync (and the new Special K equivalent feature, now that RTSS is not the only utility that can do this) -- simply puts the tearing inside the VBI instead of the visible refresh cycles, with precise raster-steered frame presentation techniques.

With larger blanking intervals (Quick Frame Transport) -- like bigger black gaps between frames on a filmreel -- it means more room to erratically splice between frames (tearing jitter -- more luxury to be sloppy splicing between frames). It can dramatically reduce latency, e.g. 144Hz refresh cycles transmitted over the cable in 1/180sec. So you now have more locations in the VBI to put tearing in.

Image

Remember, latency is lowest just below a tearline! So you want to put the tearline as close as possible to a new refresh cycle (barely above the top edge of the screen). The problem is that makes tearing more likely to become visible during stutters -- the timing tolerance is tighter. But you get lower latency.

So that's why small negative offsets have lower latency than bigger negative offsets -- the offscreen tearing is closer to the bottom of the VBI and just above the new refresh cycle (metaphorical virtual tearline -- splice between frames on a metaphorical temporal filmreel of refresh-cycles transmitted over the video cable). Lower lag, and tearing still invisible.

The bigger the VBI, the more range of offsets you can do without tearing, and more flexibility to hide tearing between refresh cycles.

Now use a bad offset, you will see tearing visible -- and it will often be mostly stationary but jitter depending on GPU/CPU load. Watch the jitter amplitude. If it jitters vertically about 50 pixel rows, then your ideal RTSS Scanline Sync offset might be -100 (hidden 50 pixel jitter margin + a safety margin of 50 more pixels for stability). So going temporarily intentionally to a bad RTSS number and testing strafe left/right or other horizontal motion, you can visually monitor the jittering to see how big a jitter margin you might need.

If you want to know how much lag exactly, then load your Custom Resolution Utility and get your display's horizontal scan rate. If your horizontal scanrate is 135 KHz (135000), then adding a +1 adds a 1/135000sec latency. So going -200 earlier would add 200/135000sec latency (a smidge over a millisecond). So the mathematically exact latency penalty of 1 unit of offset is 1/(horizontal scan rate) second. At 60Hz/1080p low resolution (lower scanrate) the lag per unit is bigger than at 240Hz/1440p (higher scan rate). Scan rate is the number of pixel rows per second transmitted over the video cable, and one pixel row takes 1/(horizontal scan rate) to transmit from GPU to monitor.

As a general rule of thumb, lowest lag without tearing is always end-of-VBI.

Please read the Quick Frame Transport thread on how end-of-VBI presentation is much lower lag than beginning-of-VBI presentation.

Generally we always prefer the reference point being set to end-of-VBI. Negative numbers automatically tells RTSS to use end-of-VBI as the reference point, and end-of-VBI is more VBI-size insensitive, so negative offsets are more universal for a wider variety of resolutions and refresh rates.

P.S. Did you know? If you're a classic 8bit programmer and you have raster interrupt experience with beam racing, tearlines are just rasters -- as evidenced by the Tearline Jedi demo.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

Post Reply