Freesync, LFC kicks in early

yamaci1775 · Post by **yamaci1775** » 27 Jan 2019, 02:33

Hi people, I have a GTX 1080 and XG2401 and when I heard the gsync update is availabe for my gpu i was really thrilled.

It works really fine but most of the sync is done via the LFC. My monitors sync range is 48-144 but LFC usually kicks in about 70-72 FPS. Below 72 FPS, LFC always kicks in

i tried below 24 fps, and LFC still kicked in, not in a double the refresh rate way but by the multiples of the fps (24 fps to 72 hz, 20 fps to 80 hz)

it seems like its almost impossible to see 48-72 hz range. Is there any particular setting i can help battle this off?

Experience is still smooth, i will be honest, but I would like to also experience 48-72 hz range sync as well.

But again, I dont expect perfect gsync since its an extra after all

but maybe its a problem that can be solved by some settings I dont know, so thats why I'm asking here.

good day

Post by **Chief Blur Buster** » 27 Jan 2019, 03:25

Lemme reach out to my NVIDIA contacts.

PRO:
That said, early LFC (e.g. LFC kicking in at higher Hz) has a known advantage: It reduces the low-Hz flickering from pixel decay effects and/or artifacts from LCD voltage-inversion logic (e.g. popping up a menu may often trigger a low framerate, that causes it to start to look flickery). Inversion artifacts (such as flickering checkerboard pixel patterns) does get worse at low native refresh rates on certain TN panels. That's where raising LFC min-Hz really helps.

CON:
However, it increases the likelihood of a repeat-refresh scanout still being in progress when the next frame is ready (fording that frame to wait) in fluctuating-frame rate situations, so early-LFC can worsen motion in random-frame rate games. LFC tries to guess the best time to repeat-refresh between frames but if the guess is wrong, the new frame readiness collides with the monitor still being busy in repeat-refresh scanout. The stall (latency) is up to one refresh cycle (1/144sec) depending on how early/late the frame is delivered while monitor is still busy repeat-refreshing. And that also adds a resulting microstutter right at that instant. A trade off effect in monitor-vs-driver engineering.

However, for FreeSync, it is the GPU’s responsibility (aka graphics driver!) responsibility to transmit-out the repeat refreshes automatically. My opinion is the advanced user should choose the VRR range like a Custom Resolution Utility, to choose the preferred trade off.

yamaci1775 · Post by **yamaci1775** » 28 Jan 2019, 12:28

Thanks for your concern! I opened CRU and it stated that Vertical range was between 48 and 146. I tinkered around with it, I set it to 30-146 but nothing changed.

By the wy, horizontal rate is between 180 and 180. Is it normal? I remember it being different, it feels like I accidently changed it, but don't know exactly.

Post by **Chief Blur Buster** » 28 Jan 2019, 17:41

Don't worry. Horizontal scan rate should always be constant during VRR.

NOTE: If you accidentally changed horizontal scan rate and you're not sure it's correct anymore -- you can delete the custom resolution (let the monitor go back to its industry standard mode), and try modifying it again. If you use ToastyX instead of NVIDIA, use the reset-all.exe executable and start over if you're concerned that you messed it up.

Blur Busters Glossary:
What is Horizontal Scan Rate?
What is Horizontal Refresh Rate?
It's scanlines per second. Number of pixel rows per second. A scan rate of 180 kilohertz (180,000 Hz) means the monitor can refresh one row of pixels in 1/180,000sec. It is the number of pixel rows per second that a monitor can refresh. Screens don't refresh all pixels at the same time, they often refresh at one pixel row at a time (with a pixel-response GtG lag-behind effect). Look at High Speed Videos of Screen Refreshing. What this means is that the refreshing sweep occurs at a constant speed on VRR. Even a 144Hz VRR monitor running at 40fps (40Hz) refreshes the "40Hz" refresh cycle in a single 1/144sec "sweep" from top-to-bottom, at the horizontal scanrate speed. The pauses between refresh cycles simply varies. Those pauses between refresh cycles are called vertical blanking intervals (VBI), and are also often nicknamed VSYNC too -- and that's where "VSYNC" terminology came from (VSYNC = Vertical Synchronization = the monitor synchronizing to a new refresh cycle).

