LFC range 48Hz vs 60Hz?

[2mg]

I'm putting this in Gsync section since the GPU I'm using is from NVidia (RTX2080ti) so I'm using G-sync on a Freesync Premium/G-Sync compatible VG259QM5A, GRD 591.74 driver, Win10.

According to CRU, both DP and HDMI on this monitor should have VRR range down to 48Hz.
It also has few 50Hz resolutions in EDID (not shown in screenshot below but it supports them).

However, I tested it and LFC kicks in the moment I go below 60FPS (doubling) when using it at 240Hz.
When monitor is set to 100Hz, LFC actually kicks in below 50FPS.
But oddly, when set to 60Hz it starts jumping rapidly to 60Hz when FPS is below 50 resulting in stuttery look.

Is this due to lack of a G-sync module, to prevent flicker, or because monitor doesn't have a 48Hz resolution?
Can I modify this behavior somehow when using 240Hz?

vrr

vrr.png (54.25 KiB) Viewed 246 times

[RealNC]

The driver will choose when to LFC on its own. The 48Hz value is just a piece of info that limits the driver's decisions. It does not mandate that LFC has to be only used below that. It only tells the driver what the lower limit is. If the driver deems it better to LFC at 60Hz, it will do that.

I don't know of any configuration/tweak for the driver's LFC behavior. At 240Hz, I would probably set this to something higher than 60 anyway if you're playing a lot of 60FPS games so you're always LFCing to 160Hz or up. (So 80Hz.) This avoids LFC constantly activating and deactivating, which will produce flicker on some displays. 240/80=3, so it's plenty of range for the driver to use. The minimum ratio that's not recommended to go below is about 2.3 or so.

[2mg]

The driver will choose when to LFC on its own. The 48Hz value is just a piece of info that limits the driver's decisions. It does not mandate that LFC has to be only used below that. It only tells the driver what the lower limit is. If the driver deems it better to LFC at 60Hz, it will do that.

I don't know of any configuration/tweak for the driver's LFC behavior. At 240Hz, I would probably set this to something higher than 60 anyway if you're playing a lot of 60FPS games so you're always LFCing to 180Hz or up. (So 80Hz.) This avoids LFC constantly activating and deactivating, which will produce flicker on some displays. 240/80=3, so it's plenty of range for the driver to use. The minimum ratio that's not recommended to go below is about 2.3 or so.

Some games (khm Elden Ring) are locked to 60FPS. Any miniscule oscillation will trigger 2x LFC, that's why I'd either prefer that it goes at least down to 50FPS to have VRR as sync solution, or maybe what you're saying, clip VRR range to above 60 so it will never use LFC, but then I lose VRR in those games and either get tearing or have to use regular (or RTSS/SK) Vsync?

OTOH is having 60FPS but LFC 2x to 120Hz should look better due faster frame scanout, or worse due to frame doubling?
Because integer frame doubling shouldn't look (as) stuttery, as opposed to say 50FPS having repeated frames on 60Hz Vsync'd panel for example.

PS: Some emulators can run the consoles at their not-quite-tight-60Hz with VRR, this is also where I'd rather have VRR support sub-60FPS. Setting the monitor to 60Hz isn't the solution as these consoles can have 59.9-60.1Hz oscillations plus monitors are often tuned to have least lag at their highest Hz.

[RealNC]

Some games (khm Elden Ring) are locked to 60FPS. Any miniscule oscillation will trigger 2x LFC, that's why I'd either prefer that it goes at least down to 50FPS, or maybe what you're saying, clip VRR range to above 60 so it will never uses LFC, but then I lose VRR?

You don't lose VRR. If you put the lower limit to 80Hz, it just means 60FPS will LFC to 120Hz. This is still VRR and you won't notice anything different other than the refresh rate always being double of whatever the current frame rate is. An 80Hz lower limit in this case would mean all frame rates below 80FPS will get LFC'd to 80Hz or higher, in real-time, per-frame, in typical VRR fashion. 30FPS will become 90Hz, 40FPS will become 80 or 120 (whatever the driver decides), 50 will become 100, etc. VRR is still fully working, just with every frame doubled when below 80FPS.

