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

[Michel Dänzer]

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>