Page 8 of 18

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

Posted: 28 Nov 2018, 09:06
by LagBuster
Chief Blur Buster wrote:What is your refresh rate? From the numbers, it implies you're running at 75Hz because you're setting two scanlines to allow 150 frames per second, correct?

But if you're trying twice the framerate as refreshrate, your goal is 2 x 75Hz = 150fps, correct? I don't think you're using 50Hz (2 x 50Hz = 100fps)
Yes, I'm using 75 Hz and my intention is to use the "fast sync" or 2x refresh rate configuration, since my PC does an average of 230 fps in the most intensive multiplayer scenario and if I cap it at 150 fps with fps_max I get tearing.

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

Posted: 30 Nov 2018, 18:25
by Chief Blur Buster
For users who want to combine RTSS Scan Line Sync with VSYNC ON / Fast Sync / Enhanced Sync

Modified from my original Guru3D post, since this is useful for Blur Busters readers looking for fine-tuning Scan Line Sync.

This can produce a massively superior "Low-Lag VSYNC ON" mode that is low-lag, tear-free, and zero-stutter provided you're playing games that tend to play framerates above refreshrates in VSYNC OFF. Such games that like to permanently stay above refresh rate, are the easiest ones to create this new "Low-Lag VSYNC ON" mode.

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).

The ideal calibration will vary from game to game. If you need a universal calibration, have a generous offset (e.g. 25% earlier). That said, 25% earlier means 1/4th more frame lag (e.g. 4ms lag at 60Hz) but it can be pretty much is solid in most games. The bigger the safety margin, the less likely you get lag spikes.

A perfect 18-20ms lag glassfloor is always better than 16.7ms with lots of 33ms spikes. So raise the tearline further above bottom edge. Remember that screenheight is lag; 1/4th screen height above bottom edge is 1/4th refresh cycle extra lag added, but that absorbs a hell of a lot of VSYNC OFF tearline vibrations (vibrations = frame timing error. microseconds become human visible -- at 100KHz scanrate, 10 microseconds means tearline moves downwards by 1 pixel. That's why tearline vibrations are so amazing to watch, it's microseconds becoming human visible!)

You can use large positive scanline offsets but negative scanline offsets are vertical-resolution-independent (and more friendly to lag-reduction tricks via Large Vertical Totals / Quick Frame Transport (QFT) tricks).

That's how you can get low-lag perfect refresh-rate-synchronized Fast Sync -- keeping tearline above bottom edge of screen.

Strafe left/right in a game with vertical wall edges, to look for tearline positions. Use the RTSS hotkeys to calibrate tearline position.

Calibration & Tuning Mantra: Always calibrate RTSS Scanline Sync using VSYNC OFF first before turning VSYNC ON / Enhanced Sync / NVIDIA Fast Sync!
The tearline position is a wonderfully excellent visual calibration indicator.

Combining RTSS ScanLine Sync with your preferred sync mode:
VSYNC OFF: Calibrate tearline offscreen
VSYNC ON: Calibrate tearline to stay permanently above bottom edge
Fast Sync: Calibrate tearline to stay permanently above bottom edge
Enhanced Sync: Calibrate tearline to stay permanently above bottom edge
Once you finish calibrating, switch to your preferred sync mode.