The driver might also decide to triple, quadruple, etc, instead of doubling. Like 50 to 150 or 200 instead of 100. But usually driver only does these LFC multiplier jumps when FPS is wildly fluctuating. If you normally cap your FPS to something the game can reach most of the time, LFC behavior should be very consistent. Unless it's right on the boundary the driver has decided to use, which is why in this case it's probably a good idea to set it to 80.

OTOH is having 60FPS but LFC 2x to 120Hz should look better due faster frame scanout, or worse due to frame doubling?

It will look the same. Frame scanout is always the same (240Hz) regardless of frame rate. The frame doubling doesn't have any visible effect on sample-and-hold displays (the frame doubling only matters for things like Pulsar or other strobing methods that can work together with VRR.)

The only case where it won't look the same is on displays that have visible differences between different refresh rates (gamma on WOLED, or ghosting differences on LCDs.)

PS: Some emulators can run the consoles at their not-quite-tight-60Hz with VRR, this is also where I'd rather have VRR support sub-60FPS. Setting the monitor to 60Hz isn't the solution as these consoles can have 59.9-60.1Hz oscillations plus monitors are often tuned to have least lag at their highest Hz.

Again, VRR will keep working just fine. LFC does not disable VRR. LFC's whole point is to keep VRR always active.

[2mg]

You don't lose VRR. If you put the lower limit to 80Hz, it just means 60FPS will LFC to 120Hz. This is still VRR and you won't notice anything different other than the refresh rate always being double of whatever the current frame rate is. An 80Hz lower limit in this case would mean all frame rates below 80FPS will get LFC'd to 80Hz or higher, in real-time, per-frame, in typical VRR fashion. 30FPS will become 90Hz, 40FPS will become 80 or 120 (whatever the driver decides), 50 will become 100, etc. VRR is still fully working, just with every frame doubled when below 80FPS.

The driver might also decide to triple, quadruple, etc, instead of doubling. Like 50 to 150 or 200 instead of 100. But usually driver only does these LFC multiplier jumps when FPS is wildly fluctuating. If you normally cap your FPS to something the game can reach most of the time, LFC behavior should be very consistent. Unless it's right on the boundary the driver has decided to use, which is why in this case it's probably a good idea to set it to 80.

1. So LFC is "semi-decoupled" from VRR?

2. It's really the driver the one that dictates LFC behavior, not the monitor?

3. Would LFC would even kick in at say 10FPS (x6 to 60Hz), or is there also a minimum range where even LFC stops working?

4. Slightly off-topic, but now displays have variable OD, but on older ones you'd rather have LFC kick in ASAP (aka even on 120FPS) to hit panels max Hz since overdrive was usually just tuned for that max Hz, correct?

It will look the same. Frame scanout is always the same (240Hz) regardless of frame rate. The frame doubling doesn't have any visible effect on sample-and-hold displays (the frame doubling only matters for things like Pulsar or other strobing methods that can work together with VRR.)

1. This would also include regular strobing ala ELMB when FPS<=2xHz or more, ala 60FPS on 120Hz/240hz, because that is 2/4 strobes per 1 frame?

2. I've an ELMB Sync monitor, aka VRR strobed (setting aside that ELMB Sync looks not-good, at least on this monitor), so when <60FPS I'll get FPS=2xHz mismatch aka frame doubling artifact, right?

3. OTOH if this panel actually could do non-LFC VRR + ELMB Sync down to 48FPS, I presume that would flicker like crazy?

4. I tried to test VRR+ELMB Sync 60FPS@120Hz and 60+120FPS@240Hz and I can't even tell if I'm looking at frame doubling artifacts because ELMB Sync even at 240FPS@240Hz looks like "double images" so I dunno if I'm looking at inverse ghosting/strobe crosstalk/devil-horn strobe look or actual frame doubling artifacts.
*There's also the fact that regular ELMB doesn't work if Hz<85, so in 240Hz mode with VRR I'm not sure if VRR ELMB Sync even is working at 60-84FPS range even though it's turned on, I'm just going by my eyeballs here unfortunately, and lower FPS just comes out looking blurry looking rather than anything else regardless of what I do (except normal ELMB with max OD, that looks "burnt" as hell).
**Using the SmoothFrog for these tests, since it does VRR.

5. I can have VRR+ELMB Sync ON, but monitor OSD allows me to change Overdrive, however, no change occurs if I change it, is this a bug or intended?

