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

[Keith Packard]

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?

> The client may still need to use a fourth buffer if it wants to start
> rendering the next frame before the flip is complete and before the last
> submitted pixmap becomes idle. I can't think of any way around that
> offhand.

We can try it both ways and see what it looks like for real applications.

> So it might make sense to try the approach using async flips for now,
> and see how well that works in practice.

Right, having "real" async flips is a prerequisite for doing this, along
with sufficient mechanism to not request a flip until the buffer is
idle, without forcing the X server to stall in the flip kernel call
waiting.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 810 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20140603/1c42293a/attachment.sig>