nvLFCreset an experimental nvapi trayapp to prevent LFC sticking for gsync compatible monitors

[elexor]

WARNING: This app is only useful for backlight strobed vrr gsync compatible displays. LFC is mostly beneficial for normal vrr monitors, so don't bother with this if you don't know what it's for.

This app minimizes to a systray icon until closed consuming minimal resources. It utilizes the Nvidia api to monitor adaptivesync. if a framerate spike big enough to trigger a sticky lfc event happens (hardcoded to 25fps for now) it will reset adaptivesync automatically.

The monitor will briefly go back to fixed max hz for 100ms and back to normal operation.
100ms isn't changeable it's just how long the nvidia drivers take to reset adaptivesync.
Has not really been tested with any other systems so it may or may not work as intended for your usecase.

LFC is still active and you still have to find the right minimum Range Limit setting in CRU.


I'm not a real programmer so this has been mostly pieced together. thanks to Kaldaien for providing functions for dealing with nvapi.


https://github.com/elexor/nvLFCreset

[Chief Blur Buster]

[Adding introduction info for other readers]

Fantastic contribution!
This should reduce double-image problems with low-framerate strobed VRR like your hacked 60Hz-implementation of DyAc.

[img]https://blurbusters.com/wp-content/uplo ... icates.png[/url]

LFC sometimes creates an issue whereupon single-image VRR suddenly becomes double-image VRR on certain VRR implementations (your modified implementation).

This can be useful for non-strobed VRR in certain cases where there’s some strange LFC behaviours such as:
- Strange appearance/disappearance of certain kinds of LFC stutters with some framerate cadences
- Strange appearance/disappearance of overdrive artifacts
- Pixel inversion artifacts that appear/disappear
- GtG-decay-derived flicker (e.g. 1% variations in brightness)
- Improving LG OLED gamma-variance behaviors.

More testing by non-strobed-VRR users may be needed in order to figure out if there are any benefits for other VRR users (in conjunction with VRR range editing in ToastyX CRU)

[Chief Blur Buster]

Developer Suggestions (for elexor)

1. Need to choose an source license

Long term, I have plans to create a “Blur Busters Refresh Rate Utility” which is sort of a merger between ToastyX / Strobe Utility / QuickRes / DDCutil (All in a multimonitor aware).

This feature *might* be a candidate for inclusion into such a theoretical future Blur Busters Refresh Rate Utility, so I’d like to know what open source license you are using —

At the moment, you have a missing LICENSE file — Within a year or two, I would love to use it in an upcoming “Blur Busters Refresh Rate Tool” open source project that combines multiple utilities (e.g. a multimonitor QuickRes-style utility combined with Strobe Utility, combined with a ToastyX launcher). If you could use a reasonably permissive license such as Apache 2.0 or MIT, that would be ideal.

Check out https://choosealicense.com/ for a good explanation of various kinds of licenses if you are unsure. I strongly recommend the Apache 2.0 license or the MIT license. Just add the LICENSE file to your github and it defines how you let others do it — that’s it!

P.S. I love GPLv3 too for some projects but for Blur Busters logo’d products (the UFO is a trademark), I can’t GPLv3 the trademark Blur Busters logo, names and other branding. While projects such as Apache allows me to handle this issue more easily — both as a hobbyist and as founder of the Blur Busters business.

2. Improved Automatic LFC Monitor

You can use a frametime monitor — but here’s an even better way that can automatically detect true LFC refresh cycles:

You can monitor driver-based LFC events by using this technique: D3DKMTGetScanLine() API. Currently, between VRR refresh cycles, D3DKMTGetScanLine() is in vblank (True). When you do a Present() — you could use a present hook — then vblank immediately ends right on the spot and the refresh cycle begins transmitting over the cable (if no pipelined 3D operations). But an LFC event is an uncommanded transition of vblank from true->false without any corresponding Present() event. So this technique can be used for LFC logging of generic VRR (VESA Adaptive Sync, FreeSync, HDMI VRR, and G-SYNC Compatible). There’s some fuzzy behaviours like the lag between Present() and the .INVBlank transitioning from true->false. It will remain false for one maxHz refreshtime (E.g. 1/240sec for a 240Hz VRR) before transitioning false->true.

