Re: VRR Floor Limited to 72 Hz (Should Be 48 Hz) on Arc 140V / Core Ultra 7 258V

lenzx · ‎10-23-2025

Summary / Problem Statement

When connecting an MSI MAG274UPF monitor (48 – 144 Hz Adaptive-Sync range) to my ASUS ExpertBook P5 (Core Ultra 7 258V, Intel Arc 140V graphics) over USB-C DisplayPort, the Intel driver enforces a minimum VRR floor of 72 Hz instead of the panel’s true 48 Hz capability.
This occurs across all recent Intel Graphics drivers, including the latest gfx_win_101.8136.
As a result, frame rates between 48–72 FPS exhibit stutter and double-refresh behavior (e.g., 60 FPS → 120 Hz output), making gameplay uneven and negating the benefits of low-framerate VRR.

System Configuration

Laptop: ASUS ExpertBook P5 (P5405)
CPU / GPU: Intel Core Ultra 7 258V (Arc 140V iGPU)
OS: Windows 11 24H2 Build 26100.6899
Driver Version: Intel Graphics 101.8136 (latest as of Oct 2025)
Connection: Direct USB-C → USB-C (DisplayPort Alt Mode, no dock or hub)
Monitor: MSI MAG274UPF (4K 144 Hz, Adaptive-Sync, FW.021)
Monitor Settings: Adaptive-Sync ON, HDR OFF
Windows VRR Setting: ON (System → Display → Graphics → Default Graphics Settings → Variable Refresh Rate)
Color Depth / Format: Panel supports 12-bit; tested with 8-bit for troubleshooting.
Alternate Systems for Comparison:
- AMD RDNA3 APU → works properly (48–144 Hz VRR)
- NVIDIA GPU via HDMI 2.1 → works properly (48–144 Hz VRR)

Steps to Reproduce

Connect MSI MAG274UPF directly to the laptop via USB-C.
Set display to 3840×2160 @ 144 Hz (Adaptive-Sync ON).
Open Intel Graphics Command Center → Display → Variable Refresh Rate.
- Maximum VRR Range: 48 – 144 Hz (correct)
- Current VRR Range: 72 – 144 Hz (incorrect; should match maximum)
Launch A Short Hike (or any title with a stable frame limiter).
Cap FPS = 60 → monitor OSD reports ~120 Hz (2× FPS) and gameplay stutters.
Cap FPS = 72 → OSD oscillates between double and single rate (rapid jitter ±5–10 Hz).
Cap FPS = 120 → OSD flickers around 120 Hz instead of holding steady.
Cap FPS = 144 → severe tearing until FPS ≤ 135 FPS.

Expected Behavior

Driver should respect the monitor’s full Adaptive-Sync range (48 – 144 Hz).
At 60 FPS, panel refresh should track ~60 Hz (not 120 Hz).
Frame pacing should remain smooth across 48–144 FPS.
OSD refresh value should remain stable when FPS is locked.
V-Sync should not be required to eliminate tearing within the VRR window.

Actual Behavior

Intel driver enforces 72–144 Hz Current VRR Range for both internal and external panels that support 48 Hz floors.
Frame rates < 72 FPS are doubled, producing stutter / judder.
OSD refresh values fluctuate rapidly (±5–10 Hz) even at constant frame rates.
When Color Format = RGB, image appears washed out below 144 Hz.
- Workaround: Setting YCbCr 4:4:4 in Intel Graphics Software restores proper contrast at 120 Hz.
Tearing persists until frame rate is capped ~135 FPS or lower.

Additional Observations

Issue persists across both USB-C and Thunderbolt 4 ports.
Using CRU (Custom Resolution Utility) to set a custom VRR range updates the Maximum VRR Range readout but does not affect the enforced Current VRR Range floor (72 Hz remains).
The same monitor and cables function normally with AMD and NVIDIA GPUs.
Reducing refresh to 120 Hz changes the floor to 60 Hz (current range 60–120 Hz), indicating the driver ties VRR floor to ~50% of the active refresh rate rather than the EDID range.

Suspected Cause

