QFT hack for VRR possible?

[dotcomma]

I have Samsung OLED G8 which has nice low input lag at its max refresh rate 175hz. It has VRR range 48 - 175Hz and my GPU Nvidia reduces it to 56-175hz because LFC kicks in at 55hz.

Since this is OLED, I get pretty annoying VRR brightness flicker when fps jumps between between min-max (49 - 175) or around LFC threshold (55- 110) in badly optimized games like Escape from Tarkov. I want working VRR range 50 - 100hz for this game.

So in order to reduce flicker, I want to reduce max refresh to 100Hz but keep input lag of 175hz mode.

FPS limiter does not work and cannot prevent spikes to 175.

Monitor has native 120Hz VRR mode and I was able to add also 100hz VRR mode. In 100hz mode, LFC threshold is at 49hz where it should be.

As I want to have working VRR range 50-100Hz, this 100hz VRR mode is great for it.

But input lag in 100 or 120hz VRR mode is higher than native 175hz.
For example 55fps in 175Hz VRR mode feels snappier than 55fps in 100Hz VRR mode.

Is there anything I can do to have 100hz VRR mode with the same input lag and scanout speed as in native 175Hz VRR mode?

I tried to create 100Hz resolution mode with the same Pixel clock as 175Hz mode and large Vblank interval calculated by CRU (QFT hack), but 55fps in this 100Hz VRR resolution is not as snappy as in 175Hz mode.

Can you help me please on how to setup and use QFT for VRR properly? Is this even possible?


Thanks.

[dotcomma]

I think i found the answer here viewtopic.php?t=12167#p95041

It is not possible to have 100Hz physical refresh rate with the same scanout speed as 175Hz physical refresh in VRR mode.

[Chief Blur Buster]

Two tips.

- Always QFT at MaxHz if possible (1/175sec).
QFT to 1/100sec (100Hz) won't be less laggy than 1/175sec (175Hz) conduit for a lower Hz.

- VRR is already QFT, so don't need QFT unless you are trying to do a non-VRR mode with the low lag of VRR. Scanout speed of VRR is always MaxHz regardlsss of current framerate(Hz) within it, it's always a MaxHz conduit.

[dotcomma]

Two tips.

- Always QFT at MaxHz if possible (1/175sec).
QFT to 1/100sec (100Hz) won't be less laggy than 1/175sec (175Hz) conduit for a lower Hz.

- VRR is already QFT, so don't need QFT unless you are trying to do a non-VRR mode with the low lag of VRR. Scanout speed of VRR is always MaxHz regardlsss of current framerate(Hz) within it, it's always a MaxHz conduit.

Thanks Chief,

But I can't use VRR at MaxHz (175) because Nvidia driver will move LFC threshold from 48 to 55Hz which causes VRR flicker around this fps. There are also spikes to 175Hz which flickers (visible in monitor OSD). I tried combinations of several cascaded framelimiters, but these spikes still happens in Escape from Tarkov (In-game + Nvidia + RTSS with 90/93/96 limit for example).
I know this behavior is unique to this badly optimized game but anyway, it happens.


What I ended up doing is this:

1) I wrote down pixel clock of MaxHZ (175) VRR mode from CRU and I added new resolution with the same pixel clock but 100 MaxHZ. CRU calculated large vertical total for me.
2) I changed desktop resolution to this 100Hz VRR mode
3) I did set VSYNC = OFF in Nvidia profile for Escape from Tarkov
4) I'm using RTSS with no frame limit but Scanline Sync "-100"

Result is nice low lag and smooth VRR with some tearing when fps goes to 100 or below 50.

I don't know why input lag feels lower with RTSS scanline sync -100, but it definitely feels better than FPS limit 96 for example. And maybe this pixel clock trick was not necessary at all?

Anyway I'm still testing this and it seems to be the best option so far. No more annoying LFC flicker between 50-60 fps because LFC threshold is at 49, and no more spikes to 175, because maxHz is now 100. It is smooth low-lag VRR in range 50 - 100 fps.

[Chief Blur Buster]

