Requesting Scanline Sync Tutorial

Nobody?
@RealNC @AsiJu are you there?

 

@Siberto2

Sorry, you're asking way too many questions, and they have been answered already many times.

 

Yep, familiarize yourself better with Vsync / Gsync / s-sync and read this thread in its entirety (helped me greatly with s-sync too).

 

The other sync methods (VSYNC ON, VSYNC OFF) is like learning how to drive a car.

The use of RTSS Scanline Sync is like learning how to fly an airplane -- it's more complicated.

It could be simplified probably to simpler HOWTOs, because I think that the S-Sync hotkeys should be easily enabled in the Rivatuner user interface. That's the only missing option that makes it easy to calibrate Scanline Sync -- the ability to adjust the tearing up/down visually. Then it'd be more like learning to fly a Cessna than flying a Boeing 737.

Note: Someone said S-Sync is useless on G-SYNC. Not necessarily: S-Sync can still be useful on a G-SYNC monitor because ULMB does not support VRR. S-Sync is perfect for blur reduction such as ULMB because it eliminates ULMB jitters/stutters. Blur reduction looks best with fps = Hz, and people don't like using VSYNC ON because that is laggy. So S-Sync provides a Plan B. One you should ideally have your 0.1% frametimes faster than your refresh rate. (e.g. no worse than 10ms frametime spikes for a 100Hz refresh rate), or S-Sync might not be worth it.

1. Enable ULMB or DyAc or ELMB or whatever blur reduction
2. Enable VSYNC ON
3. Increase mouse DPI to 1600+ (needed to de-jitter ULMB), decrease in-game sensitivity to compensate
4. Play a game that always run fps=Hz (Reduce refresh rate and game detail if necessary)

And you'll notice ULMB is so much smoother (TestUFO smooooooth turns/strafes!). But the problem is VSYNC ON is laggy. That's where RTSS Scanline Sync comes to the rescue as a low-latency VSYNC ON alternative.

As Einstein says, "it's all relative".

If you picture the signal as an endless reel of refresh cycles and VBIs, then both positive and negative numbers are relative to to screen top edge.
-- Positive numbers go from top-to-bottom
-- Negative numbers start at the top and decrement into the VBI and then back into the refresh cycle.

 

<Advanced>
Sometimes RTSS Scanline Sync is now used to roll-it-yourself DIY Quick Frame Transport when used with Large Vertical Totals.
Advantages:
- A Large VBI (Large Vertical Total) transmits the visible refresh cycle faster to the monitor (less time transmitting refresh, more time syncing between refreshes).
- A Large VBI (Large Vertical Total) hides the vibration amplitude of a tearline better. VT1300 for 1080p provides bigger tearing-hiding area than VT1125 for 1080p
- This is the principle trick of HDMI's Quick Frame Transport (QFT) in HDMI 2.1



You can actually emulate this in software DIY via RTSS Scanline Sync. Over any cable, VGA, DVI, DisplayPort, not just HDMI. However, very few monitors are large-vertical-total friendly, as your latency decrease will be proportional to the increase in VT. Doubling your Vertical Total will double the scanout velocity of your refresh cycle. It also depends on how the monitor responds -- whether it buffers the refresh cycle (e.g. XL2540) or scans it out immediately (e.g. XL2720Z) -- so certain 144Hz monitors are large-VT friendly.

FreeSync/GSYNC is an easier method of QFT. Since max Hz + framerate cap = a low-lag low-Hz mode. But if your monitor has no FreeSync, then this RTSS Scanline Sync QFT mode is a good alternative if you're an advanced user who are already RTSS Scanline Sync experienced.