Likely a firmware or driver policy in Intel’s Display Engine that clamps minimum VRR frequency to ~50% of the active refresh rate under certain bandwidth conditions (4K + 144 Hz + RGB 4:4:4).
This behavior appears to override EDID Range Limits and affects both internal and external Adaptive-Sync displays.

Workarounds Tried

Clean driver install via DDU → no change
Reduced bit depth → no change
Alternate cables (USB-C ↔ USB-C and TB3 ↔ DP) → no change
Adaptive-Sync toggled OFF/ON → no change
Custom EDID via CRU → recognized but ignored for VRR floor
Lower refresh (120 Hz) → VRR floor = 60 Hz (50% rate)
YCbCr 4:4:4 format prevents color washout seen with RGB below 144 Hz

Request for Action

Please investigate the VRR floor behavior on Arc 140V / Core Ultra 7 258V platforms and verify whether the driver is incorrectly enforcing a 50% refresh-rate minimum VRR limit.
If intentional for stability, consider adding an override or profile for displays whose EDID explicitly supports < 72 Hz VRR floors.
This issue affects both internal and external panels, suggesting a global driver-level constraint rather than a monitor or connection fault.

lenzx · ‎10-23-2025

I am attaching a video demonstrating the behavior. This is on the same MSI MAG274UPF monitor noted above, using Graphics Driver Version 32.0.101.8136 and Intel Graphics Software Version 25.32.1758.2. Please note the monitor’s OSD on the right side of the left display — the “Refresh Rate” value fluctuates rapidly.

With a Current Variable Refresh Rate Range of 72Hz–144Hz, if I cap the frame rate to 75 FPS, the OSD occasionally shows a triple-digit refresh rate, indicating that the actual refresh is briefly dropping below 72 Hz instead of remaining steady at 75 Hz. When capping the frame rate to 73 FPS, the OSD shows even more rapid fluctuation between double- and triple-digit values.

This appears to suggest that the Intel driver is not correctly enforcing the VRR floor (72 Hz in this case), resulting in the refresh rate oscillating below the defined range. This may also explain the screen tearing I experience when playing games near the upper limit of 144 Hz — for example, if the effective refresh deviates by ±5 Hz, the GPU might occasionally output 149 Hz at 144 FPS, which is out of spec for this display.

The same setup behaves normally when using an AMD RDNA3 GPU connected to the same monitor via the same DisplayPort-over-USB-C cable. In that configuration, a locked frame rate produces a stable refresh rate on the OSD, and gaming at 144 FPS shows no tearing.

DeancR_Intel · ‎10-23-2025

Hi lenzx,

Thank you for providing such a comprehensive and detailed report regarding the VRR floor limitation issue on your Intel Arc 140V graphics. Your thorough documentation, including system specifications, reproduction steps, and the video demonstration showing the refresh rate fluctuations, is extremely helpful for understanding this display compatibility concern.

I can see you've identified that the Intel driver is enforcing a 72-144 Hz VRR range instead of respecting your MSI MAG274UPF monitor's full 48-144 Hz Adaptive-Sync capability, and your observation about the driver potentially tying the VRR floor to ~50% of the active refresh rate is particularly insightful.

Before we proceed with further investigation, I'd like you to try the latest Intel graphics driver version 32.0.101.8247, which may contain improvements for VRR behavior. You can download it here: https://www.intel.com/content/www/us/en/download/785597/intel-arc-graphics-windows.html

Please perform a clean installation using Display Driver Uninstaller (DDU) to completely remove your current driver, restart the system, then install the fresh driver. This ensures no remnants from previous installations interfere with VRR functionality.

Additionally, since you're using an ASUS ExpertBook P5, I should mention that laptop manufacturers often customize graphics drivers for their specific hardware configurations. While Intel provides generic drivers that support broad compatibility, OEM-provided drivers are specifically optimized for your laptop's unique hardware implementation and may handle VRR differently. You might want to check if ASUS has released any updated graphics drivers for your specific model that could address this VRR floor behavior.

Please test with the new driver and let me know if the VRR range behavior improves.

Best regards,

Dean R.

