[Mesa-dev] Playing with display timing -- VK_MESA_present_period
keithp at keithp.org
Tue Feb 4 19:32:03 UTC 2020
Michel Dänzer <michel at daenzer.net> writes:
>> actual_period = n * r - ε
> Is that still an issue if the (minimal) length of a vertical blanking
> period is subtracted from the computed period?
What you're doing is defining a 'window' of times which match the
desired frame -- any time within 'length of vertical blanking period' of
the actual top of frame matches that frame.
I'm simply making that window as large as possible by using 'half the
frame time' instead of 'length of vertical blanking period'.
> FWIW, one thing making "not before" semantics attractive is that
> they're easy to achieve in the kernel: It can just make sure the page
> flip isn't programmed to hardware before the target time.
Yup, offering only 'not before' makes it easy to implement in the
kernel, but very difficult for the application to get the right result.
For fixed refresh rate monitors, converting from 'nearest to time T' to
'not before frame count F' conversion can be done by rounding T/rate to F and
then using that to program the hardware using 'not before' semantics.
For variable refresh rate monitors, the computation will be slightly more
complicated as it may involve some multiple of a nominal frame rate
plus some stretching of the final frame.
> PresentOptionUST has never been functional, so there can't be any
> clients relying on specific semantics (other than being a no-op :) for
> it. Therefore, we could still change its semantics before making it
> functional, FWIW.
Oops. Someone should fix that :-)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 832 bytes
Desc: not available
More information about the mesa-dev