But I can't use VRR at MaxHz (175) because Nvidia driver will move LFC threshold from 48 to 55Hz which causes VRR flicker around this fps. There are also spikes to 175Hz which flickers (visible in monitor OSD). I tried combinations of several cascaded framelimiters, but these spikes still happens in Escape from Tarkov (In-game + Nvidia + RTSS with 90/93/96 limit for example).
I know this behavior is unique to this badly optimized game but anyway, it happens.

If you use ToastyX CRU you can raise your MinHz threshold. Try raising your LFC threshold more dramatically (e.g. 65-70Hz). Basically go to the opposite side of your problem threshold

BTW, if you're doing 100Hz, you've actually disabled LFC to solve your problem. 48:100 is less than 2.4x ratio you need for LFC to be enabled. MaxHz:MinHz needs to be minimum 2.4 in order for LFC to operate. So if you're lowering to 100Hz, you've disabled LFC.

If your goal is merely simply to disable LFC (as you've actually done with 100Hz), you can slew the ratio accordingly, by using. say, a 85-90Hz minimum Hz, when doing 175Hz. That will do the same effect, and probably at much lower latency than 100Hz. If you test 65 MinHz and 175 MaxHz then you will re-enable LFC, and also probably solve your LFC entry/exit flicker at least partially.

ToastyX CRU lets you edit your MinHz (FreeSync range in CEA861 Extensions)

Right Solution for the Right Problem. If you're accidentally disabling LFC to solve your problem, why not raise your MinHz to keep your delicious 175 Hz low latency instead?

If you *want* LFC, and want to mitigate flicker, use approximately 85Hz-240Hz VRR range if you have a 240Hz OLED. High MinHz helps reduce VRR flicker caused by low refresh rate, while keeping LFC. You are at a VRR+LFC disadvantage because you only have 175 Hz, unfortunately. You could *try* 65 Hz MinHz, it will flicker a lot less than 48 Hz MinHz, but YMMV -- it varies dramatically by monitor model.

You don't want to get much less than roughly 3:1 VRR ratio, since LFC stutter is worse when MinHz and MaxHz are closer together. High quality LFC is not easy for manufacturers to do, so disabling LFC is sometimes better if the artifacts of LFC outweigh non-LFC operation (as you've noticed).

EDIT:

LFC stutter averages about 0.5/MaxHz, as LFC is essentially a collision between a pending refresh cycle & a monitor still-busy repeat-refreshing old refresh cycle. (Like a collision between two ethernet frames). Higher MaxHz means LFC becomes less necessary, since the framerate-to-refreshrate aliasing effect is so small with higher MaxHz (e.g. averages halftime of MaxHz, aka 0.5/480sec for 480Hz VRR), and you can luxuriously raise your LFC threshold to literally 100Hz and still have almost 5:1 MaxHz:MinHz ratio, knowing your 1fps-99fps material will still look defacto VRR, without the VRR flicker, and without LFC stutter due to the tinier stutter error (0.5/480sec).

For example, at 50fps, 1ms of LFC-failure stutter is hidden in 50fps motionblur/low framerate stutter (25ms persistence!), so the 25:1 blur:stutter ratio means your stutter is rendered fully invisible due to the higher MaxHz. At that point, raising LFC MinHz above the flicker region, becomes the ergonomic improvement, you'd be nowhere near the 2.4x:1 ratio anymore.
___

Now that said, RTSS Scanline Sync is sometimes a better alternative if your monitor has unsolvable VRR flicker, aqlthough it's not quite user friendly to everyone, and 100Hz still has more lag than 175Hz...

[dotcomma]

But I can't use VRR at MaxHz (175) because Nvidia driver will move LFC threshold from 48 to 55Hz which causes VRR flicker around this fps. There are also spikes to 175Hz which flickers (visible in monitor OSD). I tried combinations of several cascaded framelimiters, but these spikes still happens in Escape from Tarkov (In-game + Nvidia + RTSS with 90/93/96 limit for example).
I know this behavior is unique to this badly optimized game but anyway, it happens.