This is how you can do computer-side debug logging of whether a monitor is currently refreshing or not, or whether a monitor is executing an LFC event instead of a software-delivered VRR refresh cycle. In theory, a realtime monitor of this can allow you to do an automatic dynamic LFC reset if you see LFC events happening at the wrong frequency, with LFC automatically resetting within 1-2 refresh cycles in an automatic manner, without needing a hotkey.

You don’t need to do this, but it’s a thought that might merit attention;

[elexor]

Thanks for the advice

updated it with an mit licence file.

You can use a frametime monitor — but here’s an even better way that can automatically detect true LFC refresh cycles:

Trying to keep this a lightweight utility that works globally with all games, no injection required. Not to say I'm against developing a proper LFC replacement but it's much harder to do for me, I don't know the first thing about hooking and sending present calls to the mirad of graphics api's on a windows pc.

Might make more sense for a LFC replacement to be built into something like specialK since it's open source and already has alot of the hooking and present() stuff sorted. A true LFC replacement would also have to send dwm present() because 0hz moments can happen when exiting a game or a random application can cause it.

If theirs a global way to send dummy presents let me know because my reset adaptivesync method works well but it isn't ideal also it doesn't reset instantly, it will wait until the next vblank unfortunately which is a long time to wait when framerates are very low, not fast enough to save a monitor from a blankout. but easily fast enough to keep LFC at bay.

You can monitor driver-based LFC events by using this technique: D3DKMTGetScanLine() API. Currently, between VRR refresh cycles, D3DKMTGetScanLine() is in vblank (True). When you do a Present() — you could use a present hook — then vblank immediately ends right on the spot and the refresh cycle begins transmitting over the cable (if no pipelined 3D operations).

I have gone down the road of detecting LFC frames before see my other thread. I can do it somewhat reliably but when presents get jittery and vblanks gets jittery it's really hard to tell which frame belongs to which present(). you also have the problem with certain DX12 titles where present will drift away from vblank.

I have updated to a better way of detecting low framerate moments without having to measure frametimes. A waitable timer on a second thread is triggered on vblank. if a another vblank occurs that timer resets, if the timer reaches it's maximum value adaptive sync is reset. I'm using the wait for vblank function from d3dkmt. no polling required at all so near zero cpu usage.

Since this hack relies on LFC staying on to prevent blankouts you still need to set your cru minmum range as low as possible. 25fps is the minimum safe value for my monitor. nvidia sticky lfc events are usually when a framespike dips to your minimum cru range I have found.
25fps dips are usually just loading screens and screen transitions where you don't even notice vrr disabling for a split second.

[Chief Blur Buster]

That makes sense. A passive monitoring approach is excellent for avoiding anticheat problems when you're simply writing a utility to fix buggy LFC behavior. Anticheat software really trigger hard on false-positives when you use utilities that hooks into the frame presentation chain. So there are reasons to avoid a hook.

(However, RTSS necessarily requires frame presentation hook, and anticheat software has often whitelisted RTSS, since it's frequently used for framerate statistical analysis and by the developers of the games...)

[elexor]

nvapi is pretty useful

NvU32 _NV_GET_ADAPTIVE_SYNC_DATA_V1::lastFlipRefreshCount
[out] Number of times the last flip was shown on the screen

If it's over 1 lfc is active

[Chief Blur Buster]

nvapi is pretty useful

NvU32 _NV_GET_ADAPTIVE_SYNC_DATA_V1::lastFlipRefreshCount
[out] Number of times the last flip was shown on the screen

If it's over 1 lfc is active

Yes, that's a very handy API. Very NVIDIA specific, but handy.

[elexor]

Just upgraded to a 3090, and I'm happy to report that this workaround for sticking LFC is not needed anymore. It turns out the 1080ti had a really bad G-Sync compatible implementation. Using the 3090, LFC does not stick; it will only ever kick in if the framerate dips below your CRU minimum v-rate and will go back to 1:1 framerate : Hz quickly.

Vrr single strobing is useable in any games now

[Chief Blur Buster]

Thank you for letting me know!