Intel Customer Support Technician

lenzx · ‎10-24-2025

Hi Dean,

Thank you for your quick and detailed reply. I’ve completed the requested testing using DDU with both the ASUS-provided driver (v32.0.101.6556, dated 2025/03/06) and the latest Intel driver (v32.0.101.8247, dated 2025/10/23). The results were identical to my previous tests.

In both cases, the Intel driver enforces a “Current Variable Refresh Rate Range” of 72–144 Hz for my MSI MAG274UPF display, despite the monitor’s EDID correctly advertising 48–144 Hz as its supported VRR range. The same floor limitation occurs at other refresh modes (for example, 60–120 Hz).

I also re-examined the refresh rate fluctuation behavior using the monitor’s on-screen display. At a 60–120 Hz VRR range, I observed fluctuations of roughly ±7 Hz around the target. For instance, capping the framerate at 67 FPS results in relatively stable readings, but reducing the cap to 66 FPS causes intermittent triple-digit values to appear. While this isn’t fully conclusive, it suggests a fluctuation tolerance of approximately ±5–10 Hz near the VRR floor, which aligns with the tearing and instability I described earlier.

At this point, I believe the most important takeaway is that this issue appears to affect a wide range of Intel Arc devices and displays, not just my setup. After investigating reports on Reddit, I’ve found consistent behavior across multiple configurations—each showing that the Intel driver sets the VRR floor to approximately 50 % of the panel’s maximum refresh rate, regardless of its EDID-advertised range.

Device / GPU Monitor Advertised VRR Range Intel Driver "Current" Range Relationship

ASUS ExpertBook P5 (Core Ultra 7 258V / Arc 140V)	MSI MAG274UPF	48–144 Hz	72–144 Hz	50 % of max
MSI Claw 8 AI+ A2VM (Core Ultra 7 258V / Arc 140V)	Internal Panel PN8007QB1	48–120 Hz	60–120 Hz	50 % of max
Desktop Arc B580 User #1	KGS241Q S	48–165 Hz	82.5–165 Hz	50 % of max
Desktop Arc B580 User #2	G34WQCP	48–180 Hz	90–180 Hz	50 % of max

This consistent pattern suggests that the VRR floor limitation is likely enforced by the driver itself, rather than being tied to OEM firmware or specific display hardware.

Additional reports from other users describe similar VRR range limitations and refresh instability:

MSI Claw 8 AI+ A2VM threads:

Intel Arc B580 threads:

Each of these cases shows the same ~50 % floor rule and similar refresh instability near the VRR minimum threshold. Given that the affected devices include both mobile (Arc 140V) and desktop (Arc B580) implementations, the issue appears to stem from a shared VRR handling mechanism in the driver.

I’ll continue monitoring this thread for any updates or diagnostic requests. Please let me know if Intel engineering would like additional testing under specific conditions or firmware revisions. Thank you.

lenzx · ‎10-24-2025

Hi Dean,

Thank you for your quick and detailed reply. I’ve completed the requested testing using DDU with both the ASUS-provided driver (v32.0.101.6556, dated 2025/03/06) and the latest Intel driver (v32.0.101.8247, dated 2025/10/23). The results were identical to my previous tests.

In both cases, the Intel driver enforces a “Current Variable Refresh Rate Range” of 72–144 Hz for my MSI MAG274UPF display, despite the monitor’s EDID correctly advertising 48–144 Hz as its supported VRR range. The same floor limitation occurs at other refresh modes (for example, 60–120 Hz).

I also re-examined the refresh rate fluctuation behavior using the monitor’s on-screen display. At a 60–120 Hz VRR range, I observed fluctuations of roughly ±7 Hz around the target. For instance, capping the framerate at 67 FPS results in relatively stable readings, but reducing the cap to 66 FPS causes intermittent triple-digit values to appear. While this isn’t fully conclusive, it suggests a fluctuation tolerance of approximately ±5–10 Hz near the VRR floor, which aligns with the tearing and instability I described earlier.