6. I've just tested this monitor with VRR at 50FPS@60hz (with ELMB Sync) and 50FPS@50hz (can't enable ELMB Sync) and the results are underwhelming and I won't go deep into how it's falling apart, but tldr is it won't flicker because 50FPS@60HZ is just oscillating 50hz-60hz rapidly, and 50FPS@50Hz the Gsync doesn't even work ingame no more (no G-sync indicator), so I can't see flicker on this screen.

The only case where it won't look the same is on displays that have visible differences between different refresh rates (gamma on WOLED, or ghosting differences on LCDs.)

By ghosting differences on LCDs do you mean with VRR but low or very unstable FPS on one single LCD, or just plain panel ghosting differences between LCDs in general?

I have to tie in another questions here - you say that scanout is always 1/MaxHz (1/240 in my case):

1. Just to double check, lets say the game is 120fps locked, but VRR is on and the display is 240hz, that means that a single frame is displayed in 4ms, but is being held/displayed for 8ms, OR it's being double scanned 2 times x 4ms?

2. VRR will never slow down the scanout, at least when if it's in max Hz mode?

3. What about when it's set to 120Hz mode, is the scanout 1/240 or 1/120?

4. I still don't fully grasp why variable OD is needed if the scanout is always at max speed, the frame is just held/displayed longer or shorter depending on when the next frame comes, and the next frame can't be faster than current scanout anyway (if GSYNC+VYSNC+Reflex=ON)?



And since we are talking about the double image/strobe issue, my question is why is that visible at all (with CRT, strobing...), do our eyes simply see that the image is duplicated because there is a flicker between repetition or is there something else involved?

PS: thanks for responding, sorry for dumping so many questions on you, it's the "for each answer, I've got two new questions" syndrome.

[RealNC]

1. So LFC is "semi-decoupled" from VRR?

It's not decoupled. It's part of VRR. In other words, LFC is a VRR feature. Well, perhaps it's more correct to say LFC is a G-sync and Freesync feature.

2. It's really the driver the one that dictates LFC behavior, not the monitor?

Without a g-sync module, it's the driver. With a g-sync module, it's the monitor.

3. Would LFC would even kick in at say 10FPS (x6 to 60Hz), or is there also a minimum range where even LFC stops working?

Yes, LFC will always multiply so that the refresh rate is within VRR range. 10FPS will become 50Hz or more.

4. Slightly off-topic, but now displays have variable OD, but on older ones you'd rather have LFC kick in ASAP (aka even on 120FPS) to hit panels max Hz since overdrive was usually just tuned for that max Hz, correct?

Probably. This was never an issue with native g-sync module monitors. They all have variable OD. I'm not sure displays without a g-sync module have variable OD even now though

1. This would also include regular strobing ala ELMB when FPS<=2xHz or more, ala 60FPS on 120Hz/240hz, because that is 2/4 strobes per 1 frame?

If it strobes, of it does BFI, and the FPS doesn't match strobe rate, you get a double-image.

2. I've an ELMB Sync monitor, aka VRR strobed (setting aside that ELMB Sync looks not-good, at least on this monitor), so when <60FPS I'll get FPS=2xHz mismatch aka frame doubling artifact, right?

Yes.

3. OTOH if this panel actually could do non-LFC VRR + ELMB Sync down to 48FPS, I presume that would flicker like crazy?

Yes, if indeed it strobes at 48FPS. But I don't think it does.

5. I can have VRR+ELMB Sync ON, but monitor OSD allows me to change Overdrive, however, no change occurs if I change it, is this a bug or intended?

No idea. Normally it should have an effect on strobe crosstalk. If it doesn't, then it means the setting is ignored and they simply forgot to gray it out and make it unchangable when ELMB is on.

By ghosting differences on LCDs do you mean with VRR but low or very unstable FPS on one single LCD, or just plain panel ghosting differences between LCDs in general?

Differences in ghosting at different refresh rates due to lack of variable OD, or badly implemented variable OD.

I have to tie in another questions here - you say that scanout is always 1/MaxHz (1/240 in my case):

1. Just to double check, lets say the game is 120fps locked, but VRR is on and the display is 240hz, that means that a single frame is displayed in 4ms, but is being held/displayed for 8ms, OR it's being double scanned 2 times x 4ms?

