-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2020-02-03 8:48 p.m., Keith Packard wrote: > Michel Dänzer <mic...@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----- _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
