[Mesa-dev] Playing with display timing -- VK_MESA_present_period
keithp at keithp.org
Tue Feb 4 19:12:07 UTC 2020
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
> 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?
Yes, that would avoid the display problem.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 832 bytes
Desc: not available
More information about the mesa-dev