Variable frame intervals when using VK_PRESENT_MODE_FIFO_KHR on adaptive‑sync displays

Direct answer

No. VK_PRESENT_MODE_FIFO_KHR does not guarantee a constant CPU-to-GPU present interval when the display's refresh rate changes dynamically. The Vulkan specification models FIFO as a traditional vertical-sync queue, but it leaves the exact present timing on variable-refresh-rate (VRR) hardware to the driver implementation.

Confirmed facts

• The Vulkan specification requires FIFO to block the application when the present queue is full, but it does not define a fixed interval between vkQueuePresentKHR calls on adaptive-sync panels.
• On a VRR display, the presentation engine follows the display's current refresh cycle. When that cycle length changes, the effective throttle interval changes with it.
• Frame duplication in FIFO typically occurs when the GPU has not finished a new image before the display's next vertical blanking interval (VBI).
• Frame dropping is less common in FIFO than in VK_PRESENT_MODE_MAILBOX_KHR or VK_PRESENT_MODE_IMMEDIATE_KHR because FIFO queues images and blocks the producer rather than overwriting or bypassing the queue.

Likely explanation

The jitter you observe is probably caused by the display controller's internal VRR range logic rather than a Vulkan API failure. When the monitor adjusts its refresh rate, the driver's presentation scheduler aligns to the new timing. If the GPU misses a VBI, the driver may repeat the last image; if the queue is full, it may drop a present opportunity. Because the Vulkan specification does not mandate a specific duplicate-versus-drop policy, each IHV driver chooses its own heuristic.

Steps to verify

1. Pin the display to a fixed refresh rate (disable FreeSync/G-Sync) and measure frame intervals with the same workload. If the jitter disappears, the display controller is the source.
2. Re-enable VRR and compare the same workload. A stable interval under fixed refresh and variable interval under VRR confirms that FIFO is following the display, not enforcing a constant CPU cadence.
3. Use a hardware frame analyzer or high-speed camera for ground-truth photon timing; CPU-side timestamps alone cannot distinguish GPU completion from actual scan-out.
4. If your platform exposes a display-control extension, use it to query presentation timing directly. Availability and behavior are platform-dependent.

One diagnostic that changes the recommendation

Which GPU vendor and driver version are you testing? The duplicate-versus-drop behavior and the exact VRR handshake are implementation-defined, so a vendor-specific driver version is necessary before suggesting a concrete workaround.