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

Michel Dänzer michel at daenzer.net
Tue Feb 4 10:40:19 UTC 2020

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


More information about the mesa-dev mailing list