Michel Dänzer <[email protected]> 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
> offhand.
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
waiting.
--
[email protected]
pgptmImejIWhF.pgp
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
