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

[Keith Packard]

Pekka Paalanen <ppaalanen at gmail.com> writes:

> 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. ;-)

We're already queueing updates in the kernel, it's just that the time
for that update to be shown is implicitly 'the next frame', whatever
that means. Applications need to be able to control when their contents
are displayed

> 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.

I think of MSC as simply a different notation for 'time', one which
recognizes the current discrete nature of frames, and which changes
units every time you switch monitors.

> (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.

Present current implements the Khronos standards, which aren't exactly
forward-looking and have a lot of kruft in them, but at least are
published.

> The how is totally open, and the benefits are not clear at least to me
> yet.

Agreed; I'm just dealing with the current situation where we *do* have
queuing in the kernel and need to make it more sane. Right now, given a
flip request, the kernel has no idea whether it should replace the
current flip with that or have the new one wait for yet another frame.

Using some kind of time unit in the request (whether MSC, UST or other),
means that the kernel knows what to do.

> 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 absolutely required; right now the X server has significant
mechanism in place to deal with a canceled flip as it can only correct
things after the flip has occurred.

> 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*

With the current kernel implementation, three buffers with flipping runs
at frame rate because you always have one buffer blocked waiting for
vblank. Providing a way to replace that buffer would mean that you'd be
able to start drawing another frame as soon as the previous frame
finished rendering and the GPU went idle. At least that provides for
faster-than-frame-rate rendering, although it still doesn't saturate the
hardware.

> 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.

What you want is for the application to start drawing precisely when it will
finish in time for vblank. Modeling the performance characteristics of
the system accurately enough to do this reliably is non-trivial. Right
now, some applications adjust rendering complexity to hit their desired
frame rate, but even then developers generally want a
non-vblank-synchronized update in case they miss the deadline.

-- 
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/d28b166a/attachment.sig>