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

[Keith Packard]

Christian König <deathsimple at vodafone.de> writes:

> Agree totally, even today we have a number of problems with MSCs.
>
> For example try to move a video from one monitor to another. Since the 
> state tracker doesn't know of the window move we send out MSCs for the 
> wrong display device. In the best case this results in just displaying a 
> frame way to early, in the worst we stall for a quite long time until 
> the other device reaches the MSC counter of the first one.

Present constructs a logical MSC value for each window; move the window
among CRTCs and the MSC value continues in the correct sequence,
although the time between frames may change. In fact, move the window
off the screen entirely and the MSC interval rises to a full second,
slowing applications which are hidden down to reduce resource utilization.

> I'm not sure if we want to queue things up in the kernel.

We already queue one flip in the kernel; the question is what to do when
a second flip call is made.

> I think just providing a timestamp when the frame should be first 
> visible like VDPAU does is the right way to go.

DRI2 and Present both provide that information.

> Adding a flag that a waiting flip request should be replaced by another 
> one instead of running into an error should be enough to handle the 
> triple (or quad) buffered case as well.

I don't think this is sufficient to implement the swap_control_tear
extension though. For that, if the request comes before the vblank
event, it should wait, but if the request comes after the vblank event,
it should swap immediately. By telling the kernel which vblank interval
to flip at can you allow the kernel to correctly choose between waiting
and immediately flipping.

The alternative is to eliminate delayed flips in the kernel entirely and
rely on user space to make the request when the vblank interrupt
happens. I don't know if this will work reliably enough; you need to
deliver the vblank event out to user space, and the window system needs
to respond by getting the flip to the kernel in the space of a few
scanlines of time.

I've implemented this with the current in-ring flip stuff on
Intel and it "works" when things are not busy, correctly flipping at
vblank when possible. When the GPU becomes busy, the flip is delayed by
sitting in the ring and you end up with a tear.

However, this completely ignores the problem of scheduling the flip
while rendering is still queued for the new buffer. Placing the flip in
the ring ensures that any related rendering will be done before the flip
occurs. Using MMIO to flip means that an explicit wait is required; for
correct vblank-synchronized rendering, we must delay until the buffer is
idle *and* vblank is occurring before updating the scanout
register. Present isn't doing this idle check, and so even if we have
MMIO writes in the kernel, I suspect we'll still have tearing...

-- 
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/20140604/4b232aca/attachment.sig>