[RFC v2] Wayland presentation extension (video protocol)

[Pekka Paalanen]

On Tue, 11 Feb 2014 12:03:41 -0800
Bill Spitzak <spitzak at gmail.com> wrote:

> I think in absolute time you are right, the "P" points do not move. 
> Instead everything else would move left by .5, resulting in the same 
> image I described with the vertical arrows always tilting to the right.
> 
> The green decision lines move left by .5 to align with the "P" points 
> since the decision is strictly whether a "T" is between two "P".
> 
> The "T" points move left by .5 because the client will have to timestamp 
> everything .5 earlier.
> 
> I still feel it would be less confusing to avoid negative numbers and to 
> match what I am pretty certain is mainstream usage of integer timestamps 
> on frames.

Ok, so what you are suggesting here is that we should change the whole
design to always have presentation come late with a mean delay of half
the refresh period (T/2) and the amount of delay being between 0 and T.

Just like you say, then the client will have to arbitrarily guess and
subtract T/2 always to be able to target the vblank at a P. Also note,
that since presentation feedback reports the time P, not P - T/2, the
clients really need to do the subtraction instead of just queueing
updates with target time t = P + n * T.

To avoid is hassle with "subtract T/2 or you will always be late", I
deliberately chose to have the mean delay zero, which means that
compared to a given target timestamp, presentation may occur between
t - T/2 and t + T/2, i.e. half a period early or late.

And this was not even my idea, Axel Davy pointed it out to me when I
was first going for the "always late" case.

So this is not just a technicality in drawing a diagram, no, this would
affect how clients need to be programmed. And doing it your way would
IMO be more complicated than my way, as you need to account for the T/2
instead of using the presentation feedback timestamps directly and
extrapolating with an integer multiple of the refresh period.

The timestamps may be integers, but they are in nanoseconds, so
dividing the refresh period by 2 is not a problem at all. Besides, in
your suggestion, the clients would need to compute T/2 and we would
have to document that "always subtract T/2 from your target timestamps
so you can on average have zero latency with presentation compared to
your actual target times".

I just want that if a client estimates that a vblank will happen at time
t, and it queues a frame with target time t well in advance, it will get
presented at the vblank at time t, not the vblank *after* t.

Your suggestion of t,t+1 may make sense if we queued updates with target
time given in MSC, but here we use UST-like clock values and can do
better, because the values are not limited to "integers" (integer
multiples of the refresh period). This is probably the source of
your uneasyness: all prior art that I know of uses frame counters, not a
clock, so yes, this is a different design.

Why have this different design? That question I replied in my original
RFCv2 email, the section "3. Why UST all the way?".

Thanks,
pq

> Pekka Paalanen wrote:
> > On Mon, 10 Feb 2014 12:20:00 -0800
> > Bill Spitzak <spitzak at gmail.com> wrote:
> > 
> >> Pekka Paalanen wrote:
> >>
> >>> This algorithm aims to start showing an update between t-T/2 and t+T/2,
> >>> which means that presentation may occur a little early or late, with
> >>> an "average" of zero. Another option would be to show the update between
> >>> t and t+T, which would mean that presentation would be always late with
> >>> an "average" of T/2.
> >> I think there would be a lot less confusion if this was described using 
> >> the t,t+1 model. I think in your diagram it would move the 'P' line .5 
> >> to the right so they line up with the green lines, and all the red 
> >> arrows would tilt to the right. It makes no difference to the result 
> >> (the same frames are selected) but I think makes it a lot easier to 
> >> describe.
> >>
> >> Another reason is that media starts at time 0, not time -.5*frame.
> > 
> > Hmm, I'm not sure. The green lines are not frame boundaries, they are
> > decision boundaries. In the picture, the points P are the exact time
> > when a framebuffer flip happens, which means that the hardware starts
> > to scan out a new image. Each image is shown for the interval
> > P[n]..P[n+1], not the interval between green lines.
> > 
> > So the green lines only divide the queue axis into intervals, that get
> > assigned to a particular P. Both axes are the same time axis, with
> > units of nanoseconds which are not marked. The black ticks on both axes
> > denote when a new frame begins.
> > 
> > Did we have some confusion here?
> > 
> > - pq