LVT reduces strobe cross talk but same latency in overlay

[Kuscheln_Hammer92]

I have been pouring so much time and many hours into this. I hope it isn't because I'm using DP rather than hdmi. I own an xg2431 paired with an rx 6600. I've created crt motion clarity with the instructions for a lvt with purexp+ adjustments. However, everywhere I read I should expect to see frametime regularly under 16.7ms. I am trying to pair this with RTSS Scanline Sync which I think I finally have nailed. It required me turning on the framelimiter to match hz in the setup. I could not get the tear line to stop moving across the screen without that selected. Is that the minimum frametime I should expect to see despite the LVT? I apologize this is at 60hz custom resolution with a 4500 LVT. I tried basing off of 239.9.. native and then make lvt 2600ish via the vertical calculator but that led to a black screen and obscenely large back porch. Lowering to 4500 allowed the screen to display for me. I would appreciate any and all assistance. Trust me, I have spent at least 18 hours on the topic of both backlight strobing and low latency syncs.

[RealNC]

Frame time is not affected by LVT. Display scanout time is affected. You can't measure that with software. You need like a 1000FPS camera and record the screen.

[Kuscheln_Hammer92]

So the frame time measured in the display is not the same as what people were referring to when they were talking about LVT creating 1/240hz level of latency?

[Kuscheln_Hammer92]

I'm sorry, there was a typo in previous post, I tried setting the LVT to 4600 but that resulted in a black screen despite, so 4500 works though, I'm trying to refer back to this viewtopic.php?f=7&t=8946&hilit=scanline ... e&start=40 and others. I'm trying to ensure two things that my lvt which provides the fix for the cross talk is also providing me a qft in game and the other that I actually have it on correctly at all.

For some reason despite entering in any value for the sync does not result in scanline sync function being used. In game and no matter the sync flush, the tearline is jumping sporadically. I have to set the framelimitter in the setup window to on and select from the following async or others. Is that correct? I want the vsync on emulation but with qvt and lower input latency that I'd get with scanline sync on. I want to do this while I have my pure exp+ on which is why I'm not just using freesync.

[Kuscheln_Hammer92]

I have used amd GPUs for over half a decade. I'm very late to the party in learning I could set a minimum frame rate with Radeon Chill and then use enhanced sync for when framerates go above the monitors refresh rate. I wonder how those two in conjunction compare.

[Kuscheln_Hammer92]

So I suppose at this point what I'd appreciate anyone could tell me if I can still make use of the quick frame transport with the LVT, using AMD's chill set to 240 and enhanced sync on as I could with RTSS's sync technology.

[RealNC]

Instead of async limiter in RTSS, use back edge or front edge and see if that helps. Async does not sync to a fixed clock and thus the tearline can move. The other sync options will sync to a fixed clock and hopefully will keep the tearline more stable.

[Kuscheln_Hammer92]

Thank you. I actually really like the back edge sync most and isn't it better because of Window's programming and how that Present() works? Also I'm an idiot. The LVT are supposed to enable you to have the qft despite FRAMERATE so I don't need to worry about having the framerates limited to have the qft. Also better to have the lower GPU usage for better input latency. However if I still want a balance between low latency and qft I should keep to 100hz or 120hz and LVT. So in my case having 120hz at a LVT of 2300+ and if tighter frametimes and zero visible tearing use scanline sync or for lower input latency use in game limiter. Please tell me if I'm right.

[Kuscheln_Hammer92]

Frame time is not affected by LVT. Display scanout time is affected. You can't measure that with software. You need like a 1000FPS camera and record the screen.

To be honest, I'm still confused by your statement. I thought the whole point of LVT were to help in causing Quick Frame Transport which was all about lowering frametimes. Like how 60 fps is typically 16.67... ms and you want to bring it down to a quarter of that to the equivalent of 240hz level of frametimes in the 4.2... Ms range. It's about the LVT and large vbi and then the placement of the sync, right?

[Chief Blur Buster]

Frame time is not affected by LVT. Display scanout time is affected. You can't measure that with software. You need like a 1000FPS camera and record the screen.

Translation / Disambiguation of RealNC

He's correct, but needs disambiguation;

Everyone, RTSS doesn't always measure frametime as rendertime per se (pure GPU render time) because RTSS actually measures (GPU render time + frame-cap-blocking time) when it measures what it calls "frametime".

This is because RTSS is not always capable of determining whether the GPU is rendering or whether the drivers are now waiting (via a sync technology) before releasing the frame. So what RTSS calls "frametime" is actually the sum of (GPU rendering time) + (amount of idling time until frame release).

In other words, a sync technology such as VSYNC ON will wait until the synchronization interval (between refresh cycles), before releasing the frame (terminologies may be "frame swap" or "swapchain" or "blocking Present() call" or "return from a blocking frame-presentation API call")

Which becomes flat with VSYNC ON or RTSS Scanline Sync.

This is where people are getting "confused" by when people say "frametime" because it can means two very different metrics, due to this confusion;

(A) Pure frame rendering time; or
(B) Time interval between frame releases (including all driver/display-based throttles, caps, delays, sync technologies, etc).

If you use uncapped VSYNC OFF, then RTSS frametime is both (A) and (B) simultaneously. But if you use VSYNC ON or other caps (especially driver-based caps), then frametime is only (B) instead.

In other words, confusion is because (A) and (B) can be same or divergent. In other words, frametime is not always rendertime

I have been pouring so much time and many hours into this. I hope it isn't because I'm using DP rather than hdmi. I own an xg2431 paired with an rx 6600. I've created crt motion clarity with the instructions for a lvt with purexp+ adjustments. However, everywhere I read I should expect to see frametime regularly under 16.7ms. I am trying to pair this with RTSS Scanline Sync which I think I finally have nailed. It required me turning on the framelimiter to match hz in the setup. I could not get the tear line to stop moving across the screen without that selected. Is that the minimum frametime I should expect to see despite the LVT? I apologize this is at 60hz custom resolution with a 4500 LVT. I tried basing off of 239.9.. native and then make lvt 2600ish via the vertical calculator but that led to a black screen and obscenely large back porch. Lowering to 4500 allowed the screen to display for me. I would appreciate any and all assistance. Trust me, I have spent at least 18 hours on the topic of both backlight strobing and low latency syncs.

For LVT to reduce latency;
(1) You have to compare lag with the same non-VSYNC-OFF technology (e.g. RTSS Scanline Sync before/after LVT); and
(2) You have to adjust the scanline sync position as a negative index (above top edge).

RTSS Scanline Sync (+VSYNC OFF) isn't less lag than pure VSYNC OFF, but it's one of the lowest-lag non-VRR "framerate=Hz" sync technology available.

RTSS Scanline Sync answers the need of "I love VSYNC ON. But I hate VSYNC ON lag. What's my alternative?". And here, that's where LVT can reduce latency even further. It's not for people who say "I want something lower lag than VSYNC OFF".

When following RTSS Scanline Sync instructions, reposition the tearline above the top edge of the screen, for minimum strobe latency;