gabezz · Post by **gabezz** » 21 Feb 2019, 10:27

Chief Blur Buster wrote:Lemme reach out to my NVIDIA contacts.

PRO:
That said, early LFC (e.g. LFC kicking in at higher Hz) has a known advantage: It reduces the low-Hz flickering from pixel decay effects and/or artifacts from LCD voltage-inversion logic (e.g. popping up a menu may often trigger a low framerate, that causes it to start to look flickery). Inversion artifacts (such as flickering checkerboard pixel patterns) does get worse at low native refresh rates on certain TN panels. That's where raising LFC min-Hz really helps.

CON:
However, it increases the likelihood of a repeat-refresh scanout still being in progress when the next frame is ready (fording that frame to wait) in fluctuating-frame rate situations, so early-LFC can worsen motion in random-frame rate games. LFC tries to guess the best time to repeat-refresh between frames but if the guess is wrong, the new frame readiness collides with the monitor still being busy in repeat-refresh scanout. The stall (latency) is up to one refresh cycle (1/144sec) depending on how early/late the frame is delivered while monitor is still busy repeat-refreshing. And that also adds a resulting microstutter right at that instant. A trade off effect in monitor-vs-driver engineering.

However, for FreeSync, it is the GPU’s responsibility (aka graphics driver!) responsibility to transmit-out the repeat refreshes automatically. My opinion is the advanced user should choose the VRR range like a Custom Resolution Utility, to choose the preferred trade off.

Re: Freesync, LFC kicks in early

Hello!

I've created an account specifically because this thread speaks to my situation. I'm also eyeballing to purchase an XG2401, and I too also have a GTX 1080 to pair with it. On another site, in foreign language I saw a review that also spoke of g-sync perfectly working except for LFC kicking in early, around 70-72 FPS.

They didn't investigate or discuss it further there, but I'm very happy I could read an official nvidia contact reply here. However I'm absolutely unknowledgeable about anything that was spoken about.

Could you please ELI5 to me what exactly was said? From what I can surmise early LFC means less low framerate flickering..but can introduce more motion blur and/or microstutter when it's being active? Would it do that only sometimes, or does it depend on anything or is it a constant side effect? I've never owned a freesync or g-sync monitor before, so I don't even know what LFC normally looks like.

This is the crux of my issue and these are my main questions. I can only afford a budget 144hz monitor and I really want variable refresh rate if possible at this price point for my GPU. Or should I forget about this and just go for an AOC G2590FX? Does it have a proper g-sync compatible VRR range without early LFC? How trustworthy is AOC's quality testing compared to viewsonic?

Thank you for any and all replies and explanation.

Post by **Chief Blur Buster** » 23 Feb 2019, 20:26

Intrisinically, perfectly framepaced LFC is indistinguishable from perfectly framepaced non-LFC.
Should look exactly identical.

LFC flicker is simply a side effect, sometimes monitor-specific, that may or may not happen, and has multiple causes, that should not be confused:
- Soft flicker caused by pixel decay effects (can be 0.1% or 1% or 5% fade before the next new refresh cycle arrives)
- Soft flicker caused by interactions with LCD inversion algorithms which can have more visible flicker at low frame rates
- Hard-flicker (0%-to-100%) during certain frame rates, caused by bugs in graphics drivers, bugs in EDIDs, bugs in ustom resolutions, bugs in monitors. Some of these may occur only during LFC.

LFC stutter is simply a side effect that may or may not happen, because:
- A new refresh cycle arrives while the monitor is still not finished repeat-refreshing an old frame
- This mainly happens only if the framerate is hugely erratic, to the point where repeat-refreshes are not being successfully timed seamlessly between new frames.
- Higher-Hz and/or Wider VRR ranges means less chance for LFC stutter to become visible
- LFC stutter is extremely faint on 240Hz monitors since the frametime delay is only up to +1/240sec (4.2ms) in the worst case