At this point, I believe the most important takeaway is that this issue appears to affect a wide range of Intel Arc devices and displays, not just my setup. After investigating reports on Reddit, I’ve found consistent behavior across multiple configurations—each showing that the Intel driver sets the VRR floor to approximately 50% of the panel’s maximum refresh rate, regardless of its EDID-advertised range.

Device / GPU	Monitor	Advertised VRR Range	Intel Driver "Current" Range	Relationship
ASUS ExpertBook P5 (Core Ultra 7 258V / Arc 140V)	MSI MAG274UPF	48–144 Hz	72–144 Hz	50% of max
MSI Claw 8 AI+ A2VM (Core Ultra 7 258V / Arc 140V)	Internal Panel PN8007QB1	48–120 Hz	60–120 Hz	50% of max
Desktop Arc B580 User #1	Acer KGS241Q S	48–165 Hz	82.5–165 Hz	50% of max
Desktop Arc B580 User #2	Gigabyte G34WQCP	48–180 Hz	90–180 Hz	50% of max

This consistent pattern suggests that the VRR floor limitation is likely enforced by the driver itself, rather than being tied to OEM firmware or specific display hardware.

Additional reports from other users describe similar VRR range limitations and refresh instability:

MSI Claw 8 AI+ A2VM threads:
https://www.reddit.com/r/MSIClaw/comments/1m790kg/vrr_not_working_in_claw_8_ai
https://www.reddit.com/r/MSIClaw/comments/1mur588/warning_8_ai_do_not_install_intel_driver_support
https://www.reddit.com/r/MSIClaw/comments/1mo49iz/is_vrr_actually_working

Intel Arc B580 threads:
https://www.reddit.com/r/IntelArc/comments/1ntafmu/anyone_have_a_solution_for_this
https://www.reddit.com/r/IntelArc/comments/1nszyax/how_should_i_change_current_vrr_range
https://www.reddit.com/r/IntelArc/comments/1nvz9ek/intel_vrr_causing_flickering

Each of these cases shows the same ~50% floor rule and similar refresh instability near the VRR minimum threshold. Given that the affected devices include both mobile (Arc 140V) and desktop (Arc B580) implementations, the issue appears to stem from a shared VRR handling mechanism in the driver.

I’ll continue monitoring this thread for any updates or diagnostic requests. Please let me know if Intel engineering would like additional testing under specific conditions or firmware revisions. Thank you.

DeancR_Intel · ‎10-28-2025

Hi lenzx,

Thank you for your thorough testing with both driver versions. Your findings clearly demonstrate that this is a systemic issue affecting the Intel Arc graphics driver family rather than a device-specific problem.

The consistent 50% VRR floor pattern you've documented across multiple Arc devices (both mobile Arc 140V and desktop Arc B580) is particularly valuable evidence. Your cross-reference with Reddit reports showing identical behavior on different monitors confirms this is a driver-level limitation.

Could you please provide the EDID data from your MSI MAG274UPF monitor? You can extract this directly from Intel Graphics Command Center:

Open Intel Graphics Command Center
Go to Display tab
Select your MSI MAG274UPF monitor
Look for "Display Information" or "Monitor Details" section
Export or copy the EDID data

Having the raw EDID data will help me analyze exactly what VRR range information your monitor is advertising versus what the driver is actually implementing.

Once I have this information, I'll compile your comprehensive testing data along with the EDID analysis for further investigation.

Best regards,

Dean R.

Intel Customer Support Technician

lenzx · ‎10-28-2025

Hi Dean,

Thank you for following up with me again. I have attached a screenshot of the "Display Info" section within the "Display" tab of "Intel Graphics Software". Additionally I am attaching a zip compressed .bin file of my monitor's default/unmodified EDID which I have exported using Custom Resolution Utility (CRU).

I have been carrying out additional research and I discovered two existing threads in the Intel Community forum and Intel-GPU-Community-Issue-Tracker GitHub that directly relate to my issue:

https://community.intel.com/t5/Intel-ARC-Graphics/No-option-to-disable-adaptive-sync-plus-in-Intel-Graphics/m-p/1709331

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

