VRR...move tearline possible?

[chenifa]

hi

Would it be possible to tweak VRR in a way that we can move the tearline to any position?
I'm thinking something like scanline sync but instead of the frame waiting for the right scanline, vrr waits at the right scanline for the frame to finish rendering...
While it would tear, this would be neat for input latency (if we start scan out of a frame closer to the middle where crosshair is)

[Chief Blur Buster]

hi
Would it be possible to tweak VRR in a way that we can move the tearline to any position?
I'm thinking something like scanline sync but instead of the frame waiting for the right scanline, vrr waits at the right scanline for the frame to finish rendering...
While it would tear, this would be neat for input latency (if we start scan out of a frame closer to the middle where crosshair is)

Not worth it -- since eliminating tearlines mandatorily requires a cap anyway. Tearline control is achieved by intentional delay methods, to steer the tearline to the correct raster position (in scanout), to "splice" in the new frame at the right point of the signal's scanout.

If you hate VRR+VSYNC ON, try using VRR+VSYNC OFF with the double-cap method, frame rate ~4% below Hz in-game, and framerate ~3% below Hz below in RTSS. The in-game cap will be the latency guard cap, and the RTSS cap will be the tearing-preventer cap. In-game caps are better for lag reduction but can be more jittery for tearing.

[chenifa]

Not worth it -- since eliminating tearlines mandatorily requires a cap anyway. Tearline control is achieved by intentional delay methods, to steer the tearline to the correct raster position (in scanout), to "splice" in the new frame at the right point of the signal's scanout.

But can we steer the tearline at all?
VRR waits for the next frame at a certain raster position(vbi), can we change that position?

[Chief Blur Buster]

But can we steer the tearline at all?
VRR waits for the next frame at a certain raster position(vbi), can we change that position?

Yes. But very few software does this. WinUAE lagless vsync works with GSYNC+VSYNC OFF for precise lagless VSYNC with VRR enabled.

Prerequisite Knowledge: Computer Programmer

The trick is you have to be a computer programmer that understands how VRR works behind the scene;