If you use ToastyX CRU you can raise your MinHz threshold. Try raising your LFC threshold more dramatically (e.g. 65-70Hz). Basically go to the opposite side of your problem threshold

BTW, if you're doing 100Hz, you've actually disabled LFC to solve your problem. 48:100 is less than 2.4x ratio you need for LFC to be enabled. MaxHz:MinHz needs to be minimum 2.4 in order for LFC to operate. So if you're lowering to 100Hz, you've disabled LFC.

If your goal is merely simply to disable LFC (as you've actually done with 100Hz), you can slew the ratio accordingly, by using. say, a 85-90Hz minimum Hz, when doing 175Hz. That will do the same effect, and probably at much lower latency than 100Hz. If you test 65 MinHz and 175 MaxHz then you will re-enable LFC, and also probably solve your LFC entry/exit flicker at least partially.

ToastyX CRU lets you edit your MinHz (FreeSync range in CEA861 Extensions)

Right Solution for the Right Problem. If you're accidentally disabling LFC to solve your problem, why not raise your MinHz to keep your delicious 175 Hz low latency instead?

If you *want* LFC, and want to mitigate flicker, use approximately 85Hz-240Hz VRR range if you have a 240Hz OLED. High MinHz helps reduce VRR flicker caused by low refresh rate, while keeping LFC. You are at a VRR+LFC disadvantage because you only have 175 Hz, unfortunately. You could *try* 65 Hz MinHz, it will flicker a lot less than 48 Hz MinHz, but YMMV -- it varies dramatically by monitor model.

You don't want to get much less than roughly 3:1 VRR ratio, since LFC stutter is worse when MinHz and MaxHz are closer together. High quality LFC is not easy for manufacturers to do, so disabling LFC is sometimes better if the artifacts of LFC outweigh non-LFC operation (as you've noticed).

EDIT:

LFC stutter averages about 0.5/MaxHz, as LFC is essentially a collision between a pending refresh cycle & a monitor still-busy repeat-refreshing old refresh cycle. (Like a collision between two ethernet frames). Higher MaxHz means LFC becomes less necessary, since the framerate-to-refreshrate aliasing effect is so small with higher MaxHz (e.g. averages halftime of MaxHz, aka 0.5/480sec for 480Hz VRR), and you can luxuriously raise your LFC threshold to literally 100Hz and still have almost 5:1 MaxHz:MinHz ratio, knowing your 1fps-99fps material will still look defacto VRR, without the VRR flicker, and without LFC stutter due to the tinier stutter error (0.5/480sec).

For example, at 50fps, 1ms of LFC-failure stutter is hidden in 50fps motionblur/low framerate stutter (25ms persistence!), so the 25:1 blur:stutter ratio means your stutter is rendered fully invisible due to the higher MaxHz. At that point, raising LFC MinHz above the flicker region, becomes the ergonomic improvement, you'd be nowhere near the 2.4x:1 ratio anymore.
___

Now that said, RTSS Scanline Sync is sometimes a better alternative if your monitor has unsolvable VRR flicker, aqlthough it's not quite user friendly to everyone, and 100Hz still has more lag than 175Hz...

Raising LFC threshold was the first solution I tried. But even 87 didn't help much because 87-174 fps jumps flickers the same as 55-110. And I have around 85fps in that game more often than around 55.
Nvidia is doing LFC regardless the ratio, even if the doubled fps exceeds monitor maxHz, they do LFC.
What worked for me the best with this approach was raising min VRR range to 120Hz and limiting game fps to 87. This way I have working VRR via LFC in FPS range 61 to 87, and no VRR below 61, when Nvidia is doing 175Hz with vsync judder, but that's much better than annoying brightness flicker.

But input lag with this approach (VRR via permanent LFC for fps range 61 to 87 resulting in 122-175Hz) does not feel better than the other approach I mentioned before, where I have working VRR in 50-100Hz range with VRR maxHz = 100.

My main problem is VRR OLED brightness flicker, not occasional stutter or tearing, that I can accept, but flicker is really the most annoying to me. These 2 options helps to reduce it to acceptable level, and the 2nd option seems to be a bit better overall.