[PATCH] present: Queue flips for later execution. Begging for review.
keithp at keithp.com
Tue Jun 3 20:08:21 PDT 2014
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
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
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 810 bytes
Desc: not available
More information about the xorg-devel