I spent some time over the last week experimenting with a different way of doing frame timing.
Instead of specifying *when* a particular frame should be displayed, how
about we specify how *long* a particular frame should be made visible
to the user?
This has a couple of advantages over the approach taken in
GOOGLE_display_timing:
1. It provides information to the backend about frame timing
a frame earlier.
2. Missing a frame can generate fewer artifacts.
Here's what I'm thinking the extension would look like:
An application uses VK_MESA_present_period by including a
VkPresentPeriodMESA structure in the pNext chain in the
VkPresentInfoKHR structure passed to the vkQueuePresentKHR call.
typedef struct VkPresentPeriodMESA {
VkStructureType sType;
const void* pNext;
uint32_t swapchainCount;
const int64_t* pPresentPeriods;
} VkPresentPeriodMESA;
The fields in this structure are:
* sType. Set to VK_STRUCTURE_TYPE_PRESENT_PERIOD_MESA
* pNext. Points to the next extension structure in the chain (if any).
* swapchainCount. A copy of the swapchainCount field in the
VkPresentInfoKHR structure.
* pPresentPeriods. An array, length swapchainCount, of presentation
periods for each image in the call.
Positive presentation periods represent nanoseconds. Negative
presentation periods represent frames. A zero value means the
extension does not affect the associated presentation.
Nanosecond values are rounded to the nearest upcoming frame so that a
value of n * refresh_interval is the same as using a value of n
frames.
The presentation period causes *future* images to be delayed at least
until the specified interval after this image has been
presented. Specifying both a presentation period in a previous frame
and using GOOGLE_display_timing is well defined -- the presentation
will be delayed until the later of the two times.
I've got this kludged together to experiment with; I managed to make it
work purely within Vulkan using the infrastructure built for
GOOGLE_display_timing.
https://gitlab.freedesktop.org/keithp/mesa/commits/present-period
I wrote a longer article on my blog:
https://keithp.com/blogs/present-period/
I'm interested in hearing what people think about the general approach.
--
-keith
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
