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

[Michel Dänzer]

On 2020-02-02 7:51 a.m., Keith Packard wrote:
> 
> 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.

Instead of rounding to the nearest upcoming frame, should it round to
the earliest frame after the specified period has passed? As written, it
seems to contradict the next paragraph below:

(I'm not ruling out that rounding to nearest might be better, but there
should be a rationale for it, which also justifies being inconsistent
with GOOGLE_display_timing)


>     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.

Repeating my comment on
https://gitlab.freedesktop.org/keithp/mesa/commit/c81c6ffe335032d7c88b68f83360597f7dfd5b60
(hadn't got to this post yet):


I like this extension in general.

However, I think allowing the period to be specified in frames might be
a mistake, because it won't work well with variable refresh rate. But
it'll be tempting for application / toolkit developers not to bother
with proper time calculations but to just use frames instead. (It would
be good to seek feedback on this from AMD DC developers and the larger
DRM kernel driver community as well)

P.S. It would be good to create a WIP merge request for this in the main
Mesa project, to have a central place for gathering feedback and
tracking progress.
-- 
Earthling Michel Dänzer               |               https://redhat.com
Libre software enthusiast             |             Mesa and X developer