2. VRR will never slow down the scanout, at least when if it's in max Hz mode?

3. What about when it's set to 120Hz mode, is the scanout 1/240 or 1/120?

In VRR mode, the scanout speed is always fixed. It matches the current mode's refresh rate. No matter what the frame rate is, each frame is being scanned out in 4.2ms. After the scanout finishes, the display does nothing, meaning the frame stays on the screen as-is, until the next one is ready to be scanned out. If the next frame takes too long to arrive, then the current frame gets scanned out again (this is LFC.)

4. I still don't fully grasp why variable OD is needed if the scanout is always at max speed, the frame is just held/displayed longer or shorter depending on when the next frame comes, and the next frame can't be faster than current scanout anyway (if GSYNC+VYSNC+Reflex=ON)?

Overdrive is a voltage manipulation to the LCD pixels. The voltage alters the color of the pixels over time. If the incorrect voltage is applied to a pixel for a longer or shorter period than what was intended, the pixel will change its color to something that was not intended. This results in ghosting.

Variable OD needs to have some sort of prediction algorithm so it knows beforehand how long it will take for the next frame to arrive so that it doesn't overshoot or undershoot the voltage. This is a difficult thing to implement and also requires some processing power. The g-sync module can do it, but I guess most scalers used in monitors without a module might not be fast enough to do it.

And since we are talking about the double image/strobe issue, my question is why is that visible at all (with CRT, strobing...), do our eyes simply see that the image is duplicated because there is a flicker between repetition or is there something else involved?

It happens for the same reason why sample-and-hold displays without strobing have more motion blur the lower the frame rate gets. Your eyes are tracking what your brain thinks is continuous movement. So your eyes move smoothly and continuously to track the "moving" object. But there is no continuous movement on a screen. It's just a series of static images.

On sample-and-hold displays, when a new frame is being displayed, your eyes keep moving even though the image is static. When your eyes move while something is static, that gets perceived as a blur trail by your brain. The same thing happens when your eyes don't move but the object moves (in real life.) If you don't track a moving object with eyes as it moves, you see it have blur trail as it moves across your field of vision. Whether it's the object that moves and your eyes don't or vice versa, the result is the same: motion blur. To prevent this blur trail, the screen must turn black until the next frame arrives. Which what CRTs do (or backlight strobing, or BFI.)

When strobing, your eyes do the same thing. They move across the screen trying to track what looks like a moving object. But then the image disappears because the screen turns black. When the screen is black, your eyes keep moving, so you're now looking at a new position on the screen that's slightly ahead of where the object was. Then the screen lights up again, but it shows the same image as before (because it doubled the same frame, like 60FPS@120Hz.) So now your eyes are looking ahead of where the object was, but the object didn't move and so you see it slightly behind in your field of vision. You perceive this as a copy of the object, trailing behind the first position of the object in your FOV. The more times the same frame is shown, the more copies of it you'll see. 60@120Hz creates a double image, 40FPS@120Hz a triple image, 30FPS@120Hz a quadruple image, and so on.

This is all caused by persistence of vision. It takes some time for an image to disappear from your brain, and as a result all these effects are happening when viewing animation on a screen that consists of a series of static frames. See: https://en.wikipedia.org/wiki/Persistence_of_vision

[2mg]

It's not decoupled. It's part of VRR. In other words, LFC is a VRR feature. Well, perhaps it's more correct to say LFC is a G-sync and Freesync feature.

Yes, that's what I meant, thanks.

Probably. This was never an issue with native g-sync module monitors. They all have variable OD. I'm not sure displays without a g-sync module have variable OD even now though

Well, the VG259QM5A is a weird beast - it's a Freesync Premium/G-sync compatible. Ironically, the stand for the monitor has a "NVIDIA G-Sync" sticker. And yes, it has variable Overdrive. GPU sees it as G-sync compatible only tho.

Differences in ghosting at different refresh rates due to lack of variable OD, or badly implemented variable OD.

Do you mean different fixed refresh rates, or different refresh rates under VRR?

Because with fixed refresh rates, sure, missing/bad OD means the screen is crap at anything except max Hz.

But if you mean under VRR, well that would affect any monitor without G-Sync module (or Freesync equivalent to that module) - wouldn't that make a HUGE amount of monitors bad at VRR, there are a lot of G-sync compatible/standard Freesync monitors out there?

