# WDDM, HAGS and MPO: why 'stutter' is not a frame rate problem

> How the Windows display stack composes frames, what hardware-accelerated GPU scheduling and multi-plane overlays change, and how to test the difference.

**Tested on**

- Build: 26300.9457
- Edition: Pro (26H2)
- Architecture: x64
- Evidence: E1
- Verified: 2026-10-29

## The short answer

Three layers decide what you see, and only one of them is the game:

1. **WDDM** — the Windows Display Driver Model: how the OS schedules GPU work and manages memory.
2. **Composition** — DWM combines every window into the frame the display receives.
3. **Presentation** — flip, overlay, or copy: how that frame reaches the panel.

"Stutter" usually means **the frame pacing broke**, not that the average frame rate dropped. A 120 fps average with one 80 ms frame every few seconds looks worse than a steady 90 fps.

## The three names people mix up

| Term | What it is | What it changes |
|---|---|---|
| **WDDM 3.x** | driver model version | scheduling, memory management, feature availability |
| **HAGS** (hardware-accelerated GPU scheduling) | lets the GPU manage its own command queue | lower CPU overhead, different pacing behaviour |
| **MPO** (multi-plane overlay) | display hardware composes layers instead of DWM copying them | power and latency, but a source of flicker/stutter bugs |

HAGS and MPO are **features of the stack**, not settings that are universally better. Both have had driver-specific bugs where disabling them fixes stutter.

## Where MPO bites

With MPO, the display controller can overlay a video or a game window directly instead of DWM composing everything into one surface. That saves power and latency — and it means the driver's overlay path is now in the critical path.

Symptoms attributed to MPO:

- flicker or a brief black frame when a video starts;
- stutter only when a browser plays video in a window;
- a cursor or overlay that tears;
- multi-monitor setups behaving differently from single-monitor.

The standard diagnostic is to disable MPO through the driver's registry switch (a per-vendor key under the display adapter class) and see whether the symptom disappears. That is a **diagnostic**, not a permanent fix — you lose the power benefit.

## Check what the stack is doing

```powershell
# WDDM version and driver details
Get-CimInstance Win32_VideoController | Select-Object Name,DriverVersion,DriverDate,VideoModeDescription
dxdiag /t $env:TEMP\dxdiag.txt

# GPU engine utilisation per process (Windows 10 1709+)
Get-Counter '\GPU Engine(*)\Utilization Percentage' -MaxSamples 2
```

`dxdiag` reports the driver model and feature levels per adapter. The counters show whether one process is saturating a copy engine — a classic sign that the composition path is doing work it should not.

## Frame pacing, measured honestly

To talk about stutter you need frame times, not averages:

- present intervals (time between frames), not fps;
- **99th percentile** or worst-frame time, not the mean;
- the same scene, same settings, same driver, several runs.

Windows' own tools are weak here. GPU vendor overlays and frame-time capture tools give per-frame data; anything that only shows an average cannot distinguish smooth from stuttery.

> **Caution: Do not benchmark across driver versions casually**
>
> A driver update changes clocks, power behaviour and the composition path at once. Comparing "before/after" without pinning power plan, temperature and scene makes the result meaningless — see the measurement discipline for hardware pages.

## When to change a setting

| Symptom | Try first |
|---|---|
| Stutter only with video in a window | test with MPO disabled to confirm, then check driver updates |
| High CPU in games with a fast GPU | HAGS on (if the driver supports it) |
| Black flicker on alt-tab | MPO/driver, not Windows settings |
| Stutter on one monitor only | cable/link bandwidth, then MPO |
| Consistent low fps | GPU load, thermals, power limit — not the stack |

Change one thing at a time, and write down what you changed. The stack has enough moving parts that two simultaneous changes teach you nothing.

## Related

- [AMD Radeon drivers](https://winbook.fyi/en/hardware/gpu/amd-drivers/)
- [Driver rollback](https://winbook.fyi/en/hardware/gpu/driver-rollback/)
- [Monitor choice and VRR](https://winbook.fyi/en/hardware/display/monitor-choice/)

## Lab boundary

E1. The stack behaviour is documented by Microsoft. The lab runs a virtual display adapter, which has no MPO or HAGS path, so no stutter was reproduced and no frame-time data is published.

## Sources

- [Microsoft Learn — Hardware flip queue](https://learn.microsoft.com/en-us/windows-hardware/drivers/display/hardware-flip-queue)
- [Microsoft Learn — Multiplane overlay support](https://learn.microsoft.com/en-us/windows-hardware/drivers/display/multiplane-overlay-support)
- [Microsoft Learn — DXGI 1.6 improvements](https://learn.microsoft.com/en-us/windows/win32/direct3ddxgi/dxgi-1-6-improvements)

---

Source: https://winbook.fyi/en/hardware/gpu/wddm-hags-mpo/