New Buffer Semantics Planning

[Daniel van Vugt]

bypass/overlays: If you look at the current logic you will see that the 
DisplayBuffer holds the previous bypass/overlay buffer until _after_ the 
client has provided the next one. And it must, to avoid scan-out 
artefacts. So the server holds two of them very briefly. But only one is 
held most of the time. Without "predictive bypass" as I'm working on 
right now, that buffer is held for almost two frames. With "predictive 
bypass" it's closer to (but greater than still) one frame held. On 
startup, absolutely you're right that only one buffer is required to get 
bypass/overlays going. So my wording was wrong.

client wake-up: I may have worded that poorly too. The point is in the 
new world (tm) frame dropping mostly happens in the client (as opposed 
to all in the server like it is today). But some of it still needs to 
happen in the server because you don't want a compositor that tries to 
keep up with a 1000 FPS client by scheduling all of those frames on a 
60Hz display. It has to drop some.


On 26/06/15 11:39, Christopher James Halse Rogers wrote:
> On Fri, Jun 26, 2015 at 12:39 PM, Daniel van Vugt
> <daniel.van.vugt at canonical.com> wrote:
>> I'm curious (but not yet concerned) about how the new plan will deal
>> with the transitions we have between 2-3-4 buffers which is neatly
>> self-contained in the single BufferQueue class right now. Although as
>> some responsibilities clearly live on one side and not the other,
>> maybe things could become conceptually simpler if we manage them
>> carefully:
>>
>>   framedropping: Always implemented in the client process as a
>> non-blocking acquire. The server just receives new buffers quicker
>> than usual and needs the smarts to deal with (skip) a high rate of
>> incoming buffers [1].
>
> Clients will need to tell the server at submit_buffer time whether or
> not this buffer should replace the other buffers in the queue. Different
> clients will need different behaviour here - the obvious case being a
> video player that wants to dump a whole bunch of time-stamped buffers on
> the compositor at once and then go to sleep for a while.
>
> But in general, yes. The client acquires a bunch of buffers and cycles
> through them.
>
>>   bypass/overlays: Always implemented in the server process, invisible
>> to the client. The server just can't enable those code paths until at
>> least two buffers have been received for a surface.
>
> I don't think that's the case? Why does the server need two buffers in
> order to overlay? Even with a single buffer the server always has a
> buffer available¹.
>
> It won't be entirely invisible to the client; we'll probably need to ask
> the client to reallocate buffers when overlay state changes, at least
> sometimes.
>
>>   client wake-up: Regardless of the model/mode in place the client
>> would get woken up at the physical display rate by the server if it's
>> had a buffer consumed (but not woken otherwise). More frequent
>> wake-ups for framedropping are the responsibility of libmirclient
>> itself and need not involve the server to do anything different.
>
> By and large, clients will be woken up by EGL when the relevant fence is
> triggered.
>
> I don't think libmirclient will have any role in waking the client.
> Unless maybe we want to mess around with
>
>> [1] Idea: If the server skipped/dropped _all_ but the newest buffer it
>> has for each surface on every composite() then that would eliminate
>> buffer lag and solve the problem of how to replace dynamic double
>> buffering. Client processes would still only be woken up at the
>> display rate so vsync-locked animations would not speed up
>> unnecessarily. Everyone wins -- minimal lag and maximal smoothness.
>
> ¹: The assumption here is that a buffer can be simultaneously scanned
> out from and textured from. I *think* that's a reasonable assumption,
> and in the cases where I know it doesn't apply having multiple buffers
> doesn't help, because it's the buffer *format* that can only be scanned
> out from, not textured from.
>