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

[Michel Dänzer]

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

On 2020-02-03 9:16 p.m., Keith Packard wrote:
> "Matias N. Goldberg" <dark_sylinc at yahoo.com.ar> writes:
>
>> I read your article.
>
> Thanks!
>
>> What I feel are missing are just minor pesky details:
>
> Yes, it's definitely a rough draft at best. Figuring out the right
> words to make it do precisely what we want is hard, and I'm hoping
> we can first figure out what we want, then figure out how to say
> that precisely.
>
>> 1. Written as is, the frame being submitted is rounded up to
>> display timing, delaying *future* frames.But there is no way to
>> delay the *currently displaying frame* (i.e. the 'previous'
>> frame).
>
> Correct. The period provided controls how long the specified frame
> will be shown to the user (at a minimum). Future frames will be
> delayed by at least that long.
>
>> Right now if frame N was submitted without VkPresentTimeMESA but
>> frame N+1 is, then frame N+1 will be presented to screen ASAP.
>
> Correct.
>
>> What I'm saying is that if frame N was submitted without
>> VkPresentTimeMESA, then at frame N+1 I should be able to tell
>> 'keep frame N displayed for at least P nanoseconds since it was
>> displayed, and *then* present frame N+1, which is the frame I am
>> now submitting'
>
> That's not what this extension does; if you wanted frame 'N' to be
> displayed for 'P' nanoseconds, then you would specify 'P' when
> queuing frame 'N'.

Hmm, I didn't fully realize this in my reading of the draft, thanks
Matias for pointing it out!

That the timing of frame N+1 has to be specified when submitting frame
N for presentation is odd to me TBH. While I can imagine this might be
suitable for some apps such as video players, I'm skeptical about game
engines. They would need to calculate frame time budget and choose
simulation time for frame N+1 before submitting frame N for
presentation. Is that really how game engines (want to) work?


Instead, have you considered allowing the GOOGLE_display_timing
desiredPresentTime to be specified as a relative time, measured from
when the previous image of the swapchain was actually presented,
instead of as an absolute time? Could something like that also address
the motivation for VK_MESA_present_period?


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

iF0EARECAB0WIQSwn681vpFFIZgJURRaga+OatuyAAUCXjlKBwAKCRBaga+Oatuy
ADDxAJ49XUxG6tnAWuC/br12sORqQSBUyACgk7h1jf9fjjtMYvrkIfUnkcHwkqg=
=m2sK
-----END PGP SIGNATURE-----