Repository navigation
Support VK_EXT_frame_boundary in addition to vkQueuePresent #36
Description
We currently only detect frames when the application submits to a present queue. For some use cases, including headless test builds on llvmpipe, this never happens. To support these use cases we should expose the VK_EXT_frame_boundary extension to allow applications to manually indicate frame boundaries.
Activity
solidpixel commentedon Dec 8, 2025
Summary of required changes.
The layer needs to expose the extension availability via
vkGetPhysicalDeviceFeatures2(), storing whether the driver supported it in the layer per-instance config, and overriding the value return to the driver to indicate that it's enabled even if the driver doesn't support it.On calls to
vkCreateDevice(), if the underlying driver did not support the extension, we must remove the extension enable structure from the list passed to the driver by editing safe-struct copy of the create info that we then pass to the driver.On calls to
vkCreateDevice(), if the underlying driver did not support the extension, we must remove the extension enable structure from the list passed to the driver by editing safe-struct copy of the create info that we then pass to the driver.On calls to
vkQueueSubmit(),vkQueueSubmit2()(and KHR version),vkQueuePresentKHR(), andvkQueueBindSparse(), we need to monitor the frame ID and use that to trigger frame boundaries in the layer. If the driver did not expose support for the frame boundary extension, we must remove the extension structure from the parameter structure passed down to the driver.Note, the current protocol for Mali Timeline assumes that frames are monotonically increasing, and cannot handle multiple in-flight frames that are concurrently using Vulkan from different threads.