Tearline vibrates too much? (e.g. 1/4th screen height vibrations or worse)? Move the tearline onscreen and work hard to calm down your tearline first! Temporarily ignore the lag during this calibration stage, and focus on calming down the tearline first. Try increasing SyncFlush numbers by 1. Use SyncFlush 1. Also, lower refresh rates produce calmer tearlines. And lower CPU%, lower GPU% utilization will produce calmer tearlines too. Turning off certain features like AA will also produce calmer tearlines. If you are running very old games that always stay well below GPU 50%, try SyncFlush 2 as that produces very tranquil & calm tearlines. (Don't worry, the crazy increase in GPU% will be more than compensated by the complete lack of lag spikes; keep reading. That shiny glass floor lag beckons!). Remember, the calmer the tearline, the more likely it stays permanently near one location. Fiddle until you see your tearline calm down (vibrating consistently in a reasonably tight vertical space rather than all over the vertical dimension of the screen). The calmer the tearline, the more likely it stays permanently away from the bottom edge of screen. Thereby avoiding lag spikes if using another sync mode than VSYNC OFF. Tearlines that dips below bottom edge of screen exactly equals a latency spike if you were running FastSync instead of VSYNC OFF.

Framerates often below Hz: If your game cannot sustain framerate equal refresh rate, you WILL get lag spikes (with accompanying microstutter), no matter what. So lower your refresh rate and/or upgrade your GPU and/or adjust game detail and/or reduce AA.

Occasional framerate dips: In practice, it is okay if there's occasional framerate dips -- such as disk access -- e.g. you're able to sustain full framerate matching refresh rate 90%+ to 95%+ of the time, so just aim for the 90th or 95th percentile of permanence. For emulators or older games, it's easy to aim at the 99th+ percentile though, but for newer games, just merely getting 90th percentile can sometimes be hard. A stutter will be a visual indicator of a lag spike, so if you're getting stutters during competitive-critical gameplay, then you definitely want to calibrate for framerate permanence above that, to improve aiming during critical heated moments. You might not be able to do anything about those disk access stutters, but at least you've calibrated for your critical moments.

Extra safety margin: For all of modes other than VSYNC OFF -- I recommend moving the tearline least 1/10th screen height above the bottommost visible tearline (where the tearline vibrates downwards to). Basically you should have a 1/10th area above bottom edge of screen that you've never seen the tearline vibrate downwards to. This gives you "padding". This adds 1/10th refresh cycle extra lag (~1.6ms at 60Hz) but will eliminate your lag spikes during Fast Sync, etc. If you're trying to synchronize at 120Hz or 144Hz, try 1/5th screen height of padding above bottom edge of screen.

--easy stuff ends--
This ends the easy stuff above. Now for the more advanced (engineering-esqe) stuff below:
--hard stuff begins--

What about SyncScanLine1?:
- If unfamiliar with this, keep SyncScanLine1 setting to 0. Worry only about one tearline (SyncScanLine0 or via GUI)
- Even if you do this, please do the easy stuff first before attempting this

If your game is ultra-low GPU (e.g. Quake Live or CS:GO) combined with motion blur reduction, this can reduce strobe lag a further (e.g. 240fps at 120Hz, or 200fps at 100Hz). First, calibrate using VSYNC OFF. You may use two tearlines with Enhanced Sync or Fast Sync -- but not with VSYNC ON (that will frame-throttle you badly). Calibrate the middle tearline to middle of screen (slightly above middle is ideal, to keep it equidistant with the bottommost tearline, but position of middle tearline matters less than the bottommost tearline) but focus on carefully calibrating the bottommost tearline to stay permanently above bottom edge of screen. Ideally, they should be signal-equidistant from each other (half Vertical Total apart, taking into account of VBI versus visible vertical resolution). But this is less critical than keeping the bottommost tearline permanently above bottom edge of screen, in order to avoid those lag spikes during Fast Sync and Enhanced Sync.

Advanced-User Large blanking interval trick for DIY Quick Frame Transport (QFT):
- Do not bother with below trick doing this unless you're a CRU Wizard.
- Do not bother with below trick unless you know your monitor supports ultralarge blanking intervals larger than the vertical resolution, such as "Vertical Total 2200" for 1080p.
- Do not bother with below trick if you don't understand "Vertical Total" or "Front Porch" or "Back Porch" or "Horizontal Scan Rate".
- QFT behavior is already built into VRR, so use VRR instead. It's easier to use GSYNC or FreeSync as a much easier QFT method (e.g. 60fps cap at 240Hz) since the VRR provides a very easy natural QFT mechanism. That's why lag is very low on GSYNC/FreeSync since all refresh cycles (no matter the current Hz=fps) are always delivered at max-Hz velocity.

Very few monitors support large VBIs at their maximum non-VRR refresh rate. However, a few of them do -- e.g. delivering a 60Hz refresh cycle in 1/120sec on a monitor that doesn't support 120Hz. (This is rare, but occasionally happens). Alternatively, if you're using large blanking intervals to reduce strobe crosstalk (squeezing LCD GtG into VBI to reduce artifacts with a blur reduction backlight) -- then it may be more favourable to use VSYNC OFF and adjust scan line sync late into VBI. This creates a "Quick Frame Transport" effect. Normally, Microsoft and graphics drivers does frame presentation at end of refresh cycle (bottom edge of screen), rather than beginning of refresh cycle (top edge of screen). By delaying input reads-render-present late into a superlarge VBI, via RTSS scanline frame rate capping late into VBI (small negative offsets), one can reduce lag further thanks to the Quick Frame Transport effect of the use of an ultralarge blanking interval (Example: 60Hz refresh cycles transmitted over the cable in 1/120sec via the use of an ultralarge VBI the same size of the visible image). Quick Frame Transport (QFT) is part of the HDMI 2.1 specification but is possible to DIY on any cable with Custom Resolution + Large VBI + RTSS scanline sync. Displays that are intentionally designed to support QFT works best with this trick, but I've run into some displays that have undocumented QFT capability on one of its inputs, e.g. certain 60Hz HDTVs that supports 120Hz input but the panel can't support 120Hz. (Basically frameskips, as in only displays 60 frames out of 120 per second); those displays can often be tricked into a QFT 60Hz signal (via ultralarge VBI -- maintaining same exact 135KHz horizontal scanrate but halving the vertical refresh rate from 120Hz to 60Hz) -- that speeds up delivery of 60Hz refresh cycles to 1/120sec -- reducing frame delivery latency by 8ms. If you shift your inputread-render-deliver pipeline to align with the frame transmission (presenting framebuffer very late in VBI, right on time for visible frame transmission), that reduces the input lag of VSYNC ON / Fast Sync / Enhanced Sync by 8ms without raising refresh rate on displays that supports a 2x QFT acceleration factor (documented or undocumented). First, play with custom resolutions until you've got the biggest supernova-sized galactic-sized blanking interval your monitor will sync to -- a blanking interval big enough to drive a battlecruiser through. Next, start your game, make sure it's correctly using that hacked custom frankenstein signal timings & resolution you created, THEN finally calibrate RTSS until your tearline shows up near top edge of screen, THEN calibrate it until it barely disappears above top edge. Now you've created a fixed-Hz QFT sync mode!

(Hmmm. It appears I wrote a mini-guide. Maybe I'll copy and paste into the Blur Busters article, but I'm still recruiting assistance on writing a ScanLine Sync HOWTO (graphics, expanded article, etc) since I'm spread between so many things)

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

Posted: 02 Dec 2018, 01:00
by LagBuster
Well, I've been using SyncScanLine0 without VSYNC and I love it. Well worth it to sacrifice a few frames for this level of consistency. The only thing that would make it better would be better hardware, but that goes without saying.

Anyway, imo this is revolutionary.

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

Posted: 07 Dec 2018, 15:32
by Chief Blur Buster
You're welcome!

It was my suggestion to the RTSS authors, and this advice came from my Tearline Jedi research. Combining raster knowledge and tearline knowledges ("VSYNC OFF tearlines are just rasters") was what made this new RTSS scanline sync possible.

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

Posted: 08 Dec 2018, 04:27
by Vega
Wonder if this is even worth messing around with on my 120 Hz 4K Mango that basically has my 2080 Ti maxed out. Or just stick with the -.007ms frame cap V-Sync on RTSS method. It seems to be working pretty good.

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

Posted: 08 Dec 2018, 22:07
by andrelip
Thanks for the suggestion. This feature is amazing!

Some questions:

1) I', putting the scanline at a given height above the aim. Do that mean that I'm receiving the lowest input lag possible in that region due to the scanline gradient? Do that region have a lower latency probability at a moderate frequency (180hz por example) than if I had unlocked fps at my 240hz display (reaching 250~300 fps)? My theory is that having the scanline perfectly placed at a slightly lower frequency should win most of the times against the random gradient of a higher rate in the specific region.

2) On my Alienware AW2518HF (240 hz) I could set my 1280x960@200hz to use a total height based on 360hz pixel clock. It has no frameskip but in another post you said that most of the 240hz monitors use buffers to send at 240hz speed. How can I know if that is the case here?

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

