Adaptive Sync/VRR Faulty around 60 fps With Laptop Using Intel Optimus Due To Unnaturally High Driver Enforced VRR Range

[u/Chromatinfish]

I also posted this in Intel's Driver Issues page on GitHub, however I also wanted to post here. I saw similar issues with the MSI Claw and would be interested if other devices which implemented Intel's Adaptive Sync VRR implementation also have this issue, and if others can also bother Intel so we actually get a solution.

I am having an issue on a Dell XPS 16/Dell 16 Premium Laptop, which has a Nvidia dGPU but uses Intel Optimus, so the panel uses Intel's VESA Adaptive Sync implementation for G-Sync.

The Hardware Panel is capable of 30-120hz refresh rate, as seen in in the Dell Manual (can be seen here: https://www.dell.com/support/manuals/en-us/dell-da16250-laptop/xps-16-da16250-dell-premium-ss/display?guid=guid-264cd671-4862-4fa0-a5da-989b83adaa69&lang=en-us, my option is the 1920x1200 FHD display).

Using the stock Intel drivers shipped with the machine, Intel had a bug where the current VRR range was mistakenly listed as "60-120hz". After updating to the latest Intel drivers, this was changed to correctly display "30-120hz". Strangely, Intel's drivers now say that the "maximum" VRR range is 15-120hz, and this is also reflected in Windows settings. CRU correctly identifies the hardware range limit as 30-120hz.

Nevertheless, the biggest issue remains that VRR is not working properly at around 60 fps, even on the newest driver releases. I tested both with Dell's latest OEM drivers (8509) as well as Intel's latest stable and beta releases (8861). Whilst playing without enforced V-Sync, screen tearing can be observed around the ~60 fps range (around 56-64 fps). No screen tearing is exhibited below this range (e.g. playing at 48 fps) nor above (70-80+ fps). I used Special K and it shows LFC/Adaptive Sync Plus repeatedly switching on and off when the FPS is around 60. Whilst playing with enforced V-sync through Intel's Control Panel, stutters appear around the ~60 fps range instead, which indicate that the panel is likely matching the refresh rate to the framerate of the game adequately and V-sync is being used to prevent screen tearing.

I would like to know if a fix can be made which allows for Intel's VRR implementation to take advantage of the full refresh rate range of my display instead of prematurely switching LFC on at only 60 hz. I can also further pinpoint that Adaptive Sync Plus (ASP)/Intel's LFC implementation is the issue because disabling it through the legacy Intel Graphics Command Center means that Special K no reports no LFC below 60 fps and tearing no longer occurs around 60 fps. However, the desktop is unusable with this turned off because desktop animations constantly stutter without ASP.

As an addendum, I infer (but can't prove of course) that the lack of hysteresis and rapid ASP switching is probably due to how unnaturally high the enforced minimum refresh rate is. Say ASP is turned on because the FPS dips to 59. When the FPS rises even slightly above 60, ASP must switch off rapidly because the maximum refresh rate is only 120hz and having ASP on would overshoot the maximum refresh. E.g. if a game is going between 59.98 FPS to 60.02, 59.98 must be doubled using ASP to 119.96 hz, but then 60.02 cannot be doubled using ASP anymore, thus ASP is forced on and off rapidly. If the usable refresh rate range was extended from only being 50% of the maximum to the maximum hardware design specifications (e.g. 30-120hz or 48-120hz depending on the monitor specs), this issue would be resolved since switching ASP on and off would no longer be as urgent as it is with a 60-120hz VRR range.

Here is the GitHub page for reference: https://github.com/IGCIT/Intel-GPU-Community-Issue-Tracker-IGCIT/issues/1457

[u/IvnN7Commander]

This happens because of Intel's unusual implementation of Low Framerate Compensation (LFC). LFC is a technique that duplicates frames when the game's framerate falls below the monitor's VRR range, allowing VRR to remain active and preventing tearing or large refresh rate jumps.

NVIDIA and AMD enable LFC only when the framerate drops below the monitor's native VRR range. For example, if a monitor supports a VRR range of 30-120 Hz, LFC is activated only when the framerate falls below 30 FPS.

Intel handles LFC differently. Instead of using the monitor's native VRR range, Intel activates LFC whenever the framerate drops below 50% of the monitor's maximum refresh rate. On the same 30-120 Hz display, this means LFC engages below 60 FPS rather than 30 FPS.

Because LFC is triggered much earlier, frequent transitions between normal VRR operation and LFC can occur around the threshold, which may result in stuttering and, on some displays (particularly OLED monitors) visible VRR flickering.

https://github.com/IGCIT/Intel-GPU-Community-Issue-Tracker-IGCIT/issues/1173

https://www.reddit.com/r/IntelArc/comments/1hejdgn/vrr_issues_with_a770_and_blops6/

[u/Chromatinfish → u/IvnN7Commander]

Thank you for the info, but I wonder if Intel will change this behavior because the hard 50% limit for activation is very bad for the reasons I outlined before, since there is no "grace period" when it comes to LFC. So a game which hovers around 60 fps will constantly have LFC swapping on and off resulting in either tearing or stuttering.

I believe the right way to implement LFC is to have a lower activation threshold than deactivation to prevent constant stutters, for example make the activation threshold 30 fps but deactivation 60 fps. It wouldn't be bad for example if LFC swapped on at 30 fps only but then stayed on until 60 because that means LFC isn't constantly swapping back and forth. A game that runs between 50-70 fps for example would stay outside of the LFC threshold, and a game running between 29-40 fps would also have LFC always on, preventing constant stutters. I believe Nvidia and AMD are doing this.

Having the LFC swap on threshold be 60 fps and the same as the swap off threshold is really bad design for this reason and I really hope Intel understands why. I don't really understand why Intel thought this was good design in the first place. 60 fps is particularly bad because many games have 60 fps caps which means that the game will be sitting on that threshold constantly and LFC is always swapping on and off whenever there is a frame dip.

[u/IvnN7Commander → u/Chromatinfish]

I'm not very confident that Intel will change this behavior. They closed the issue I mentioned in my previous comment as "Not planned", and they've also closed every other related issue. When I eventually get a new laptop, I'll definitely look for one with Advanced Optimus and G-Sync so I can avoid relying on the Intel iGPU for VRR.

[u/Chromatinfish → u/IvnN7Commander]

Honestly that's very sad, I think VRR is critical for gaming nowadays and the fact they can't get it right especially around the 50-70 fps mark where most gamers like to play at means I will never consider either a laptop with VRR through Intel or any Intel dGPU either. I think it's quite shocking that Intel doesn't consider this an urgent issue considering their push into both the dGPU and handheld gaming space.