New Vulkan Extension Could Enhance Frame Timing Controls For Games
Longtime X11 developer Keith Packard who has been working on various infrastructure improvements to the Linux desktop in recent years under contract for Valve has been eyeing the creation of a new Vulkan extension for dealing with frame timing behavior for Vulkan apps/games.
While there is already the Vulkan VK_GOOGLE_display_timing extension for dealing with frame/display timing, there are shortcomings when it comes the flexibility of the extension and its controls. Keith explained an example of VK_GOOGLE_display_timing's shortcomings, "Imagine the application is trying to render at 1/2 the native frame rate. Using GOOGLE_display_timing, it sets the display time for each frame by spacing them apart by twice the refresh interval. When a frame misses its target, it will be delayed by one frame. If the subsequent frame is ready in time, it will be displayed just one frame later, instead of two. That means you see two glitches, one for the delayed frame and a second for the "early" frame (not actually early, just early with respect to the delayed frame)."
Keith is proposing a new VK_MESA_present_period extension for having more control over the displaying of future images and addressing where VK_GOOGLE_display_timing comes up short.
Right now Keith's proposal is in the prototype stage along with an example Mesa implementation. He's seeking more feedback on this Vulkan Present-Period functionality and spells out all of the details on his blog.
While there is already the Vulkan VK_GOOGLE_display_timing extension for dealing with frame/display timing, there are shortcomings when it comes the flexibility of the extension and its controls. Keith explained an example of VK_GOOGLE_display_timing's shortcomings, "Imagine the application is trying to render at 1/2 the native frame rate. Using GOOGLE_display_timing, it sets the display time for each frame by spacing them apart by twice the refresh interval. When a frame misses its target, it will be delayed by one frame. If the subsequent frame is ready in time, it will be displayed just one frame later, instead of two. That means you see two glitches, one for the delayed frame and a second for the "early" frame (not actually early, just early with respect to the delayed frame)."
Keith is proposing a new VK_MESA_present_period extension for having more control over the displaying of future images and addressing where VK_GOOGLE_display_timing comes up short.
Right now Keith's proposal is in the prototype stage along with an example Mesa implementation. He's seeking more feedback on this Vulkan Present-Period functionality and spells out all of the details on his blog.
7 Comments