RTSS Scanline Sync is quite powerful and unlocks some neat features like software-based Quick Frame Transport -- when used in conjunction with a Custom Resolution Utility (ToastyX or NVIDIA) -- tricks such as transmitting a 60Hz emulator frame in 1/144sec on a fixed-Hz 144Hz monitor that supports approximately ~VT2700 for 60Hz -- in a zero-stutter manner with 60 refresh cycles appearing exactly 1/60sec apart, with the 60 refresh cycles being refreshed individually faster in 1/144sec (faster scanout) -- a Quick Frame Transport acceleration factor of approximately 2.4x. Be noted not all monitors supports large blanking intervals, but there are a bunch of fixed-Hz monitors (that don't support FreeSync) such as the BenQ XL2720Z, that can be tricked into doing various kinds of large vertical totals, and the attendant further input-lag decreases that are possible (beyond just only doing RTSS Scanline Sync).

One Picture Of Do-It-Yourself Quick Frame Transport via RTSS Scanline Sync:



Prerequisites:
(A) Non-blocking sync method such as VSYNC OFF
(B) Negative raster scanline indexes (or large positive scanline indexes late in VBI such as "1350" for a "Vertical Total 1440")

You must have your entire tearline vibration amplitude completely above the top edge of your screen. If your tearline is vibrating too much, lower refresh rate, raise ForceFlush values (config), reduce detail, until your framerate range (when uncapped) is completely above your refresh rate even for most of your framerate dips. THEN your tearline jitter amplitude is thinner, almost stationary tearline, sometimes vibrating by only 10 pixel rows instead of all over the screen. Now that's easy to calibrate to right above the top edge of your screen, making tearlines completely disappear. Obviously, your tearline vibration amplitude height should be smaller than VBI height, for this to work -- that's why large VBIs makes this much easier. And lower refresh rates are easier (lower scan rate). And so on.

<Programmer Technical>
The tearline is vibrating because this is a software-based polled raster interrupt emulation (via D3DKMTGetScanLine() raster API), so microsecond imprecisions appear as a vibrating tearline -- a horizontal scanrate of 160KHz means a 1/160000sec delay will move a tearline downwards by 1 pixel. Since it is difficult for a full PC to be microsecond-exact (not realtime OS), you inevitably get a vibrating tearline. It's only recently that GPUs and computers are now powerful enough that that software-based raster synchronization is precise enough to make a software-based QFT mode possible in certain games.

Normally Microsoft VSYNC ON implementation is Present() at beginning of VBI. Quick Frame Transport requires Present() at end of VBI, because that is lower lag to the new refresh cycle. Large Vertical Total increases input lag with default Microsoft implementation, but RTSS Scanline Sync can "fix" that by relocating Present() to end of VBI, reducing lag.

--Lowest lag--
RTSS Scanline Sync QFT + Large Vertical Total
Normal RTSS Scanline Sync
Normal VSYNC ON
Normal VSYNC ON + Large Vertical Total
--Highest lag--

So there liein the rub -- Large Vertical Totals (large VBIs) makes things worse with the default start-of-VBI frame presentation. But relocate the frame presentation to end of VBI, and now you get even BETTER than RTSS Scanline Sync on a non-large-VT signal.
</Programmer Technical>

Even though you're using VSYNC OFF, you're creating a defacto custom "VSYNC ON QFT" mode using RTSS Scanline Sync!

Atta boy, you're getting it now!

Negative numbers are identical to positive numbers in a "Vertical Total MODULUS" manner.
So for a Vertical Total 2500, the use of "2400" and "-100" is identical.

Negative numbers are useful if you keep changing your vertical total all the time, so negative numbers don't require re-tweaking as often as positive numbers.

Trying to use 2600 with a Vertical Total simply moduluses it back, to 100. The refresh cycle is simply an endless loop of a series of refresh cycles, so negative and positive numbers are simply MODULUS vertical total, so you have to think of the RTSS number as a modulus number.

The advantage of using negative numbers, is they are end-of-VBI relative, rather than start-of-VBI relative -- which means you can continue to tweak the size of your VBI without repeatedly re-tuning / re-changing your RTSS negative number.



And loops over and over. A cable is just an endless stream of refresh cycles --
[...]-Sync-BackPorch-Active-FrontPorch-Sync-BackPorch-Active-FrontPorch-[...]

VBI = Sum of Back Porch + Sync + Front Porch seen in ToastyX Custom Resolution Utility or NVIDIA Custom Resolution
Vertical Total = Sum of Active + VBI seen in ToastyX Custom Resolution Utility or NVIDIA Custom Resolution
Vertical Total = Sum of Active + Back Porch + Sync + Front Porch seen in ToastyX Custom Resolution Utility or NVIDIA Custom Resolution

Those porches and syncs are simply paddings/delimeters between pixel rows / refresh cycles "on the wire" when the GPU transmits the refresh cycle (1D serialization of a 2D image) one pixel at a time, left-to-right, top-to-bottom.

Video does this for almost 100 years now, from a 1930s analog TV to a 2020s DisplayPort cable -- we've stuck to the same raster sequence. Yesterday, they were just electric signals to reset CRT cathode ray beam. Today, they're digital sync separators treated like comma delimeters (paddings/hidden offscreen pixels). But the video signal structure has remained unchanged for almost 100 years. It's the same even on a FreeSync signal (the VBI simply varies in size), and at any refresh rate -- it's just simply enforced by the law-of-physics of having to serialize a 2D image over a 1D wire, whether be analog or digital -- as a waveform analog -- or binary digits -- or whatever.



While this is somewhat advanced writing, since most readers just don't know what the hell those numbers in ToastyX or NVIDIA Custom Resolution does -- now the above diagrams hopefully helps educate what the numbers actually does -- the true resolution of a signal is bigger than the resolution of the display -- analog or digital -- thanks to hidden offscreen porch pixels and offscreen sync pixels.

Hope this post provides educational insight to how we've successfully pulled off a successful software-based "Quick Frame Transport VSYNC ON emulation" mode via using raster beam raced RTSS Scanline Sync + Large VBI + VSYNC OFF

Yeah, RTSS Scanline Sync is like an airplane cockpit -- compared to simply using a tricycle or car with plain VSYNC ON and plain VSYNC OFF. This is not necessarily for the faint of heart.

Do this QFT trick ONLY if you're
(A) very familiar with RTSS scanline sync already; and
(B) very familiar with custom resolution utilities
(C) understand the use cases this benefits

A defacto QFT effect is much easier with variable refresh (GSYNC or FreeSync) -- you simply run at max Hz and then cap (e.g. 60fps) to get the natural QFT effect much more easily, such as reducing lag in 60fps games and emulators. So the QFT trick mainly helps non-VRR displays that supports large vertical totals. Or a situation such as motion blur reduction where you cannot use VRR (e.g. QFT + blur reduction).

</Advanced>

 

^ thanks for the information. Not that I understand 100 % of it but can educate myself now more on the topic.

 

@mdrejhon

Hello, you seem extremely knowledgeable on sync methods and display stuff in general, do you perhaps know if there are any hard numbers on button-to-pixel input lag when using scanline sync at the same fps compared to vsync off? say 120 hz 120 fps vsync off vs 120 hz 120 fps vsync off and scanline sync ON ?


at the moment I set my tearline to the bottom of my monitor with scanline sync = 1000 and have not touched anything else in RTSS basically, it works really, really well in the game i'm using it in (fifa 19 in dx11 mode) , also I am using lightboost at the same time on my old asus vg248qe monitor, its extremely smooth and sharp, and if there is any input lag it feels *very* minor, but i'm just curious !


is there any point to mess around with the flush setting or should I just leave it like it is ? I can't see the flush line in the profile cfg file at all, i'm guessing it defaults to "1" and thats the best option for least input lag ?

basically looking for the "optimal" settings to use in combination with scanline sync in terms of least input lag possible, in nvidia CP I set max prerendered frames 1, vsync forced off, and threaded optimization to off but that particular setting might be pointless to change from auto?


appreciate any feedback, cheers!

 

@RealNC

Can you tell me which setup has less input latency:
-Standard Vsync + RTSS 59.94 Framerate limit (on a 59.951hz refresh rate)
or
-Fast Sync + RTSS Scanline Sync = 1
?

 

@tesla2105 Scanline sync probably has a bit lower latency. Although fast sync is most probably interfering with it, so I'm not sure.

 

Please elaborate, how would I know how many scanlines I have? 1920x1080, custom resolution to run at 80Hz:
https://i.imgur.com/LnASilm.png

 

The "1080" in 1920x1080 refers to 1080 visible scanlines. A scanline is a row of pixels, at 1080p you have 1080 of them. There's some invisible ones as well, sort of "below" the screen (used for timing purposes,) but how many of those you have doesn't matter. The 1080th scanline is the last visible one, so if the tearing happens after it, it won't be visible. The driver cannot sync immediately to the scanline you specify. There's some lag. So that's why you target a scanline that's further up the screen.

 

I understand. I'm just trying to understand where are these magic numbers came from. Like -50. -60? Why such big negatives? If I have 1080 scanlines, why just -1 isnt enough to put it off-screen?

 

Because there's some lag between RTSS requesting a new frame and the driver/GPU actually delivering the new frame. The lag can be 50 scanlines or 100 scanlines or somewhere around that. Depends on the game and GPU load. So you need to target an earlier scanline than the one you actually want.

 

How does scanline sync 1 with negative offset affects input lag?

 

What do you mean?

 

So is there any way to get S-sync work properly with DSR/VSR/Downsampled custom resolution?


It's definitely different from GeDoSaTo but in the end, the GPU does scale the resolution back to monitors native res. So the off screen pixels are still there. However, it's still possible to move the tearline to top part of the screen and then it becomes less botherable. It's quite acceptable that way.



The main problem with downsampled resolution at the moment is that the frame rate will get locked to half of the refresh rate. On most games, just alt tabbing fixes this issue. On other games, switching to window mode and then switching back to fullscreen will fix that issue. But on some games you can't switch to window mode and on some games alt-tabbing crashes/freezes the game. So are there any plans to fix the half framerate issue? Or is there any way to solve this problem?

 

For the half refreshrate issue, it also helps to change the resolution from the downsampled one back to native, and then change it back again. This is not a fix, however - more of a workaround.

 

Yeah that will work too.


Some games are just pure evil though. Those only allow changing resolution from launcher.

 

Sorry to bring this up after all this time, but could you go further into why setting scanline sync to the first scanline "1" then enabling Fast Sync works differently than simply enabling Fast Sync?

Thanks! I've been re-reading this thread and I'm a bit confused on that front. Much appreciated! Sorry to bother you again,

 

What you're asking is what's the difference between FPS cap (s-sync enabled) and no FPS cap (s-sync disabled.) If you don't want an FPS cap, don't use s-sync. If you want an FPS cap that caps exactly to your refresh rate, use s-sync.

Fast sync itself will cap FPS of course as well, but it will always cap to a multiple of your refresh rate if it can.