On Mon, Oct 29, 2018 at 05:37:49PM +0100, Michel Dänzer wrote:
> On 2018-10-26 7:59 p.m., Ville Syrjälä wrote:
> > On Fri, Oct 26, 2018 at 05:34:15PM +0000, Kazlauskas, Nicholas wrote:
> >> On 10/26/18 10:53 AM, Ville Syrjälä wrote:
> >>>
> >>> Speaking of timestamps. What is the expected behaviour of vblank
> >>> timestamps when vrr is enabled?
> >>
> >> When vrr is enabled the duration of the vertical front porch will be
> >> extended until flip or timeout occurs. The vblank timestamp will vary
> >> based on duration of the vertical front porch. The min/max duration for
> >> the front porch can be specified by the driver via the min/max range.
> >>
> >> No changes to vblank timestamping handling should be necessary to
> >> accommodate variable refresh rate.
> >
> > The problem is that the timestamp is supposed to correspond to the first
> > active pixel. And since we don't know how long the front porch will be
> > we can't realistically report the true value. So I guess just assuming
> > min front porch length is as good as anything else?
>
> That (and documenting that the timestamp corresponds to the earliest
> possible first active pixel, not necessarily the actual one, with VRR)
> might be good enough for the actual vblank event timestamps.
>
>
> However, I'm not so sure about the timestamps of page flip completion
> events. Those could be very misleading if the flip completes towards the
> timeout, which could result in bad behaviour of applications which use
> them for animation timing.
>
> Maybe the timestamp could be updated appropriately (yes, I'm hand-waving
> :) in drm_crtc_send_vblank_event?
Hmm. Updated how? Whether it's a page flip event or vblank even we won't
know when the first active pixel will come. Although I suppose if
there is some kind of vrr slew rate limit we could at least account
for that to report a more correct "this is the earliest you migth be
able to see your frame" timestamp.
Oh, or are you actually saying that shceduling a new flip before the
timeout is actually going to latch that flip immediately? I figured
that the flip would get latched on the next start of vblank regardless,
and the act of scheduling a flip will just kick the hardware to start
scanning the previously latched frame earlier.
scanout A | ... vblank | scanout A | ... vblank | scanout B | ... vblank
^ ^ ^ ^
| | flip C latch C
flip B latch B
vs.
scanout A | ... vblank | scanout B | ... vblank | scanout C | ... vblank
^ ^ ^ ^
| latch B | latch C
flip B flip C
The latter would seem more like a tearing flip without the tearing.
--
Ville Syrjälä
Intel
_______________________________________________
amd-gfx mailing list
amd-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
