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

Michel Dänzer michel at daenzer.net
Tue Feb 4 10:42:19 UTC 2020

Hash: SHA1

On 2020-02-03 8:48 p.m., Keith Packard wrote:
> 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 - ε

Is that still an issue if the (minimal) length of a vertical blanking
period is subtracted from the computed period?

>> (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 see. Same question as above.

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.

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

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.

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

Thanks. For the record, that's
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3682 .

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


More information about the mesa-dev mailing list