[Mesa-dev] Playing with display timing -- VK_MESA_present_period
keithp at keithp.org
Mon Feb 3 19:48:24 UTC 2020
Michel Dänzer <michel at daenzer.net> writes:
> Instead of rounding to the nearest upcoming frame, should it round to
> the earliest frame after the specified period has passed? As written, it
> seems to contradict the next paragraph below:
Sorry for the poor wording; let me describe what I want informally here.
For nanosecond periods to be easy to use on fixed-refresh-rate monitors,
I want the näive computation to "just work". For a given refresh period,
'r', I want to select a period of 'n' frames using:
computed_period = n * r
Because of clock skew and rounding problems, it's quite possible that
the period could easily end up being just slightly smaller than that:
actual_period = n * r - ε
When I said 'nearest', what I intended to describe was that the target
frame would be as close as possible to the specified time.
> (I'm not ruling out that rounding to nearest might be better, but there
> should be a rationale for it, which also justifies being inconsistent
> with GOOGLE_display_timing)
Yes, this is intentionally inconsistent with GOOGLE_display_timing,
which I believe is hard to use correctly.
By specifying not before semantics, GOOGLE_display_timing requires
applications compute a fake time guaranteed to be not after the actual
target frame time. This really messes things up when you might have
variable refresh rate monitors.
I just went and read the time-based stuff from the X Present
extension. That uses 'nearest' semantics too, when supported by the
driver. When not supported, the server gets to do whatever it likes
> I like this extension in general.
Thanks! I've been trying to get this posted for a few months now.
> However, I think allowing the period to be specified in frames might be
> a mistake, because it won't work well with variable refresh rate. But
> it'll be tempting for application / toolkit developers not to bother
> with proper time calculations but to just use frames instead. (It would
> be good to seek feedback on this from AMD DC developers and the larger
> DRM kernel driver community as well)
Yeah, given that the application will need the refresh period to know
what to display, it certainly doesn't provide much technical benefit
I stuck it in to make the extension feel like GL's swap interval stuff
(although it isn't the same), and because it seemed like a 'nice' thing
to offer applications.
> P.S. It would be good to create a WIP merge request for this in the main
> Mesa project, to have a central place for gathering feedback and
> tracking progress.
Done, thanks for the suggestion.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 832 bytes
Desc: not available
More information about the mesa-dev