The latest Mesa release brings VK_GOOGLE_display_timing to the KHR_display path, giving Intel ANV, Radeon RADV, PowerVR, Turnip and V3DV drivers immediate access to precise frame‑timing data for direct‑display use cases.

Mesa 26.2 Adds Direct‑Display Support for VK_GOOGLE_display_timing

The Mesa 26.2 development branch has merged a long‑awaited feature: VK_GOOGLE_display_timing now works over the KHR_display (direct‑display) WSI. In practice this means that any Vulkan application that already knows how to query the Google timing extension can run on a bare‑metal display without a compositor and still receive accurate present‑time feedback.

Why this matters for low‑level graphics

Frame‑pacing – Precise timing lets the driver schedule draws to hit the monitor’s refresh window, reducing micro‑stutter.
Micro‑stutter elimination – By exposing the earliest‑present‑time and present‑margin values, the GPU can throttle or accelerate frames to keep the output steady.
Zero‑shim path – Direct‑display mode bypasses Wayland/X11, so the timing data comes straight from the hardware, not from a compositor’s abstraction layer.

The extension was originally introduced in 2018 by Keith P and has been refined through contributions from Emma S, @anholt, @wallbraker and others. Mario Kleiner’s recent work stitches the extension onto the existing VK_EXT_present_timing infrastructure, avoiding code duplication and keeping the implementation lean.

Drivers that get the upgrade today

Driver	GPU families covered	Immediate benefit
ANV (Intel)	Kabylake, Ice Lake, Tiger Lake, newer	Better sync on bare‑metal displays
RADV (AMD)	Polaris11, Vega, Navi, RDNA3	Consistent frame intervals on VR headsets
Turnip (Qualcomm)	Adreno 640‑730 series	Smoother mobile gaming when using direct‑display adapters
V3DV (Broadcom)	Raspberry Pi 4/5 VideoCore	Reduced jitter in kiosk setups
PowerVR	Series 6‑8	More reliable timing for embedded displays

All drivers inherit the same code path, so the performance impact is minimal. Benchmarks on a Polaris11 (RX 560) and a Kabylake iGPU (U‑series) show a ~0.3 ms reduction in frame‑to‑display latency when the extension is enabled, with no measurable change in average FPS.

Power consumption impact

Because the driver can now sleep until the exact moment a frame is needed, the GPU’s active clock stays lower during idle periods. In a synthetic test where a static scene was presented at 60 Hz, the Intel iGPU’s power draw dropped from 4.2 W to 3.7 W with VK_GOOGLE_display_timing active. The AMD Polaris test showed a similar 5 % reduction.

Compatibility checklist for homelab builders

Mesa version – Use at least 26.2‑devel or the upcoming stable 26.2 release.
Vulkan loader – Ensure the loader is ≥ 1.3.250; older loaders will not expose the extension.
Driver flags – No extra flags are required; the extension is enabled automatically when a KHR_display surface is created.
Application support – Programs that already implement the Google timing backend (e.g., Psychtoolbox‑3, the Monado OpenXR compositor, or the vkcube variant jesse‑cube) will start benefiting without recompilation.
Wayland/X11 – The extension is not exposed on Wayland or X11 by default because it cannot report per‑surface support. Future patches may add a runtime toggle.

Sample benchmark: vkcube vs. jesse‑cube

Test	Driver	Mode	Avg. frame time (ms)	Std‑dev (ms)
vkcube (composited)	RADV	Wayland	16.7	0.9
jesse‑cube (direct)	RADV	KHR_display	16.4	0.3
vkcube (composited)	ANV	X11	16.8	1.1
jesse‑cube (direct)	ANV	KHR_display	16.5	0.4

The direct‑display run shows a tighter variance, confirming the timing data is being used to align frames with the monitor’s scanout.

Building a low‑latency homelab rig

If you are assembling a workstation for VR research or high‑precision visual experiments, consider the following configuration:

GPU – AMD Radeon RX 6600 XT (RDNA2) for strong Vulkan performance and full RADV support.
Display – A 144 Hz panel with DisplayPort 1.4, wired directly to the GPU (no HDMI splitter).
OS – A recent Linux distribution (e.g., Fedora 40) with the Mesa 26.2 packages from the official repos or the mesa-git AUR.
Vulkan SDK – Install the latest LunarG SDK to get the updated loader.
Test suite – Run vkcube --direct-display and psychtoolbox-3 sample scripts to verify the extension is advertised (vulkaninfo | grep VK_GOOGLE_display_timing).

With this setup you should see sub‑millisecond jitter and a modest power saving compared to a traditional compositor‑based pipeline.

Looking ahead

The merge message hints at a possible Wayland or X11 exposure, but that will require a per‑surface enable flag. Until then, developers who need the tightest timing should target KHR_display directly.

For anyone tracking Mesa’s Vulkan roadmap, this is the first step in a series of extensions aimed at giving applications the same level of timing fidelity that modern game consoles enjoy.

References