Posted: 08 Dec 2018, 23:50
by Chief Blur Buster
andrelip wrote:Thanks for the suggestion. This feature is amazing!
1) I'm, putting the scanline at a given height above the aim. Do that mean that I'm receiving the lowest input lag possible in that region due to the scanline gradient?
<Expert User Tweaking Only>
Yes, frameslices are a latency gradient with the lowest lag at the top edge of frameslice (right above all tearlines). So you made an excellent call putting the crosshairs near the top edge of your frameslice.

If you have enough framerate overhead, try double framerate with both SyncScanline0 and SyncScanline1 .... One of them aligned between refresh cycles and the other one of them right above your crosshairs.
andrelip wrote:Do that region have a lower latency probability at a moderate frequency (180hz por example) than if I had unlocked fps at my 240hz display (reaching 250~300 fps)? My theory is that having the scanline perfectly placed at a slightly lower frequency should win most of the times against the random gradient of a higher rate in the specific region.
There's a small frame-capping overhead inherent in RTSS. So it may be lag-neutral compared to VSYNC OFF in the best case scenario. I think it approximately cancels each other out. However, the improved fluidity can improve aiming anyway. You have to give it a try and see if it helps!

Simply using framerate-capped FreeSync (e.g. ~237fps at 240Hz) is a lot easier than using RTSS scanline sync, but give both a try and see how the latency-feel works for you.
andrelip wrote:2) On my Alienware AW2518HF (240 hz) I could set my 1280x960@200hz to use a total height based on 360hz pixel clock. It has no frameskip but in another post you said that most of the 240hz monitors use buffers to send at 240hz speed. How can I know if that is the case here?
It is very model-dependent. But if you worry about this, you can simply use large vertical totals (large blanking intervals) to deliver your 200Hz refresh cycles in 1/240sec. If you transmit your scanlines at max pixel clock (max scanrate) the 240Hz FreeSync monitors tends to skips pre-buffering pixel rows. The buffering necessarily occurs only if pixel rows are raster-scanned-out over the video cable (DisplayPort, HDMI, whatever) slower than the monitor's motherboard is refreshing-out to the LCD. So it has to pre-buffer enough pixel rows before it flushes out to a full-240Hz-velocity scanout of the panel. (That's why most 2017-era and 2018-era 240Hz monitors are bad for 60Hz console gaming at the moment) All gaming LCD displays use a top-to-bottom refreshing sequence (as seen high speed videos on Blur Busters). So if your video cable scanout velocity (Horizontal Scanrate in Custom Resolution) is the same as 240Hz, then it's pretty much in sync with the LCD panel scanout.

