RTSS now has new automatic Low-Lag VSYNC ON (raster based)

Everything about displays and monitors. 120Hz, 144Hz, 240Hz, 4K, 1440p, input lag, display shopping, monitor purchase decisions, compare, versus, debate, and more. Questions? Just ask!
User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: RTSS now has new automatic Low-Lag VSYNC ON (raster base

Post by Chief Blur Buster » 20 Feb 2019, 20:49

andrelip wrote:What is the behavior of s-sync when fps are inconstant and the frametime get longers than the refresh. Let's say a random drop occors to the range of 220-240 for 240hz. It will start the render of the new frame immediately? It will add a single and long delay to the return to the desired position as fast as possible? It will spread that delay across n frames to smooth the transition?
It depends on which sync tech, which GPU, which graphics driver version, and what behaviour it imparts on a sync mode.

VSYNC ON will simply round to the next refresh cycle (sudden +16.7ms frametime spike for a delayed frame at 60Hz).

Now, Scanline Sync is usually used with VSYNC OFF, so it is complicated to explain.

see VSYNC OFF tearline are just rasters (Warning: Technological "Pandora Box" topic)

The input lag is relative to the location of the tearline. In a Custom Resolution Utility, the relative lag increaser of a pixel row below a tearline is ([pixel rows]/[horizontal scanrate]) latency.

If your screen is displaying 160KHz horizontal scan rate (160000 scanlines per second), the input lag of a pixel row 10 rows below the tearline is 10/160,000sec of input lag.

That's latency at the GPU output, subject to any micropacketization latency (which might bundle 2, 4, 6, or 8 pixel rows together simultaneously) and other nitty-picky microsecond-league variables.

But needless to say, the point I am making is that the latency of a specific pixel row is actually relative to the location of its preceding tearline.

So in the case of RTSS Scanline Sync, the usual test case is to calibrate the tearline to just right above the top edge of the screen (aka hiding the tearline between refresh cycles). Now, this excludes the lag of other parts of the chain....

Now that complexity explained, let's try to answer your question...

In addition to the increased frametime latency (the rendertime latency -- e.g. becoming 1/220sec instead of 1/240sec on a 240Hz monitors) -- your latency gradient during RTSS Scanline Sync will vertically shift if the tearline is in a new location. Scanout lag is always relative to the tearline immediately above.

If you have a tearline in the middle of the screen, that means you can have a weird wraparound lag gradient [2ms...4ms][0ms...2ms] for the screen instead of [0...4ms]. For a middle-of-screen tearline at 240Hz, basically top edge has a +2ms lag, just above tearline has +4ms lag, just below tearine has 0ms lag, and bottom edge has +2ms lag that then wraps around back to the top for the next refresh cycle (right after what is usually a sub-millisecond VBI when you're not using a Large Vertical Total).

Be noted, this is the scanout latency, not other parts of the lag chain (e.g. rendering lag, mouse lag, display processing lag, GtG pixel response lag, etc).

Fortunately, if you usually keep full framerate at Scanline Sync, framedrops only create minor reappearances of tearing that only disrupt latency consistency briefly. In fact, if it's only a very slight movement of tearline downwards from top edge (e.g. stays near top edge), then your latency gradient has only shifted slightly, possibly only adding a sub-millisecond momentary inconsistency only for those specific refresh cycles that has an aberrant tearline location different from its stable location. (Keep in mind 1ms = one quarter screen height scanout on 240Hz).

In reality, frametime latency variances will be your bigger latency error margin, especially on a 240Hz monitor. At 60Hz, the slow scanout latency (16.7ms) definitely can give you major latency inconsistency, so perfect RTSS Scanline Sync is more important at 60Hz than at 240Hz -- it's okay to be more tolerant of RTSS Scanline Sync abberations at 240Hz.

Now, if you're one of those who prefer a brief stutter instead of a brief tearline, you may have already calibrated RTSS Scanline Sync with VSYNC ON / Enhanced Sync / Fast Sync. In this event, your lag increase effect usually be a binary sudden increase of one refresh cycle (with an accompanying microstutter) for only one instant of one refresh cycle. Such as [16ms...16ms...16ms...16ms...33ms...16ms....16ms] during 60Hz. However, this method can be useful when you're much more bothered by tearing than stutters, as long as those framerate slowdowns are "exception to the rule" -- RTSS scanline sync is mainly recommended for games that can almost always run at full framerate, where drops are exceptions rather than the rule.
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!

andrelip
Posts: 160
Joined: 21 Mar 2014, 17:50

Re: RTSS now has new automatic Low-Lag VSYNC ON (raster base

Post by andrelip » 21 Feb 2019, 16:18

Thanks for the explanation!

I'm asking that because I want to have the lowest input lag possible.

Since I've achieved that 580hz based VT for the 240hz I'm thinking that this could not be the best scenario for v-sync off and no sync. The frame will be transmited very fast indeed but then we will be stucked at the long vertical of the blanking interval.

If the blanking interval is too bigger for the frequency and the game fps then it should be very similar to fast sync from what I've understand. The visible area would be rendered so fast that the probability of having tear would be minimum. If the video buffer just have been updated this will be perfect but if the frame is almost being replaced then we would have almost a frame of delay. If s-sync don't add much latency then we have guarantee that we are being in the optimal scenario here where we start scanning the visible area ultra fast and as soon as the frame have been drawn.

I even thought of doing the contrary... getting the very minimum VT without any sync. That way the frame transmission will be slow but the new frame will be rendered immediately no matter where.

My last and random thought is if the blank interrupt have any usage by modern gaming engines when v-sync is off. Like some kind of compensation.

Is that too crazy?
andrelip

Posts: 33
Joined: 21 Mar 2014, 19:50

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

Re: RTSS now has new automatic Low-Lag VSYNC ON (raster base

Post by Chief Blur Buster » 21 Feb 2019, 16:55

andrelip wrote:Since I've achieved that 580hz based VT for the 240hz
1/580sec Quick Frame Transport of a single refresh cycle? Wow; that's the fastest I've heard thus far.

At those frame delivery speeds, VSYNC ON would probably be ultralow lag if you've calibrated RTSS Scanline Sync.
andrelip wrote: even thought of doing the contrary... getting the very minimum VT without any sync. That way the frame transmission will be slow but the new frame will be rendered immediately no matter where.
Correct. Quick Frame Transport does not help VSYNC OFF because frame slices is like realtime streaming to scanout.

However, Quick Frame Transport is hugely beneficial to VSYNC ON in dramatically lowering full-frame-delivery latency.
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!

Acclaim
Posts: 3
Joined: 28 Mar 2015, 16:30

Re: RTSS now has new automatic Low-Lag VSYNC ON (raster base

Post by Acclaim » 23 Feb 2019, 19:40

Chief Blur Buster wrote:For users who want to combine RTSS Scan Line Sync with VSYNC ON / Fast Sync / Enhanced Sync



1. Use VSYNC OFF first
2. Calibrate scanline sync (via keyboard shortcut) until you've got a vibrating tearline that NEVER goes below the bottom edge of the screen.
3. Go back to VSYNC ON / Fast Sync / Enhanced Sync
4. You'll see it stay more consistently, perfect smoothness & no lag spikes.

In VSYNC OFF, if the "tearline" goes below the bottom edge of the screen, that's the sudden 33ms frametimes if you were using Fast Sync -- because that's a missed VSYNC. That's why if I recommend if you combine RTSS Scanline Sync with NVIDIA Fast Sync -- you must calibrate tearline position to the point where it permanently stays above the bottom edge of the screen. If it vibrates crazily, raise the tearline higher (bigger negative scanline offset). So that tearlines never, never, never touches the blanking interval (except during rare framerate dips). You want to get tearlines as close as possible to bottom edge of screen, but never reaching the blanking interval (A.K.A. tearline occasionally going below bottom edge of screen).
Having some trouble using the keyboard hotkeys in RTSS. I have added "SyncHotkeys=1" to my Global profile but Ctrl+Shift+Up does not seem to change the Scanline sync number on RTSS (displayed on a secondary monitor). As well, I do not see a tear line with any setting that I manually enter into RTSS (I've tried -30, 10, 900, 1020, 1050).

Is there a guide to help with this for someone who has not used RTSS previously? Any thoughts? Sorry for the bother!

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

Re: RTSS now has new automatic Low-Lag VSYNC ON (raster base

Post by Chief Blur Buster » 23 Feb 2019, 20:12

Make sure tearing is visible BEFORE you enable RTSS for Scanline Sync
If you don't see any tearing, disable RTSS and fix your tearing FIRST before re-enabling RTSS. Pretend you never installed RTSS yet (disable RTSS) and make sure tearing is visible first.

Trying to do RTSS Scanline sync without making tearing visible first -- is like trying to fix a car tire of a car that has a dead engine. You have to fix the engine (tearing) first since Scanline Sync is basically custom steering of tearline positions. First, there has to be visible tearlines at all, before you can adjust tearlines.

Remember to test using horizontal motion so play something that has lots of horizontal motion with high contrast. That is the easiest stuff to see tearing in.

If you have never ever seen VSYNC OFF tearing before, you need to learn that first (e.g. metaphorically get your driver's license) before you learn RTSS Scanline Sync. Turn off RTSS first. Study VSYNC OFF first before you study RTSS Scanline Sync.
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!

Acclaim
Posts: 3
Joined: 28 Mar 2015, 16:30

Re: RTSS now has new automatic Low-Lag VSYNC ON (raster base

Post by Acclaim » 23 Feb 2019, 21:31

Chief Blur Buster wrote:Make sure tearing is visible BEFORE you enable RTSS for Scanline Sync
If you don't see any tearing, disable RTSS and fix your tearing FIRST before re-enabling RTSS. Pretend you never installed RTSS yet (disable RTSS) and make sure tearing is visible first.

Trying to do RTSS Scanline sync without making tearing visible first -- is like trying to fix a car tire of a car that has a dead engine. You have to fix the engine (tearing) first since Scanline Sync is basically custom steering of tearline positions. First, there has to be visible tearlines at all, before you can adjust tearlines.

Remember to test using horizontal motion so play something that has lots of horizontal motion with high contrast. That is the easiest stuff to see tearing in.

If you have never ever seen VSYNC OFF tearing before, you need to learn that first (e.g. metaphorically get your driver's license) before you learn RTSS Scanline Sync. Turn off RTSS first. Study VSYNC OFF first before you study RTSS Scanline Sync.
Thanks Chief! Back to the DMV I go!

Will do further testing tomorrow morning.

Klesk Reaver
Posts: 2
Joined: 30 Jan 2019, 20:32

Re: RTSS now has new automatic Low-Lag VSYNC ON (raster base

Post by Klesk Reaver » 15 May 2019, 10:23

So just to be clear, using Scanline Sync + V-Sync On is the better alternative to Framerate limit (FPS cap) + V-Sync On?
I'm assuming Scanline Sync prevents the V-Sync lag by not allowing the framerate to go over refresh rate? (just like FPS cap does)

I've been testing visibility of the tearline using a -150 setting and V-Sync Off, it appears near the bottom of the screen.

V-Sync On gets rid of the tearline and going off what I've been reading my goal is to test the worst fluctuation of the line and use a setting that prevents it from going below the screen in order to reduce input lag?

Is there a major difference between using V-Sync and Fast Sync in combination with Scanline Sync?
My understanding of Fast Sync was that it works best when your framerate far exceeds your refresh rate, but with Scanline Sync aren't we keeping framerate below refresh rate?

cheers for help in advance and thanks for such an amazing method, I have a G-Sync monitor but due to using a dual PC set-up and using HDMI instead of DisplayPort I cannot use G-Sync, I have a Freesync HDMI 2.0 monitor arriving tomorrow but from what I read Freesync doesn't function on HDMI either, so I guess Scanline Sync is my only choice if I continue using a capture card.

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

Re: RTSS now has new automatic Low-Lag VSYNC ON (raster base

Post by RealNC » 15 May 2019, 11:14

Klesk Reaver wrote:So just to be clear, using Scanline Sync + V-Sync On is the better alternative to Framerate limit (FPS cap) + V-Sync On?
Scanline sync must be used with vsync OFF or with fast sync (nvidia) or enhanced sync (amd.) It should not be used with vsync ON.
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.

DsKri
Posts: 2
Joined: 13 Jun 2019, 09:24

Re: RTSS now has new automatic Low-Lag VSYNC ON (raster base

Post by DsKri » 13 Jun 2019, 12:07

Hey guys,

I've only just begun properly acquainting myself with various latency & input lag improvement methods including scanline sync (it's FANTASTIC by the way, thank you Sir Blur Buster) and similarly to @Simboubou's query from a few posts ago (below), but in terms of use-case as well as curiosity; when, if at all, would you favour low lag v-sync over scanline sync?

I don't understand the technicalities just yet and was just trying to figure out what would be more beneficial in the cases of say; a slightly lower end PC that's not quite capable of stable %70~ GPU usage? Or a user who might prefer to sacrifice a little smoothness in favour of graphics?
And while on the topic of use-cases, what is occurring when using fast sync + scanline sync and in which situation would it be most beneficial?

Apologies in advance as that's like 5 questions including Simboubou's original post - I just tried and failed as he/she did to find conclusive answers

Thanks heaps in advance.
Simboubou wrote: "...I've read some technical info on Guru and Blurbusters, and while I think I understand the basics, I still don't exactly understand the difference between s-sync and low lag vsync (let's call that lsync), more specifically why ssync has lower input lag than lsync.

- I understand that no-vsync just render frames as fast as it can. Once a frame is rendered, it is copied to the "output frame", creating a tearline. If I understand correctly, ssync uses its framerate limitation method in a dynamic way where it tries to end the rendering on a specific scanline, so that the copy to the output frame occurs during the vblank, hence the low-lag no-tearling.

- But then, what is difference with lsync ? Since we are preventing the output queue to fill, aren't we always copying the last rendered frame in the output frame at each vblank, which is essentially the same as ssync ? What am I missing here ?..."

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

Re: RTSS now has new automatic Low-Lag VSYNC ON (raster base

Post by Chief Blur Buster » 13 Jun 2019, 12:50

Okay, here's the explanation:

1. The low-lag VSYNC trick, found at Low-Lag VSYNC
2. The Scanline Sync mode for RTSS

The low-lag VSYNC has a latency-varying artifact.
Even if there's a tiny difference (even 0.001) between framerate and Hz, it can never be exact with the "cap 0.0x below Hz" trick.

Even though it's lower latency, the latency sawtooths as the refreshrate beat-frequencies against framerate. On a fixed-refreshrate display (not using variable refresh rate), the refresh rate is not perfectly matched with frame rate. So there's always an arbitrary (0...refreshtime) additional latency depending on the phase of the frame relative to the phase (VBI) of the refresh cycle.

Image

Any cap-differentials on a fixed-Hz display, creates a beat frequency effect. It's constantly slewing. Yes, it's lower lag than VSYNC ON, but the latency is varying for non-VRR cap below. (This is not a problem for FreeSync, this is not a problem for GSYNC, this is not a problem for S-Sync .... This only happens when doing cap-differentials on fixed-Hz.

When it sawtooths, there's a sudden stutter (or series of stutters). But even between them, is a continually varying input-lag as the phase constantly slews between the frame Present() time versus GPU blanking interval time.

The beat-frequency effect between Hz and fps creates TWO problems:
1. Sawtooth varying lag
2. Stutter at the sharp points

It's still lower lag than VSYNC ON while much smoother than VSYNC OFF. But you're accepting a tradeoff.

Scanline Sync Permits Glass Floor Latency
Scanline Sync avoids that by achieving a perfect framerate=Hz match, even as tight as the bottom of the sawtooths and keeping it constant there (for consistent-frametime games). So the latency is much flatter with a properly, well-tuned, well-optimized scanline-sync.

Assuming your game can permanently keep a framerate beyond refresh rate, Scanline Sync works well. In the best situation, the latency is a glass floor when game frametimes are consistent. No sawtoothing.

But your latency will potentially spike much worsely (with worse artifacts like tearing) when you fail to sustain framerate. In this situation, framerate-below-Hz looks worse with S-Sync than Low-Lag VSYNC method. The poison suddenly switches between benign-to-bad when framerate crosses over the refreshrate point -- and the pros/cons flips around a bit.

A workaround is calibrating S-Sync with Fast Sync / Enhanced Sync (using the VSYNC OFF tearline pre-calibration method) if you still want to use S-Sync with games that sometimes have framerates falling below Hz. This will allow you to have glassfloor latency for full framerate situations, while having acceptable/tolerable latency mechanics for framerate-below-Hz situations, while also avoiding the "ugly-tearing-surge" effect of S-Sync framerate slowdowns.

TL;DR:
-- Use Low-Lag VSYNC if you cannot sustain framerates above Hz,
-- Use S-Sync if nearly all of your framerate range permanently stays above refresh rate (if you were using VSYNC OFF before switching S-Sync), or if you're willing to lower your refresh rate to make S-Sync work better
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