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

[Michel Dänzer]

-----BEGIN PGP SIGNED MESSAGE-----
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
-----BEGIN PGP SIGNATURE-----

iF0EARECAB0WIQSwn681vpFFIZgJURRaga+OatuyAAUCXjlKiwAKCRBaga+Oatuy
ALsMAKCRxgfQa1zDXrLZ6iUnkl1+PtHqIQCgrFiNxQmRMye9B0t3RRXtr3dGjiY=
=lLMw
-----END PGP SIGNATURE-----