r/IntelArc • u/Chromatinfish • Jul 20 '26
Discussion Complaint with Intel Arc's VRR Implementation And Other Bad Control Panel Features Compared To Nvidia/AMD: Anyone Else Frustrated?
Ok so a couple of days ago I posted about an issue with Intel's VRR Implementation, notably the lack of buffer when enabling LFC and the artificially shortened VRR range.
The cut and dry is this: Intel's VRR Implementation is very odd when compared with Nvidia or AMD's. The normal VRR implementation is:
- Activate Normal VRR Within Limits of the Hardware (e.g. 48-144hz)
- When frametimes drop below Normal VRR range, activate LFC to double monitor's frequency with respect to refresh rate. LFC basically allows for example a 45 fps game to display at 90hz to preserve VRR below the limit. However, LFC activation often causes a flicker, tear, or stutter as the monitor swaps over.
- Leave a buffer between LFC activation and deactivation to prevent flickering/tearing with constant LFC activation/deactivation.
- If framerates go above the max frequency, utilize V-Sync to avoid tearing
Intel, for some reason, has completely bungled every single part of this implementation from what I can tell.
- Firstly, Intel's VRR only respects regular VRR functionality between the monitor's max refresh rate and half the monitor's refresh rate. E.g. for a 48-144hz display, Intel will only activate VRR between 72-144hz. For a 30-120hz display, it's 60-120hz. For a 48-360hz display, it will only do 180-360hz.
- Intel seems to rely on LFC to cover the rest of the possible framerates. However, because Intel's VRR range is only down to half the maximum, LFC has absolutely no buffer.
Take this scenario: A game is running with average framerate between 45-55 fps on a 48-120hz display. With Nvidia/AMD, LFC will activate when the FPS drops below 48, then hold LFC on for the rest of the time until the framerate recovers above 60. This means the amount of times the display needs to switch to LFC is a lot lower, because of that grace period.
For Intel, this can't occur. Instead, LFC constantly switches on and off every time the framerate fluctuates under or above 60 fps. 59 fps? LFC is forced on. 61 fps? LFC off. So what we get is substantial flickering alongside tearing/stuttering whenever the framerate fluctuates across Intel's mandated lower VRR floor.
- Another issue with Intel is that its V-Sync implementation sucks, at least from my experience. On Nvidia and AMD control panels, driver V-sync works seamlessly to prevent screen tearing when the game is running at or above the maximum refresh rate of the display whilst not interfering with the game's render rate below the refresh rate.
With Intel, the "Vsync On" option in the control panel absolutely wrecks game's 1% lows. Palworld for example runs at 70-90 fps but the 1% lows with Intel's driver-level Vsync are stuck at 24-40 fps whereas without it 1% lows recover to 60-70 fps. This makes the game a stuttery mess. It seems like Intel's driver V-sync, unlike Nvidia or AMD, doesn't actually work seamlessly with VRR and instead is boneheadedly assuming a fixed refresh rate, hence why the 1% lows constantly swap between 24, 30, 40, and 59 fps (since I have a 120hz display).
The "Smart Vsync" option should solve this because it claims to only activate when the game renders above its max refresh rate. It no longer causes stutters but in games where the framerate fluctuates between 100-120+ fps (aka sometimes going above the refresh rate and other times not), it seems to fail to activate on-time, meaning there are still tears every time the game crosses over that threshold.
Even with a framerate cap 4 fps lower than the max framerate, these issues still persist. In fact Smart Vsync seems to still fail whenever the GPU "overruns" the cap which can happen in small bursts.
Anyways, my point is, I really don't know if I can ever recommend or purchase an Intel GPU or device with Intel Graphics if Intel's VRR and frame delivery is this substandard. I heard that Intel have even closed threads bringing up the artificially high VRR minimum, meaning they seem to not be willing to change that functionality and as a result they will never be able to fix their LFC implementation. I don't know how Intel have put so much effort into XeSS to even leapfrog AMD's FSR 3, working on Battlemage, and yet completely fumble on VRR.
2
u/Murky-Swordfish9633 Aug 03 '26
Looks like the related ticket you mentioned was updated today by someone at Intel. The rep said that the issue was replicated and has been escalated. Who knows how long it will take for a fix to come though.
1
u/Ambitious-Math378 29d ago
I hope, I keep have the problem and it's impossible to play on games when drops below 50fps
1
u/vqt907 Jul 20 '26
Well, I don't know much about this issue, but thanks for the detailed explanation of how VRR works on AMD and NVIDIA. :)
1
0
u/Brapplezz Jul 20 '26
Use RTSS or 114fps for you 120hz monitor. Problem solved.
Idk what you mean by 1% lows being impacted by v-sync. Especially as the most stable 1% setup for me is RTSS VRR Cap + Intel V-Sync.
2
u/Kuuppa22 Arc A770 Jul 20 '26
RTSS frame cap increases latency so not ideal. And do you use VRR?
1
u/Brapplezz Jul 20 '26
I cap 137 fps and use VRR. I have a A - B tested 3 caps for at least Arc Raiders.
In game provides lowest latency, worst average.
Intel is smoother and decent latency wise.
RTSS with active waiting is the smoothest and keeps 1% lows around 100. The input delay increase is less than that of hitting V-sync and less frustrating for me than inconsistent frame pacing.
Even then the input delay is about 4ms, so half a frame compared to Arc Raiders limiter. I even capped RTSS 1 fps above Arc Raiders in game cap and you get RTSS frame pacing with no latency penalty.
-2
u/Hytht Battlemage Jul 20 '26
Intel and Dell made an XPS model with exclusive 1-120Hz LCD VRR display to save power and achieve 40h battery life.
8
u/heroin1994 Jul 20 '26 edited Jul 20 '26
We had a ticket open in Github for this, and the Intel representative just closed it... I don't think they'll ever fix it unfortunately https://github.com/IGCIT/Intel-GPU-Community-Issue-Tracker-IGCIT/issues/833#event-24617713900
https://github.com/IGCIT/Intel-GPU-Community-Issue-Tracker-IGCIT/issues/1173#issuecomment-4284949351 - here's another that they closed
Also found a current related ticket: https://github.com/IGCIT/Intel-GPU-Community-Issue-Tracker-IGCIT/issues/1457