1. In VRR, scanout is always paused at top edge between refresh cycles (it's looping on back porch scanlines until computer starts displaying the first pixel row of visible refresh cycle frame)
2. You must cause the display to start the scanout by the FIRST call to Present() or glxxSwapBuffers() or whatever frame present API you use;
3. The scanout starts at a constant speed matching horizontal scanrate in the EDID. You can interrupt tearlines (ala Tearline Jedi) thereafter, by Present() precise time offset after the first Present() to control tearline position.

Here's a time-based diagram of using microsecond-precise Present() for tearline control during VRR:
Study prerequisites:
1. Understand the display scanout at www.blurbusters.com/scanout where displays refresh one pixel row at a time;
2. Understand how VRR works via programming API;
3. Understand the video signal structure;
4. Understand non-VRR tearline control; RTSS Scanline Sync does this.
5. Then you finally can understand the diagram below, and become a Tearline Jedi during VRR mode.



But because of item (1), tearline control is not useful for most purposes during VRR=ON, and has no usefulness/applications for typical FPS esports apps (Counterstrike etc), because a full frame depends on the first Present(), and the display is essentially in a paused state during that time during VRR whenever in VRR range (and no refresh cycle is in progress).

[chenifa]

Thank you Chief, I appreciate your detailed response!

2. You must cause the display to start the scanout by the FIRST call to Present() or glxxSwapBuffers() or whatever frame present API you use

Dx11 is what I'm a little familiar with. In that case isn't the first present call way before the gpu has finished rendering the frame?
I imagine the scanout would be looping on the back porch scanline until the gpu is finished rendering?

no usefulness/applications for typical FPS esports apps (Counterstrike etc), because a full frame depends on the first Present(), and the display is essentially in a paused state during that time during VRR whenever in VRR range (and no refresh cycle is in progress).

Ok but the "paused state" doesn't cost latency, since there is no new frame waiting during that pause.
And if we move the location of that pause from the top edge, downward to a row slightly above the crosshair, we get latency benfits.
OFC we would get a tearline but latency would be as consistent as regular VRR and lower for the important area(crosshair)

[Chief Blur Buster]

Dx11 is what I'm a little familiar with. In that case isn't the first present call way before the gpu has finished rendering the frame?
I imagine the scanout would be looping on the back porch scanline until the gpu is finished rendering?

The Present() does accelerate the rendering, so usually it finishes rendering within 1ms of Present(). If you want to make it deterministic, use Flush() right after Present(), that's what I used for more precise tearline steering.

Ok but the "paused state" doesn't cost latency, since there is no new frame waiting during that pause.

Correct, but:

And if we move the location of that pause from the top edge, downward to a row slightly above the crosshair, we get latency benfits.
OFC we would get a tearline but latency would be as consistent as regular VRR and lower for the important area(crosshair)

It's impossible. No displays function like this. ALL of them ALWAYS start scanout at one edge.

That's why there's generally no usefulness to tearline control during VRR use.

During VRR=OFF, RTSS Scanline Sync can sort of do what you want because the scanout of the previous frame has already started, and you're splicing the new frame mid-scanout. But with VRR=ON, VRR avoids tearing by intentionally not scanning out a previous frame.

Now, Scanline Sync requires busylooping to steer the tearline (adds lag), so you've got a lag cost of tearline steering unless you've custom-modified the game to do correct inputdelay behaviors. RTSS Scanline Sync can steer tearlines at a lower lag cost than normal VSYNC ON, but pure VRR (without tearling steering) is usually lower lag than using tearline steering techniques (RTSS Scanline Sync or Special K Latent Sync).

VRR is the world's lowest-lag "not VSYNC OFF" sync technology, so combining the two is generally counterintuitive for non-beamraced applications.

[chenifa]

It's impossible. No displays function like this. ALL of them ALWAYS start scanout at one edge.

gotcha

The Present() does accelerate the rendering, so usually it finishes rendering within 1ms of Present(). If you want to make it deterministic, use Flush() right after Present(), that's what I used for more precise tearline steering.

I think you talking about specific scenario where you use a framelimiter right?
Bc without a framelimiter Present is called when the cpu finishes the frame(assuming cpu limited scenario) and then it takes as much time as the gpu needs to render.
There is a stat in presentmon "msuntildisplayed" which is time from present to frame complete and it can be up to 4ms at 240 fps...

VRR is the world's lowest-lag "not VSYNC OFF" sync technology

Do you know how long it takes between the gpu finishing render and the first real visible line of pixels being scanned out? Is it just the time it takes to send the line over the cable or is there more latency added from vrr?

Another question I had....while I want to use VRR my biggest problem is it changes my monitors overdrive(benq xl2540)....it sets it to 28 and when I try to change it manually in the service menu it just falls back to 28...is there any fix for this?

[Chief Blur Buster]

Do you know how long it takes between the gpu finishing render and the first real visible line of pixels being scanned out? Is it just the time it takes to send the line over the cable or is there more latency added from vrr?

Most of the time (at least with G-SYNC native), there is no added latency for VRR except the scanout (that VSYNC OFF bypasses).

Within VRR range, Present() VRR scanline #1 is usually same latency as the first pixel row underneath a VSYNC OFF tearline (whatever position the scanout is currently at). The render latency in both situations is identical, it's just a matter of mandatorily starting the latency stopwatch at top edge (for VRR), where VSYNC OFF allows you to start the latency stopwatch at any position in scanout (at the cost of tearline).

Latency gradient during VRR: Pixel row #1 is lowest lag (Zero basis), and increases to the bottom of the screen.

Latency gradient during VSYNC OFF: Pixel row underneath tearline is lowest lag (Zero basis) and increases to the next tearline (including wraparound to next refresh cycle).

So the zone between two tearlines are individual latency gradients.

Now, that said, monitors and drivers vary a bit. There can be some overheads (on some displays and some driver technologies, like generic FreeSync displays) of just merely starting to scan out. But on many esports display, the latency of the zero-basis scanline is identical for VRR and VSYNC OFF -- it's just that the zero-basis scanline is far away from crosshairs (screen center) when it comes to VRR, which means you've got a necessary increasing-latency gradient from top edge of screen towards bottom edge. But at 360Hz, your VRR-penalty for crosshairs latency is as low as 0.5/360sec, but you've got near-zero latency volatility unlike for VSYNC OFF (where VSYNC OFF can jitter in latency from [0....1/360sec] because of random positions of tearlines). It's a lagfeel tradeoff, and different people prefer different.

But one thing for sure, scanouts are getting faster. Yesterday, we had 1/60sec=16.7ms lag difference between top/bottom edge. Today we have 500Hz, so that's 1/500sec=2ms lag difference between top/bottom edge. That means during VRR on a 500Hz display, your VRR lag penalty is only 1ms, but you've also (hopefully) concurrently eliminated jitter/stutter/lag variances. So you've traded off a [0..2ms] latency variance during VSYNC OFF for a constant +1ms latency offset during VRR, since you've locked your zero-basis latency scanline position by virtue of VRR, with zero busywaiting needed (like software based Scanline Sync technologies requires)

In both cases, latency of rendering is the same, so we ignore that difference. And then, latency of VSYNC OFF and VRR is the same for their specific zero-basis scanlines.

However, reviewers usually standardize their photodiode tester position (e.g. screen center), so they don't make this observation.

Not all pixels have the same latency, so you get different lag numbers from different websites, and/or from different sync technologies. Even the decision where in the GtG curve to stop the lag stopwatch at (GtG2%? GtG10%? GtG50%? GtG100%?), can affect lag results, and the differences in VRR overdrive on/off can affect the lag results synthetically. (NVIDIA's G-SYNC premium is very good here when you want the cleanest, most consistent, and fastest VRR overdrive).

If you use VRR in esports, the moral of the story is to:
(A) Purchase more VRR range than you need, so your framerate range is completely within VRR range without worrying about the capping compromises; and
(B) Don't worry about VSYNC ON nor VSYNC OFF, since your framerate stays within VRR range and never activates the fallback sync technology.
(C) Get good overdrive. In this case, sometimes the G-SYNC premium can be helpful, or one of the much better FreeSync implementations, or using OLED VRR, etc.

So that means a 360Hz+ LCD may be preferred by those who insist on using VRR during esports; to avoid the problems of capping, or the lagfeel changes of enter/exit VRR ranges.

I am currently pretty excited about upcoming 360-480Hz OLED monitors too -- compromises-free esports-quality VRR.

[Gamesager]

Latency gradient during VRR: Pixel row #1 is lowest lag (Zero basis), and increases to the bottom of the screen.

I’ve read so many threads and post here to learn a lot of this stuff. And this might be what I was looking for finally.
Halo infinite stutters no matter what if you frame cap with vrr, (every single cap I know of) and every time it causes a tear with vsync off, and a hitch with vsync on.
Do you think using scanline sync set to 1 can finally fix this? I am going to try it when I am home.