On 04.06.2014 10:11, Keith Packard wrote: > Chris Wilson <[email protected]> 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