OTOH VRR is always the max hz scanout, so I again I don't see the need for variable OD here (see question below)?

Variable OD needs to have some sort of prediction algorithm so it knows beforehand how long it will take for the next frame to arrive so that it doesn't overshoot or undershoot the voltage. This is a difficult thing to implement and also requires some processing power. The g-sync module can do it, but I guess most scalers used in monitors without a module might not be fast enough to do it.

But under VRR since everything is done at max scanout speed, it's like you're using the panel at it's max refresh rate constantly.
You only change VBI duration/hold the image displayed longer/shorter but again never shorter than scanout speed, so I have tough time understanding why you would need to adjust voltages differently, you always have exactly the same time to do it, 1/maxHz, no?

This is all caused by persistence of vision. It takes some time for an image to disappear from your brain, and as a result all these effects are happening when viewing animation on a screen that consists of a series of static frames. See: https://en.wikipedia.org/wiki/Persistence_of_vision

I am aware of that.


However, if just 1 line going down fast enough on a CRT display is enough to trick our minds to think we saw a full image (frame), if you redraw that image the same way, how can we see it as a double frame?

The only time a CRT has a fully black screen is when it does a vertical retrace, and that afaik is veeery short - is that what trips our eyes?
*consider that we are staring at 30FPS content on 60Hz CRT for simplicity, I'm not talking about having stable FPS and a sudden 1 frame that repeats due to a performance hiccup.

Basically this:
CRT draws the first line, our vision system picks up on that something is happening.
CRT line has moved to the half of the screen, we think we are seeing half of the frame due to persistence.
CRT line is at the last line, and our vision system thinks we have seen one full frame being displayed on the entire screen, but that never really physically happened on the CRT.

Basically, with CRT we think we saw what we actually see on an LCD screen - because there the frame is physically on the screen as it's being drawn.

Now I understand that due to sample-and-hold, the next frame is just painted over old one, and we see that as blur.
But the question is still with CRT when was it that we noticed the flicker, the "there was a brief black between frames"?

[RealNC]

Variable OD needs to have some sort of prediction algorithm so it knows beforehand how long it will take for the next frame to arrive so that it doesn't overshoot or undershoot the voltage. This is a difficult thing to implement and also requires some processing power. The g-sync module can do it, but I guess most scalers used in monitors without a module might not be fast enough to do it.

But under VRR since everything is done at max scanout speed, it's like you're using the panel at it's max refresh rate constantly.
You only change VBI duration/hold the image displayed longer/shorter but again never shorter than scanout speed, so I have tough time understanding why you would need to adjust voltages differently, you always have exactly the same time to do it, 1/maxHz, no?

The refresh rate changes with VRR. The scanout speed doesn't. Every frame is scanned out at the same speed. But the pause where the display waits before scanning out the next frame is what's variable.

For OD, the scanout speed is not important. It's the amount of time the frame stays on the screen without being refreshed that matters. You need to keep in mind that "display scanout" is just another term for "applying new pixel voltages". If you apply a new voltage to a pixel, that pixel will keep changing its color over time at a speed that depends on the voltage. If you intended for a pixel to have that voltage applied to it for 10ms, but then because of VRR it actually takes 15ms for the next voltage change, then that means overshoot, which causes ghosting.

This is all caused by persistence of vision. It takes some time for an image to disappear from your brain, and as a result all these effects are happening when viewing animation on a screen that consists of a series of static frames. See: https://en.wikipedia.org/wiki/Persistence_of_vision

I am aware of that.

However, if just 1 line going down fast enough on a CRT display is enough to trick our minds to think we saw a full image (frame), if you redraw that image the same way, how can we see it as a double frame?

Because by the time the same frame is redrawn, your eyes have moved further to the right (if the motion your eyes are tracking is left to right.) So when the frame is redrawn, you see the object at a different position in your FOV compared to the first time you saw it. So you see two objects instead of one because the first time you saw it is still in your perception due to persistence of vision. And now you see the same object again at a slightly different position since your eyes have moved. So you perceive two objects instead of one.

If instead of redrawing the same frame a new frame is drawn (which means FPS=Hz), then there's no problem because the new frame will have the object your eyes are tracking at the correct position right where your eyes expect to see that moving object, meaning it's at the same position as the previous time you saw it in your FOV.

