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

[Keith Packard]

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
(oops!).

> 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
here.

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.

-- 
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20200203/f5bf4c9e/attachment.sig>