In each of these threads there is a reference to using the old/legacy "Intel Graphics Command Center" Windows Store app to disable Adaptive Sync Plus (ASP). I followed these instructions and after disabling ASP I can confirm, via my monitor's OSD, that my refresh rate can reach the correct VRR floor of 48Hz. Prior to disabling ASP, my refresh rate would begin doubling as soon as it dropped below 72Hz. An option to disable ASP in the current "Intel Graphics Software" would solve this particular issue for me, but in my testing I noticed that my monitor's refresh rate behaves erratically when below 48Hz. With ASP disabled my monitor OSD shows the refresh rate jumping between seemingly random values and games stutter in this state. It is my understanding that ASP is Intel's Low Framerate Compensation (LFC) solution, and I can understand why the option to disable it was removed in recent driver software versions.

The issue that I and other users are facing is that ASP does not appear to incorporate sufficient logic to smooth out the LFC experience. I speculate that a simplified version of the current ASP logic looks like this:

VRR_ceiling = get_EDID_VRR_max()
VRR_floor = VRR_ceiling / 2
LFC_multiplier = 1
target_refresh = current_FPS

# Clamp to VRR ceiling
IF target_refresh > VRR_ceiling:
    target_refresh = VRR_ceiling

# Increase multiplier until refresh rate is within VRR range
while target_refresh < VRR_floor:
    LFC_multiplier = LFC_multiplier + 1
    target_refresh = current_FPS * LFC_multiplier

set_refresh_rate(target_refresh)

The issue with this logic is that when the FPS is hovering around the VRR_floor range, the monitor's refresh rate is rapidly jumping between double and triple digit numbers. In my case, the refresh rate might oscillate between far apart values such as 72 and 142, resulting in noticeable frame pacing issues. From what I can derive from the aforementioned Intel Community and IGCIT posts, this behavior is causing severe flickering for OLED monitor users.

I only have a basic understanding of these technologies, so I apologize if I am off base, but I would like to propose a possible solution to the oscillation issue by adding the following smoothing logic to the ASP algorithm:

VRR_ceiling = get_EDID_VRR_max()
VRR_floor = get_EDID_VRR_min()

# Use the previous multiplier value if available (defaults to 1 otherwise)
LFC_multiplier = get_LFC_multiplier()

# Set target refresh rate based on previous multiplier (stabilizes output)
target_refresh = current_FPS * LFC_multiplier

# Test if previous multiplier puts us out of VRR range. Recalculate if it does
IF target_refresh <= VRR_floor OR target_refresh >= VRR_ceiling:
    LFC_multiplier = 1
    target_refresh = current_FPS

    # Clamp to VRR ceiling
    IF target_refresh > VRR_ceiling:
        target_refresh = VRR_ceiling

    # Increase multiplier until refresh rate is within VRR range
    WHILE target_refresh < VRR_floor:
        LFC_multiplier = LFC_multiplier + 1
        target_refresh = current_FPS * LFC_multiplier

# Store the multiplier to smooth the next frame
set_LFC_multiplier(LFC_multiplier)

set_refresh_rate(target_refresh)

The result of storing and fetching the LFC_multiplier is that refresh rates will remain close in value until it is absolutely necessary to update the LFC_multiplier. For example, if my FPS drops from 48 to 47, the refresh rate will be set to 94, and if FPS increases to 48 in the next frame, then the refresh rate will be set to 96 instead of 48. The LFC_multiplier of 2 in this scenario will be enforced until FPS drops below 24 or rises above 72. This creates a sizable buffer zone where the FPS will be consistently multiplied by the same value until recalculation is necessary.

I am sure that there are other ways to achieve this "VRR smoothing" result. I hope that this proposed solution helps to convey the issue that I and other users are experiencing.

DeancR_Intel · ‎10-30-2025

Hi lenzx,

Thank you for this incredibly detailed and insightful analysis! Your technical investigation into the Adaptive Sync Plus (ASP) behavior and the proposed algorithmic solution demonstrates exceptional understanding of the underlying VRR implementation issues.

