Before reading this post, you need to understand Quick Frame Transport
See FAQ: Understanding HDMI Quick Frame Transport (lower lag)
crossjeremiah wrote:*UPDATE*
So I'm adjusting the tearline. When I have the tearline up on the top of screen fps drops to 40. game is unplayble input lag noticeably increased.When I adjust to the very bottom of screen, I dont know if I can tell difference in input lag at all, or is that not where the reduction happens. Do I have to put extreme values in because of VT2810 like 2000 ? Or can I input a higher value so the tear line can loop back to the top of screen?
(1) This will mainly reliably work with VSYNC OFF method, as VSYNC ON will interfere with frame presentation timing
(2) You have to move tearline high enough ABOVE the top of the screen (negative indexes) high enough so the entire jitter amplitude of the tearline is completely above the top edge of the screen. You'll know when stutters suddenly disappear once you've moved the tearline high enough far above beyond the top edge of the screen.
crossjeremiah wrote:*UPDATE 2*
I played this morning
https://www.twitch.tv/videos/453990029 . the glassfloor was perfect, no fps drops, I used a Scanline Sync 1050 , that was closest to the bottom i could get. Is there way I can move the tearline to the top to get the reduced input lag, I tried 0-400 and 400 is literally the middle of the screen
Buddy, buddy, buddy, buddy, that won't work.
You
MUST use negative numbers. The tearline must jitter ABOVE the top edge of your screen.
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.
</Programmer Technical>
Even though you're using VSYNC OFF, you're creating a defacto custom "VSYNC ON QFT" mode using RTSS Scanline Sync!
crossjeremiah wrote:*UPDATE 7*
I think I got it.
Scanline Sync 2200 value. Which is above the top edge I presume, I couldn't really tell. But I saw the graph perfect saw tooth for a couple cycles and the perfect glass floor was back. The input lag seems reduced, because the advanced tech I usually do on a crt (1-frame window) was easy to execute when the value was put in.
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.
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