Science: Scanout Skew -vs- Skew of Infinite-fps VSYNC OFF

Advanced display talk, display hackers, advanced game programmers, scientists, display researchers, display manufacturers, vision researchers & Advanced Display Articles on Blur Busters. The masters on Blur Busters.
User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: Science: Scanout Skew -vs- Skew of Infinite-fps VSYNC OF

Post by Chief Blur Buster » 25 Jun 2017, 12:07

I've created a modification of the TestUFO Blur Trail with preconfigured settings & an easier Full Screen Mode (just click anywhere once). I've now retroactively edited my earlier posts to include this link. It's called TestUFO Scan Skew.

www.testufo.com/scanskew

Try this on all kinds of screens, even your phone & tablet. (The popup message won't disappear yet on mobile devices, but ignore that for now). You can pinch zoom, and try all screen rotations/orientations to see how scan-out skew changes on your phone / tablet.
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!

User avatar
RealNC
Site Admin
Posts: 3741
Joined: 24 Dec 2013, 18:32
Contact:

Re: Science: Scanout Skew -vs- Skew of Infinite-fps VSYNC OF

Post by RealNC » 25 Jun 2017, 12:13

Nice one! The slant on the lines is clearly visible.

You can fix it if your monitor has pivot adjustment :mrgreen:
SteamGitHubStack Overflow
The views and opinions expressed in my posts are my own and do not necessarily reflect the official policy or position of Blur Busters.

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

Re: Science: Scanout Skew -vs- Skew of Infinite-fps VSYNC OF

Post by Chief Blur Buster » 25 Jun 2017, 12:26

RealNC wrote:You can fix it if your monitor has pivot adjustment :mrgreen:
:mrgreen:

...Then vertical movement will show scanout skew -- like lines of text during web browser vertical scrolling!

...I see scanout skew when flick-scrolling on my iPad Mini 4 in portrait mode.
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!

User avatar
RealNC
Site Admin
Posts: 3741
Joined: 24 Dec 2013, 18:32
Contact:

Re: Science: Scanout Skew -vs- Skew of Infinite-fps VSYNC OF

Post by RealNC » 25 Jun 2017, 13:07

Another thing that can be observed in the test is "tearing" with vsync. It's not tearing in the usual sense though. If you don't track the lines with your eyes but focus on a fixed spot, you can see the lines being drawn top to bottom. Since you don't do eye tracking, the lines appear to pop-up at random places. When the previous line disappears, you see it "vanishing" top to bottom, when a new line appears, it appears top to bottom.

This looks a bit like tearing. The effect is bigger in 60Hz, and is reduced the higher the frame rate goes. This is obviously due to the increased scanout speed at higher refresh modes.

This can also be used to detect whether your monitor does 120Hz scanout even in 60Hz. Some monitors do, especially TN panels, since they have optimized TN pixel response time nowadays to the point where they need two 120Hz scanouts in 60Hz mode to prevent the pixels from losing color. Or, at least, that's what I heard. It would seem that this is even done by some 60Hz TN monitors that don't actually support higher refresh rates.

If this is true (it seems plausible), one has to wonder how VRR copes with this.
SteamGitHubStack Overflow
The views and opinions expressed in my posts are my own and do not necessarily reflect the official policy or position of Blur Busters.

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

Re: Science: Scanout Skew -vs- Skew of Infinite-fps VSYNC OF

Post by Chief Blur Buster » 25 Jun 2017, 13:19

RealNC wrote:Another thing that can be observed in the test is "tearing" with vsync. It's not tearing in the usual sense though. If you don't track the lines with your eyes but focus on a fixed spot, you can see the lines being drawn top to bottom. Since you don't do eye tracking, the lines appear to pop-up at random places. When the previous line disappears, you see it "vanishing" top to bottom, when a new line appears, it appears top to bottom.
I see this in photographs of TestUFO Blur Trail and TestUFO Scan Skew. I get tearing in the photographs.

But for my eyes, I am unable to visually see it easily during fixed-gaze -- The easiest is when I sit 3 meters away at a 60Hz refresh rate, I definitely faintly see asymmetries during the fixed-gaze situation -- not tearing per se, but basically more faded at top-left and bottom-right of "each moving blob mess of lines".
RealNC wrote:If this is true (it seems plausible), one has to wonder how VRR copes with this.
During VRR, scan velocity is constant. For GSYNC 30-240Hz, the frames are scanned 1/240sec regardless of current framerate/refreshrate. If you lower refresh rate to 120Hz, and get a GSYNC 30-120Hz range, the frames are scanned 1/120sec regardless. Scan velocity is fixed, only the intervals between scanouts varies.
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!

User avatar
RealNC
Site Admin
Posts: 3741
Joined: 24 Dec 2013, 18:32
Contact:

Re: Science: Scanout Skew -vs- Skew of Infinite-fps VSYNC OF

Post by RealNC » 25 Jun 2017, 13:54

Chief Blur Buster wrote:
RealNC wrote:If this is true (it seems plausible), one has to wonder how VRR copes with this.
During VRR, scan velocity is constant. For GSYNC 30-240Hz, the frames are scanned 1/240sec regardless of current framerate/refreshrate. If you lower refresh rate to 120Hz, and get a GSYNC 30-120Hz range, the frames are scanned 1/120sec regardless. Scan velocity is fixed, only the intervals between scanouts varies.
Nah, I mean the pause between scanouts gets too long.

But never mind. I forgot that VRR already starts doubling frames (scanning them out twice or more) to prevent color loss. With very fast TN panels, this simply would start to happen sooner; usually at around 40FPS for many monitors, but super-fast panels would require that to happen even at 60FPS.
SteamGitHubStack Overflow
The views and opinions expressed in my posts are my own and do not necessarily reflect the official policy or position of Blur Busters.

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

Re: Science: Scanout Skew -vs- Skew of Infinite-fps VSYNC OF

Post by Chief Blur Buster » 27 Jun 2017, 14:13

RealNC wrote:
Chief Blur Buster wrote:
RealNC wrote:If this is true (it seems plausible), one has to wonder how VRR copes with this.
During VRR, scan velocity is constant. For GSYNC 30-240Hz, the frames are scanned 1/240sec regardless of current framerate/refreshrate. If you lower refresh rate to 120Hz, and get a GSYNC 30-120Hz range, the frames are scanned 1/120sec regardless. Scan velocity is fixed, only the intervals between scanouts varies.
Nah, I mean the pause between scanouts gets too long.

But never mind. I forgot that VRR already starts doubling frames (scanning them out twice or more) to prevent color loss. With very fast TN panels, this simply would start to happen sooner; usually at around 40FPS for many monitors, but super-fast panels would require that to happen even at 60FPS.
Oh yes, when the pause between scanouts become too long, another duplicate scanout occurs. Assuming the refresh recycle hasn't degraded visibly, the duplicate scanouts are virtually invisible to eyes. (Note, LCD color accuracy may degrade a percent or few, if left unrefreshed too long.)

However, you ideally want to time the repeat-refresh scanout so that the duplicate scanout doesn't hold up the next scanout if the current frame render completes shortly (e.g. a frame interval that was slightly a miss -- 1/29.9th of a second -- for a 30Hz bottom for GSYNC/FreeSync -- that scanout for a refresh cycle for a fresh frame -- will be delayed by the current now-in-progress repeat refresh cycle of the previous frame.

Solutions have been found to avoid these timing collisions of "repeat-refreshes" (of previous frame) versus "unexpectedly-slightly-too-late" (of new frame). This is called Low-Framerate Compensation. AMD did this first, but I believe GSYNC has also followed suit as it's a technologically simple add-on to extend the lower range of the VRR monitor.

Basically, it reschedules the repeat-scanouts (duplicate refresh cycles) to avoid interfering with the timing of refresh cycles with fresh scan-outs.

So if content is playing at 24 frames per second, it will time the repeat-refreshes roughly halfway between -- by running at 48Hz (with 1/48sec between scanouts). Likewise, 20fps would result in a 40Hz refresh rate (with 1/40sec between scanouts), and 17fps would result in a 34Hz refresh rate (with 1/34sec between scanouts). Basically repeat-refresh cycles are intentionally done 'early' to prevent holding up new-frame refreshes.

The repeat-refreshes don't even have to be precisely in between (as long as VRR logic is very good -- good overdrive, good inversion -- to minimize VRR artifacts). For very good VRR< the repeat refresh cycles are quite completely invisible as long as they don't fudge the timing of refresh cycles for freshly new frames.

Scanout velocity is always done at the fastet refresh cycle speed (current top end of currently configured VRR range). So if the monitor is configured to a max 144Hz VRR range -- then the repeat-refresh scanouts are always 1/144sec long each. So the repeat-refresh scanout has to begin occur at least 1/144sec earlier than the next brand new frame -- to prevent delaying the scanout for a brand new frame (Which potentially adds a microstutter caused by not being able to refresh exactly when the frame was completed).

For a 240Hz VRR monitor, it is easier to void repeat-refresh scanouts from colliding with the timing of new-refresh scanouts, because scanout is 1/240sec (only 4.1ms). So in this case a higher Hz VRR range actually makes it easier to lower the bottom end of the range via Low Framerate Compensation (and similar algorithms). Easily as low as single-digit frames per second.

Repeat-scanouts are invisible (24fps@48Hz is exactly the same looking as 24fps@24Hz) except for extremely minor artifacts such as variable-speed modulating patterns within LCD inversion test patterns (the voltage for each pixel inverts every scanout, negative->positive and positive->negative, usually in a fine-checkerboard pattern) -- see www.testufo.com/inversion and both the Lagom/Techmind links on that. Inversion artifacts (on certain VRR displays) can modulate at varying speeds depending on the timing and frequencies of the scanouts.
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!

Sparky
Posts: 682
Joined: 15 Jan 2014, 02:29

Re: Science: Scanout Skew -vs- Skew of Infinite-fps VSYNC OF

Post by Sparky » 27 Jun 2017, 15:44

Chief Blur Buster wrote:Solutions have been found to avoid these timing collisions of "repeat-refreshes" (of previous frame) versus "unexpectedly-slightly-too-late" (of new frame). This is called Low-Framerate Compensation. AMD did this first, but I believe GSYNC has also followed suit as it's a technologically simple add-on to extend the lower range of the VRR monitor.
Nvidia did that first, PCPer did an article on it back when freesync first came out: https://www.pcper.com/reviews/Graphics- ... ies-Differ

Even back in 2015, G-Sync started doubling frames before it got to the 30fps minimum refresh rate of the monitor, so it was still displaying frames on time below 30fps. If it was waiting all the way until the deadline before refreshing, you'd get a short-long-short-long pattern on the scope instead of a consistent spacing. Of course, it's likely there have been further changes in the last couple years, and freesync has LFC now.

User avatar
RealNC
Site Admin
Posts: 3741
Joined: 24 Dec 2013, 18:32
Contact:

Re: Science: Scanout Skew -vs- Skew of Infinite-fps VSYNC OF

Post by RealNC » 27 Jun 2017, 16:24

And the video is here, where they use an oscilloscope to see what happens with low refresh rates in G-Sync and Freesync:

https://www.youtube.com/watch?v=VkrJU5d2RfA

I don't think they ever repeated the test later. (It should be noted that PCPer seems to be NVidia biased. Not sure if that's really true, but usually they seem to focus on news that show NVidia as being superior to AMD :P)
SteamGitHubStack Overflow
The views and opinions expressed in my posts are my own and do not necessarily reflect the official policy or position of Blur Busters.

Sparky
Posts: 682
Joined: 15 Jan 2014, 02:29

Re: Science: Scanout Skew -vs- Skew of Infinite-fps VSYNC OF

Post by Sparky » 27 Jun 2017, 16:39

RealNC wrote:And the video is here, where they use an oscilloscope to see what happens with low refresh rates in G-Sync and Freesync:

https://www.youtube.com/watch?v=VkrJU5d2RfA

I don't think they ever repeated the test later. (It should be noted that PCPer seems to be NVidia biased. Not sure if that's really true, but usually they seem to focus on news that show NVidia as being superior to AMD :P)
I've been called Nvidia biased too. I think my comments on G-sync vs Freesync have been accurate as I can make them. AMD was late to this party, and more reliant on third parties, so naturally it took them a while to catch up. At least freesync 2 should be an improvement, I think AMD should have held the original freesync label to higher standards, at least excluding anything incapable of LFC(those monitors can still use the adaptive sync branding).

Post Reply