[Mesa-dev] Playing with display timing -- VK_MESA_present_period

[Keith Packard]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20200201/b48171e9/attachment.sig>