Your proposed LFC multiplier smoothing algorithm with buffer zones is a sophisticated approach to resolving the oscillation issue. The concept of storing and reusing the LFC multiplier until recalculation is absolutely necessary would indeed create more stable refresh rate behavior and reduce the jarring transitions between vastly different refresh rates.

Thank you for providing both the Intel Graphics Software screenshot and the CRU-exported EDID .bin file. This gives me the complete picture of what your monitor is advertising versus what the driver is implementing.

I'll review your comprehensive technical analysis internally, including your proposed algorithmic improvements. Your detailed documentation of the ASP behavior, the workaround discovery, and the proposed solution provides an excellent foundation for addressing this systemic issue affecting the Intel Arc graphics driver family. I'll get back to you once I have the necessary information you need.

Best regards,

Dean R.

Intel Customer Support Technician

CheezyFoodz · ‎11-25-2025

Hi,

I'm from the post you mentioned: https://community.intel.com/t5/Intel-ARC-Graphics/No-option-to-disable-adaptive-sync-plus-in-Intel-Graphics/m-p/1709331

I have found that when editing the VRR range with CRU, the VRR floor can be affected, but only by modifying the maximum value instead of the minimum value. For example, when I modify the range to be between 40-110 hertz instead of 40-120 hertz, the frames start doubling at 55fps instead of 60 fps. Obviously, the refresh rate will no longer go above 110 hertz however.

A solution that would be good enough for me would be to implement low framerate compensation the way I believe most non-intel GPUs implement it which is to only start doubling the refresh rate after fps goes below the minimum refresh rate of the display, such that on my 40-120 hertz tv once fps goes below 40 the framerate would double to 80 instead of doubling to 120 hertz at 60 fps. This would remove most flickering on OLEDs while in the VRR range while still having VRR support below the range (though there would still be flickering near 40fps due to it rapidly changing refresh rates from 40 to 80). Lenzx's solution would be the ideal solution if it can be implemented though so there would be minimum flickering at all fps.

Also about your experience with screen tearing with VRR on and V-Sync off, I believe it is normal for there to be slight tearing at the bottom of your screen when near the top of your VRR range based on this article: https://blurbusters.com/gsync/gsync101-input-lag-tests-and-settings/15/ (Second question on page).

Starhleo · ‎11-29-2025

Hi,

Thank you so much for your post Lenzx !

I am experiencing the exact same problem on my HP Omnibook 14 (Lunar Lake) with my 2880*1800 Oled panel. The minimum VRR range is locked at 60Hz (half of the 120Hz panel), instead of 48Hz. I was able to replicate this without difficulty on an external display.

Overall, VRR support appears to be broken in the current Intel drivers. Hopefully, a driver update will resolve this.

Domik101 · ‎12-15-2025

I have a same problem with Arc B580 and MSI mag 27CQF. Vrr should be 48Hz-180 and it's stuck at 90Hz-180Hz.

Intel support is not helping saying stuff like reinstall driver with DDU, disable and enable vrr and it's just not working. This is a driver problem, i didn't have this problem with AMD gpu. I would be glad for driver VRR fix.

toriko · ‎12-17-2025

Anyone else who has this issue please consider providing more information and let it be known this problem is effecting you at the following github intel issue tracker: https://github.com/IGCIT/Intel-GPU-Community-Issue-Tracker-IGCIT/issues/1173

The intel issue tracker github is generally better at reporting issues to driver engineers than these community forums so please leave a comment there mentioning this issue to hopefully get it fixed!

xelan · ‎02-14-2026

Same issue. Lenovo Yoga Slim 7i with Ultra 7 258V

Current Variable Refresh Rate: 60Hz - 120Hz

Maximum Variable Refresh Rate: 30Hz - 120Hz

This is with a built-in panel, not even an external desktop.

Tried everything possible but failed to bring the current variable refresh value down from 60-120 to 30-120.

The trick with disabling Adaptive Sync Plus (ASP) in the old Intel Graphics Command Center did NOT work for me.

Measured refresh rate with the Dynamic Refresh Rate Tool - it indeed doesn't go lower than 60Hz.

Dynamic Refresh Rate in Windows is enabled.

All drivers and software are the latest available.