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

[Christian König]

Am 04.06.2014 21:54, schrieb 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.

The problem of MSC is that with approaches like free-sync, active sync 
or G-sync (or however you call it) the number of vertical refreshes per 
second isn't constant any more. So you don't have an unit associated 
with your MSC, and so we really need some kind of external reference for 
this to work reliable.

Apart from that at least on Radeon hardware you have double buffered 
registers, so the hardware does the flip in the next vertical or 
horizantal vblank period if you tell it to do so. So waiting in 
userspace for a certain VBLANK counter to be reached and then sending 
down the request to the kernel would be rather awkward and error prone, 
cause the hardware can do this on their own.

Christian.

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