Just max-out your pixel clock and use the same Horizontal Scanrate of your 240Hz mode, and any lower-Hz PC mode (with Large Vertical Total) just behaves as a "Quick Frame Transport" mode. All refresh cycles would scanout in 1/240sec (4.16ms).

Remember when doing Custom Resolution tweaking (NVIDIA Custom Resolution)
1. Display your 240Hz mode
2. Write down all Horizontal numbers (Front Porch, Sync, Back Porch, Total, Scanrate)
3. Write down all Vertical numbers
4. Write down your Pixel Clock number.

Now, when creating a new lower-Hz custom resolution that becomes a Quick Frame Transport mode (Might not be better than 240Hz frame-capped FreeSync, but you can give it a spin), you have to:
1. Use "Manual" for custom resolution
2. Preserve all horizontal numbers _exactly_
3. Preserve all your vertical numbers except Back Porch and Vertical Total (if you don't have a Back Porch number, don't worry -- it's embedded in Vertical Total)
4. Preserve your dotclock
5. As you lower your refresh rate, increase your Vertical Total.

For example, if you're using VT1152 at 240Hz, then you need to exactly double the VT for exactly half Hz -- VT2304 for 120Hz (for 2x QFT acceleration factor). Or exactly quadruple, VT4608 for exactly one-quarter Hz, ala 60Hz (4x QFT acceleration factor).

Remember...get exactly the same Horizontal Total, same Horizontal Scanrate, and Same Pixel Clock -- the number must be exactly the same as a FreeSync-enabled 240Hz mode even if you are disabling FreeSync. FreeSync works via variable-size vertical totals to space out refresh intervals, so you're piggybacking on that native capability to achieve fixed-hz Quick Frame Transport (QFT) for lower refresh rates, for the use cases that you don't want VRR for.

If your monitor supports large vertical totals at 240Hz, you might get up to a 5x QFT acceleration factor for 60Hz (60Hz refresh cycles transmitting over the cable in only 3.5 milliseconds!) before you start hitting DisplayPort speed limitations.
</Expert User Tweaking Only>

If you do any of the above and get any significant improvements in lagfeel, please post. I'm interested in your experiences.

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

Posted: 10 Dec 2018, 13:25
by andrelip
Chief

Thanks for the explanation!

I did exactly that using CRU and I was able to achieve up to 1/360 using a lower resolution (capped by HDMI 2.0) for both 200hz and 120hz with no frame-skip (my max totals for 1024 x 768 120hz is 2349). But my monitor have native frequency of 240hz. Should I assume that the monitor is really delivering at a faster scanout cycle then the one used at the native resolution@frequency or maybe there are some transport protocol trick to delivery that at 1/240?

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

Posted: 10 Dec 2018, 13:52
by Chief Blur Buster
andrelip wrote:I did exactly that using CRU and I was able to achieve up to 1/360 using a lower resolution (capped by HDMI 2.0) for both 200hz and 120hz with no frame-skip (my max totals for 1024 x 768 120hz is 2349). But my monitor have native frequency of 240hz. Should I assume that the monitor is really delivering at a faster scanout cycle then the one used at the native resolution@frequency or maybe there are some transport protocol trick to delivery that at 1/240?
1/360 second frame transport! That's a refresh cycle delivered in 2.8 milliseconds over the HDMI cable!

So you just essentially did QFT on HDMI 2.0 -- so you pulled a "feature" on HDMI 2.1 back to HDMI 2.0. ;)