[2mg]

The refresh rate changes with VRR. The scanout speed doesn't. Every frame is scanned out at the same speed. But the pause where the display waits before scanning out the next frame is what's variable.

For OD, the scanout speed is not important. It's the amount of time the frame stays on the screen without being refreshed that matters. You need to keep in mind that "display scanout" is just another term for "applying new pixel voltages". If you apply a new voltage to a pixel, that pixel will keep changing its color over time at a speed that depends on the voltage. If you intended for a pixel to have that voltage applied to it for 10ms, but then because of VRR it actually takes 15ms for the next voltage change, then that means overshoot, which causes ghosting.

Okay, beginning to understand it more now, the problem lies in that transition between frames - or more precisely, the voltage used to draw AND hold a pixel on screen when you have varying refresh rates?

But that would mean if you draw that pixel for 10ms and use appropriate voltage, you would need to be able to see the future to know that you need different voltage for that new 15ms pixel, because you first have to know how long that pixel will last in the first place?

Unless VRR works by first informing the display about that 15ms duration, so the display can then vary OD/voltages and draw it, meaning the display is ever so slightly (perhaps imperceptibly) laggy?

Because by the time the same frame is redrawn, your eyes have moved further to the right (if the motion your eyes are tracking is left to right.) So when the frame is redrawn, you see the object at a different position in your FOV compared to the first time you saw it. So you see two objects instead of one because the first time you saw it is still in your perception due to persistence of vision. And now you see the same object again at a slightly different position since your eyes have moved. So you perceive two objects instead of one.

If instead of redrawing the same frame a new frame is drawn (which means FPS=Hz), then there's no problem because the new frame will have the object your eyes are tracking at the correct position right where your eyes expect to see that moving object, meaning it's at the same position as the previous time you saw it in your FOV.

So your eyes moved, but the object repeated or "stayed in wrong position", which makes it look like two objects, makes sense, there is a visual disconnect with what we expect to see and what occurred.

But the problem of FPS=1/2Hz is that you can see the object that's in the center of your screen (so your gaze is fixed/static on it) like Mario or Sonic when going full speed and being in the center of the screen (only their running sprites change), also appear like 2 images, no?

You also said repeated frames on sample&hold aren't an issue in few posts earlier, but according to logic you now explained when tracking left to right it would result in double image even on sample&hold?

[RealNC]

Okay, beginning to understand it more now, the problem lies in that transition between frames - or more precisely, the voltage used to draw AND hold a pixel on screen when you have varying refresh rates?

But that would mean if you draw that pixel for 10ms and use appropriate voltage, you would need to be able to see the future to know that you need different voltage for that new 15ms pixel, because you first have to know how long that pixel will last in the first place?

Yes. It's a predictive algorithm that needs to take into account the frame times of previous frames and then predict what's gonna happen. If it was easy, every monitor would have it But it's not, and usually display vendors don't care much. And it's also the cost. It might require a faster scaler to run this algorithm instead of a cheap one.

Unless VRR works by first informing the display about that 15ms duration, so the display can then vary OD/voltages and draw it, meaning the display is ever so slightly (perhaps imperceptibly) laggy?

I'm not aware of this being a thing. It's up to the display how to do OD. It needs to figure it out on its own.

So your eyes moved, but the object repeated or "stayed in wrong position", which makes it look like two objects, makes sense, there is a visual disconnect with what we expect to see and what occurred.

But the problem of FPS=1/2Hz is that you can see the object that's in the center of your screen (so your gaze is fixed/static on it) like Mario or Sonic when going full speed and being in the center of the screen (only their running sprites change), also appear like 2 images, no?

If you see two images there, then it's not a double-image effect. It's crosstalk.

You also said repeated frames on sample&hold aren't an issue in few posts earlier, but according to logic you now explained when tracking left to right it would result in double image even on sample&hold?

It results in blur, not double-image. With sample-and-hold, the object stays visible at a fixed position while your eyes are moving. This creates a blur trail. The more times the same frame is repeated, the bigger the blur trail gets.

Sample-and-hold: blur
Strobing: double-image

They both have the same cause behind them: your eyes are moving while the screen only shows static frames.