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

Michel Dänzer michel at daenzer.net
Tue Jun 3 19:43:57 PDT 2014

On 04.06.2014 10:11, Keith Packard wrote:
> Chris Wilson <chris at chris-wilson.co.uk> writes:
>> Hmm, it appears to break flip elision.
> Right, you'd have to quad buffer to get flip elision with the current
> vblank-synchronized kernel flip call:
>         1)      buffer currently scanning
>         2)      buffer queued to the kernel for the next flip
>         3)      buffer with finished contents, waiting for flip or elision
>         4)      buffer being drawn to
> Now, when you ask to swap, you can switch 3) and 4) and draw another
> frame.
> If you go back to always using async flips, then you can do:
>         1)      buffer current scanning
>         2)      buffer queued *in the X server* for the next flip
>         3)      buffer being drawn to
> Now, when you ask to swap, you can switch 2) and 3) and draw another
> frame. The X server will immediately flip to whatever buffer is in spot
> 2) down to the kernel when it gets the appropriate vblank event.
> The hacks I had for immediate swaps aren't really done though -- we
> actually want to flip to whichever buffer is actually done rendering,
> not which one has been sent to the X server for display; presumably the
> rendering commands for that buffer are still sitting on the GPU ring
> happily executing away.
> So, what we need to do is:
>         1)      Fix the kernel to use MMIO flips so there isn't
>                 any ring latency when doing an immediate flip. This
>                 will also require that we wait for rendering to complete
>                 before performing the MMIO register write; presumably
>                 we'll want to avoid doing that in the calling thread.

FWIW, you can see both the current and future way the radeon driver does
this in Christian's patch
http://lists.freedesktop.org/archives/dri-devel/2014-June/061107.html .

>         2)      present_pixmap shouldn't expect to be able to flip to a
>                 pixmap until it knows that the pixmap is actually idle.
>                 That means that you can't actually replace the buffer
>                 queued in the X server for the next flip until the
>                 incoming rendered buffer is idle.
> What I don't know is whether 2) can be done up in the X server, or if we
> are going to end up coding a bunch of this into the kernel.

At least the waiting for the pixmap to become idle part should be
perfectly possible in the X server?

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.

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.

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

Earthling Michel Dänzer            |                  http://www.amd.com
Libre software enthusiast          |                Mesa and X developer

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 234 bytes
Desc: OpenPGP digital signature
URL: <http://lists.x.org/archives/xorg-devel/attachments/20140604/e32a813c/attachment.sig>

More information about the xorg-devel mailing list