Mesa 26.2 Lands VK_GOOGLE_display_timing Support For Direct Display Mode
The VK_GOOGLE_display_timing extension for obtaining display timing information that can be useful for frame-pacing and eliminating micro-stuttering in games now has direct display mode support with KHR_display for the Mesa Vulkan drivers. This now merged addition immediately benefits the Intel ANV and Radeon RADV drivers as well as the PowerVR, Turnip, and V3DV drivers too.
Open-source developer Mario Kleiner worked on this VK_GOOGLE_display_timing for KHR_display support in recent weeks, building off prior work of other Mesa developers stretching all the way back to 2018 with the original VK_GOOGLE_display_timing work. This modern support is built off the existing VK_EXT_present_timing extension.
Mario explained in the Mesa merge request that hit Mesa 26.2-devel this past week:
This VK_GOOGLE_display_timing support for KHR_display for Intel ANV, PowerVR, Radeon RADV, Qualcomm Adreno Turnip, and Broadcom V3DV is now merged for next quarter's Mesa 26.2 feature release.
Open-source developer Mario Kleiner worked on this VK_GOOGLE_display_timing for KHR_display support in recent weeks, building off prior work of other Mesa developers stretching all the way back to 2018 with the original VK_GOOGLE_display_timing work. This modern support is built off the existing VK_EXT_present_timing extension.
Mario explained in the Mesa merge request that hit Mesa 26.2-devel this past week:
"This implements the VK_GOOGLE_display_timing extension for VK_KHR_display, aka vulkan/wsi/display or direct display mode.
It was inspired and initially based on the work of @anholt from late 2025, which itself is based on @keithp work from 2018, but rebased on top of Mesa 26.2-devel and then incrementally rewritten to turn it mostly into a fronted, which sits on top of the code/infrastructure of @themaister that implements VK_EXT_present_timing for VK_KHR_display, so we can avoid code duplication as much as possible.
By now only trace amounts of Keith and Emma's code are left, one slightly fixed enablement commit by Emma and a handful lines of original code by Keith for calculation of timing feedbacks .earliestPresentTime and .presentMargin for FRR displays.
This so far has been tested successfully by myself on a AMD Polaris11 and Intel Kabylake gpu with Psychtoolbox-3 (which has a mature VK_GOOGLE_display_timing backend since 2021, used and tested on the macOS Khronos MoltenVK Vulkan ICD, and on various earlier Linux iterations of VK_GOOGLE_display_timing by @keithp, @wallbraker, @anholt and myself. Also with "jesse-cube" a direct display enabled variant of vkcube. And the Mesa CI ofc.
The benefits of having VK_GOOGLE_display_timing in addition to the more powerful and flexible VK_EXT_present_timing would be to enable existing software with mature and well tested VK_GOOGLE_display_timing backend to immediately use the new timing goodness without immediate extra application porting effort. E.g., Psychtoolbox-3, the VR compositor of the OSS Monado OpenXR runtime, vkcube and probably other demos or apps.
A possible future followup would be to maybe also enable it on Wayland or native X11. This would need some "default off" / "don't expose extension" setting, with some driconf setting to conditionally expose the extension to suitable apps. VK_GOOGLE_display_timing can't report back its support on a per-surface basis like VK_EXT_present_timing, so unconditionally exposing it on all Wayland implementations or on X11 + XWayland wouldn't work. A similar approach was taken in earlier Mesa releases for VK_KHR_present_wait."
This VK_GOOGLE_display_timing support for KHR_display for Intel ANV, PowerVR, Radeon RADV, Qualcomm Adreno Turnip, and Broadcom V3DV is now merged for next quarter's Mesa 26.2 feature release.