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

[Michel Dänzer]

On 2020-02-04 8:12 p.m., Keith Packard wrote:
> Michel Dänzer <michel at daenzer.net> writes:
> 
>> 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?
> 
> It's not asking the application to figure this out much earlier -- the
> application needs to know the target time for the next frame before
> starting any of the frame computations, and that happens right after
> submitting the previous frame.
> 
> The goal here is to provide the display system the timing information as
> soon as the application knows it, in case that helps the backend work
> better.

With variable refresh rate, it could certainly be useful for the kernel
to have this information as early as possible. It shouldn't make any
difference with fixed refresh though, since the kernel should always be
able to hit the next refresh in that case as long as the fences for the
flip signal in time for vertical blank.


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