Now, getting Windows to reap the lag-saving benefits of QFT in VSYNC ON mode (or Fast Sync / Enhanced Sync) requires the use of RTSS scanline sync (late-VBI framebuffer flip). There's no lag benefits of QFT on Windows systems until you use RTSS, since frame presentation (example: Direct3D Present() API) is aligned to the bottom of refresh cycles, not the top of refresh cycles.

For 1/360sec .... I suspect the monitor may be buffering the refresh cycle while beginning the 1/240sec scanout. So you may not get any lag benefits if your bottleneck is the monitor is buffering for a slower panel scanout. (Much like 60Hz is buffered on many 240Hz monitors, some monitors may buffer the 1/360sec delivered frame and scan out in 1/240sec).

Once frame transport becomes faster than panel scanout, there's no further lag benefit (button-to-pixels). Thanks to LG 240Hz monitors getting less strobe crosstalk during large vertical totals (1/280sec frame transport), I suspect some 240Hz monitors can scan a little bit faster even if it cannot begin a new refresh cycle.

Also, don't forget monitor scaling lag. I don't know if it applies here. Although scaling can be done virtually laglessly (line buffered scaling), hopefully your monitor scaling isn't adding lag. Testing will be needed with a high speed camera.

Indeed -- cable scanout velocity and panel scanout velocity is often different. So we're not sure if 1/360sec QFT has any benefits (yet)

