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

[Michel Dänzer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

Should this extension specify how it interacts with the various
VK_PRESENT_MODE_* modes?


For one example: With VK_PRESENT_MODE_MAILBOX_KHR, does the period
specified by this extension correspond to:

a) The time between when the image is placed in the the queue of
pending presentation requests and when the next image is placed in the
queue

b) The time between when the image is taken from the queue to be
actually presented and when the same thing happens for another image
(which happens to be in the queue at the time)

c) Yet something else?

If it's a), given the extension talks about rounding to the nearest
upcoming frame, does VK_PRESENT_MODE_MAILBOX_KHR effectively behave
the same as VK_PRESENT_MODE_FIFO(_RELAXED)_KHR with this extension?

If it's b), there can be any number of images entering and leaving the
queue during the period, so it's not clear what purpose the period
would serve?


- -- 
Earthling Michel Dänzer               |               https://redhat.com
Libre software enthusiast             |             Mesa and X developer
-----BEGIN PGP SIGNATURE-----

iF0EARECAB0WIQSwn681vpFFIZgJURRaga+OatuyAAUCXkrQ9gAKCRBaga+Oatuy
AB2FAJ4glgpyMYSy1WPmbpzbI2O5Rvv0/QCfSeQBF7vsooAtjEBicmW76NfWWws=
=MzZO
-----END PGP SIGNATURE-----