[PATCH] present: Queue flips for later execution. Begging for review.
Keith Packard
keithp at keithp.com
Tue Jun 3 18:11:28 PDT 2014
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.
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.
> When combined with Frank's patches it also stops unflipping upon
> window destruction.
I don't think Frank's patches are correct.
--
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/4fefd6d6/attachment.sig>
More information about the xorg-devel
mailing list