If Cable scanout > panel scanout -- then monitor has to buffer. It can begin the refresh cycle, but the buffer will build even while the monitor is beginning scanout already. Most gaming monitors won't wait for a full frame buffer -- as long as there's enough data to begin the refresh cycle, the gaming monitor generally will. In that situation, 1/360sec frame transport has the same input lag as 1/240sec frame transport (the amount of time to transmit the Vertical Active resolution at the configured increased Horizontal Scanrate, via the use of large vertical total) if the panel is fixed at 1/240sec. So delivering a frame too fast to the monitor is usually harmless as long as the buffer logic in the monitor is properly implemented.

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

Posted: 10 Dec 2018, 13:59
by Chief Blur Buster
andrelip wrote:I did exactly that using CRU and I was able to achieve up to 1/360 using a lower resolution (capped by HDMI 2.0) for both 200hz and 120hz with no frame-skip (my max totals for 1024 x 768 120hz is 2349). But my monitor have native frequency of 240hz. Should I assume that the monitor is really delivering at a faster scanout cycle then the one used at the native resolution@frequency or maybe there are some transport protocol trick to delivery that at 1/240?
1/360 second frame transport! That's a refresh cycle delivered in 2.8 milliseconds over the HDMI cable!

So you just essentially did QFT on HDMI 2.0 -- so you pulled a "feature" on HDMI 2.1 back to HDMI 2.0. ;)

Now, getting Windows to reap the lag-saving benefits of Quick Frame Transport (QFT) in VSYNC ON mode (or Fast Sync / Enhanced Sync) requires the use of RTSS scanline sync (late-VBI framebuffer flip). There's no lag benefits of QFT on Windows systems until you use RTSS, since frame presentation (example: Direct3D Present() API) is aligned to the bottom of refresh cycles, not the top of refresh cycles. Once you do the RTSS trick, then you know you're getting an even-lower-lag VSYNC ON mode -- even less lag than my HOWTO!

For 1/360sec .... I suspect the monitor may be buffering the refresh cycle while beginning the 1/240sec scanout. So you may not get any lag benefits if your bottleneck is the monitor is buffering for a slower panel scanout. (Much like 60Hz is buffered on many 240Hz monitors, some monitors may buffer the 1/360sec delivered frame and scan out in 1/240sec).

Once frame transport becomes faster than panel scanout, there's no further lag benefit (button-to-pixels). Thanks to LG 240Hz monitors getting less strobe crosstalk during large vertical totals (1/280sec frame transport), I suspect some 240Hz monitors can scan a little bit faster even if it cannot begin a new refresh cycle.

Also, don't forget monitor scaling lag. I don't know if it applies here. Although scaling can be done virtually laglessly (line buffered scaling), hopefully your monitor scaling isn't adding lag. Testing will be needed with a high speed camera.

Indeed -- cable scanout velocity and panel scanout velocity is often different. So we're not sure if 1/360sec QFT has any benefits (yet)

If Cable scanout > panel scanout -- then monitor has to buffer. It can begin the refresh cycle, but the buffer will build even while the monitor is beginning scanout already. Most gaming monitors won't wait for a full frame buffer -- as long as there's enough data to begin the refresh cycle, the gaming monitor generally will. In that situation, 1/360sec frame transport has the same input lag as 1/240sec frame transport (the amount of time to transmit the Vertical Active resolution at the configured increased Horizontal Scanrate, via the use of large vertical total) if the panel is fixed at 1/240sec. So delivering a frame too fast to the monitor is usually harmless as long as the buffer logic in the monitor is properly implemented.