GPU Idle Power Draw and Multi-Monitor Setups: Why High Refresh Displays Increase Idle Wattage
Idle power on a modern graphics card is supposed to sit in the single digits. Add a second monitor, especially a high refresh one, and the card can jump to 20 or more watts doing nothing at all. Here is what actually forces the memory clock to stay up.
Measure a single RTX or Radeon card at the Windows desktop with one 1440p 165Hz monitor attached and you will typically see 8 to 15 watts on the power draw sensor in HWiNFO64. Add a second monitor, particularly one running a different refresh rate or resolution, and that number can climb to 40 or even 60 watts without a single application open. Nothing about the workload changed. What changed is the GPU's ability to drop its memory clock into a low-power state.
The root cause sits in how the display controller schedules memory fetches for each connected screen. Every monitor has a blanking interval—the gap between when one frame finishes scanning out and the next one starts. The GPU can only safely downclock VRAM during a window when none of the attached displays are actively reading from the frame buffer. With one monitor, that window is predictable and the driver parks the memory clock at its lowest P-state for most of the idle period. With two monitors running different refresh rates, the blanking intervals rarely line up, so the driver keeps the memory controller running near its maximum clock continuously to guarantee no display ever misses a scanout window.
Which Configurations Trigger High Idle Power
Not every multi-monitor setup causes this. The behavior depends heavily on how closely the timings match between displays.
| Configuration | Typical Idle Power | Why |
|---|---|---|
| Single 1440p 165Hz monitor | 8–15W | Memory clock parks at lowest P-state |
| Two identical 1440p 165Hz monitors | 10–18W | Matching timings allow overlapping blanking windows |
| 1440p 165Hz + 1080p 60Hz | 35–55W | Mismatched refresh rates prevent overlap |
| 4K 144Hz + 1440p 165Hz | 45–70W | High bandwidth demand plus mismatched timing |
| Three mixed-resolution monitors | 50–80W | No shared blanking window across all three |
The pattern is consistent across both NVIDIA and AMD cards, though the exact wattage differs by architecture. Cards with larger VRAM buses (GDDR6X on higher-end NVIDIA parts, for example) tend to show a bigger idle penalty than narrower-bus cards, because the memory controller has more channels to keep active.
Practical Fixes
The most reliable fix is matching refresh rates across all connected displays, even if that means running your secondary monitor a few Hz below its native maximum. Setting a 165Hz primary and a 144Hz secondary monitor to both run at 120Hz, for instance, often restores the low-power idle state because the driver can find a common blanking window.
- Set all monitors to the same refresh rate in Windows Display Settings, even if one panel supports higher.
- Where possible, keep resolutions similar; large resolution mismatches between displays widen the timing gap further.
- On NVIDIA cards, disabling and re-enabling a display sometimes forces the driver to recalculate the shared timing window after a driver update changes behavior.
- Custom Resolution Utility (CRU) can adjust a monitor's blanking interval directly, which is a more surgical fix than changing refresh rate, but it requires care since incorrect timings can cause a monitor to go black until reset.
Confirming What Is Actually Happening
Before changing anything, confirm the memory clock is the cause rather than something else, like a background application preventing the GPU from entering a low-power state. Open HWiNFO64, expand the GPU sensor tree, and watch the memory clock value while toggling a second monitor on and off. If the memory clock jumps from around 400-800MHz up to its full boost value (often 1750-2500MHz depending on the card) the moment the second display connects, this behavior is confirmed. If the memory clock stays low but power still rises, the cause is more likely a browser hardware-accelerating video decode or a game overlay keeping the GPU engine partially active, which is a separate problem.
This idle power difference matters more than it might seem for anyone running a system continuously, since idle time typically dominates total runtime on a desktop that is left on. Fifty extra idle watts running 16 hours a day adds up to a noticeable amount on an electricity bill over a year, and it also means more fan spin-up cycles and slightly higher ambient case temperature even when nothing demanding is running.
A Real Example Worth Testing
One configuration worth specifically testing if you suspect this issue: a primary 1440p 165Hz monitor paired with a secondary 1080p 60Hz monitor used mainly for chat, monitoring, or a browser window. This is an extremely common combination in home offices and gaming setups, and it is also one of the worst-case scenarios for idle power, since 60Hz and 165Hz share almost no common blanking window across a reasonable observation period. Owners who have run this exact pairing and later switched the secondary monitor to also run at 120Hz or 165Hz (even though its native panel might be rated lower) have reported idle power dropping by 20 to 40 watts, confirmed on a wall meter rather than just the in-game overlay reading, which can lag or average out short-term spikes.
It is also worth checking whether the secondary display is connected through the same GPU output type as the primary. Some driver versions handle mixed DisplayPort and HDMI configurations differently than two displays on the same connector type, and a firmware or driver update can change this behavior release to release without it being called out prominently in the patch notes. If idle power was fine on one driver version and rose after an update with no hardware changes, checking the release notes for memory clock or multi-monitor power management changes is a reasonable next step before assuming a hardware fault.