[PATCH] present: Queue flips for later execution. Begging for review.

[Pekka Paalanen]

On Wed, 04 Jun 2014 10:39:18 +0200
Christian König <deathsimple at vodafone.de> wrote:

> Am 04.06.2014 09:03, schrieb Pekka Paalanen:
> > On Tue, 03 Jun 2014 20:08:21 -0700
> > Keith Packard <keithp at keithp.com> wrote:
> >
> >> Michel Dänzer <michel at daenzer.net> writes:
> >>
> >>> At least the waiting for the pixmap to become idle part should be
> >>> perfectly possible in the X server?
> >> One of three possible ways:
> >>
> >>   1) Blocking kernel call waiting for buffer idle.
> >>      This doesn't seem like what we want.
> >>
> >>   2) Receive a DRM event when a buffer is idle
> >>      Does this event even exist today?
> >>     
> >>   3) Polling for idle when receiving a vblank event.
> >>      This will work fine for vblank-synchronized flips; we
> >>      simply check whether the next queued buffer is idle and delay the
> >>      flip by a frame if it isn't.
> >>
> >>> For flip elision with non-async flips, something like
> >>> DRM_MODE_PAGE_FLIP_REPLACE (and possibly a corresponding DRM event
> >>> signaling the previous flip was canceled, if DRM_EVENT_FLIP_COMPLETE is
> >>> inappropriate for that) might work, which would replace any pending flip
> >>> with the new one.
> >> Do we just want to send the MSC count to the kernel so it "knows" which
> >> frame we want the contents presented at?
> > Hi,
> >
> > that is starting to sound a lot like queueing display updates in the
> > kernel. Let me jump a few (couple?) years to the future and speculate
> > wildly, likely going off-topic. ;-)
> >
> > I think the whole concept of MSC will be breaking down, as we are
> > getting dynamic/variable refresh displays (G-SYNC, FreeSync). MSC will
> > no longer correspond to the true real time at all (bye bye A/V sync),
> > not even for the very next vblank which might happen any time from 5 to
> > 500 ms from the previous vblank. (That is one reason why I designed the
> > Wayland Presentation extension (still RFC [1]) around timestamps
> > instead of frame counters.) We'd need a way to tell DRM when we would
> > like the next vblank to happen.
> 
> Agree totally, even today we have a number of problems with MSCs.
> 
> For example try to move a video from one monitor to another. Since the 
> state tracker doesn't know of the window move we send out MSCs for the 
> wrong display device. In the best case this results in just displaying a 
> frame way to early, in the worst we stall for a quite long time until 
> the other device reaches the MSC counter of the first one.
> 
> > DRM universal planes + atomic modesetting / nuclear pageflip is already
> > aiming to gather at least a per-head update into a single atomic set of
> > state changes. Once we have that, we might extend that to allow
> > queueing in the kernel for more than just the very next update. The how
> > is totally open, and the benefits are not clear at least to me yet. I
> > suspect you'd also need a way to cancel some or all queued updates - I
> > suppose you'd want that already - and to get feedback per submission on
> > was it actually presented and when.
> >
> > This is just some food for thought, nothing more.
> 
> I'm not sure if we want to queue things up in the kernel.

Right. I'm not sure either. It might seem logical to push the queue
even closer to the hardware for better guaranteed timely processing, but
then it also becomes harder to manage from user space, plus adding
complexity to the kernel, not to mention needing more buffers again.

> I think just providing a timestamp when the frame should be first 
> visible like VDPAU does is the right way to go.

Right, and I believe it is important the kernel driver can choose which
clock to use for everything, like we now have CLOCK_REALTIME vs.
CLOCK_MONOTONIC for DRM flip/vblank events. I assume that would make
things simpler all around?

As I understand, VDPAU uses the "not before" semantics with the target
timestamp. That means that to hit a certain predicted vblank on a
constant refresh rate system, an application has to subtract an
arbitrary "margin" number from the predicted vblank time. Otherwise
inaccuracies may cause you to miss the vblank due to strict "not
before" semantics. But if the refresh rate is dynamic, the driver could
choose to have the "vblank" at exactly the requested time, which would
be too early by the chosen margin.

I'm not sure if that really matters, but it made me choose the "nearest
vblank" semantics for Wayland Presentation, by default at least. The
target time would be approximate rather than a strict not-before, which
means you can just use the same value regardless of constant vs.
dynamic refresh.

What do you think?

> Adding a flag that a waiting flip request should be replaced by another 
> one instead of running into an error should be enough to handle the 
> triple (or quad) buffered case as well.

Yes, that sounds good to me. It would replace the earlier atomic
property set commit as a whole, regardless of any timestamps.

There should also be DRM events telling what actually happened, did the
earlier set get applied or replaced. If the earlier set got applied,
then the new set would apply only on the next vblank (if syncing).


Thanks,
pq