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

[Christian König]

Am 04.06.2014 09:03, schrieb Pekka Paalanen:
> On Tue, 03 Jun 2014 20:08:21 -0700
> Keith Packard <keithp at keithp.com> wrote:
>
>> 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?
> Hi,
>
> that is starting to sound a lot like queueing display updates in the
> kernel. Let me jump a few (couple?) years to the future and speculate
> wildly, likely going off-topic. ;-)
>
> I think the whole concept of MSC will be breaking down, as we are
> getting dynamic/variable refresh displays (G-SYNC, FreeSync). MSC will
> no longer correspond to the true real time at all (bye bye A/V sync),
> not even for the very next vblank which might happen any time from 5 to
> 500 ms from the previous vblank. (That is one reason why I designed the
> Wayland Presentation extension (still RFC [1]) around timestamps
> instead of frame counters.) We'd need a way to tell DRM when we would
> like the next vblank to happen.

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.

> DRM universal planes + atomic modesetting / nuclear pageflip is already
> aiming to gather at least a per-head update into a single atomic set of
> state changes. Once we have that, we might extend that to allow
> queueing in the kernel for more than just the very next update. The how
> is totally open, and the benefits are not clear at least to me yet. I
> suspect you'd also need a way to cancel some or all queued updates - I
> suppose you'd want that already - and to get feedback per submission on
> was it actually presented and when.
>
> This is just some food for thought, nothing more.

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

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

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.

Christian.

>
>>> 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.
> We've had similar discussions in the Wayland land, and generally people
> were horrified of needing 4 buffers for a busy-loop EGL app (games).
> I'm not sure if we came to any real conclusion. I think if someone
> really wants to waste CPU/GPU cycles for drawing more than you can
> show, they have also the memory to juggle more buffers around. *shrug*
>
> If the aim is to reduce latency, I think it should be tackled in a
> more... sophisticated manner than just throwing raw power at it. But
> that'd mean the games would need to get smarter, which won't help
> existing games.
>
>>> 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.
> I think dmabuf will be solving that problem. If I understood right, you
> would be able to use the dmabuf fd to check if (DRM) fences have been
> signalled. I'm not sure of the details, though, or when that feature
> would be available. Maarten Lankhorst would know.
>
>
> Thanks,
> pq
>
> [1] http://lists.freedesktop.org/archives/wayland-devel/2014-March/013580.html