Improving next_buffer() rpc

Daniel van Vugt daniel.van.vugt at canonical.com
Fri Jul 11 08:55:06 UTC 2014


Good news. I've done some visual testing and there definitely is visibly 
reduced lag from double-buffering.

My previous argument was both right and wrong:
"Even the slightest pause then, and you can be certain that the "ready" 
sub-queue is emptied and thus it's only one frame lag from client to 
server, no matter how long the overall ring of buffers is."

This statement remains true. However what I forgot was that during 
scrolling etc when latency matters most, there is no "slightest pause" 
for the compositor to catch up. Thus the client is allowed to pre-render 
too many frames and the age of a frame by the time it appears on screen 
is nbuffers-1.

So it looks like double-buffering is still a good idea. In fact, based 
on those findings it seems a more efficient protocol while increasing 
throughput, would only increase the problem of perceived lag as clients 
can render even further in advance of vsync.

But it's a delicate balance. On desktop for example one can hack around 
the parallel render/pageflipping logic and make it wait for vsync 
sooner. This reduces lag even further, however it increases the risk of 
the compositor missing the frame deadline (as seen in clone mode) 
unacceptably.


On 10/07/14 18:01, Gerry Boland wrote:
> On 09/07/14 16:39, Kevin Gunn wrote:
>> First
>> Not sure we're still on topic necessarily wrt changing from id's to fd's
>> do we need to conflate that with the double/triple buffering topic ?
>> let's answer this first...
>>
>> Second
>> while we're at it :) triple buffering isn't always a win. In the case of
>> small, frequent renders (as an example "8x8 pixel square follow my finger")
>> you'll have potentially 2 extra buffers that need their 16ms of fame on the
>> screen in the queue, 1 at session server, 1 at system server. Which can
>> look a little laggy. I'm willing to say in the same breath though, that
>> this may be lunatic fringe. The win for the triple buffering case is likely
>> more common, which is spikey render times (14+ms) amongst more normal
>> render times (9-12ms)
>> +1 on giving empty buffers back to the clients to allow them to have a
>> "queue" of empty buffers at their disposal (i'm not sure if RAOF is correct
>> or duflu in that its "synchronously waiting for a round trip every swap"...can
>> we already have an empty buffer queue on the client side ?)
>
>
> I also want to remind everyone that our default shipping configuration
> is a root mir server with a nested mir server as a client, and that
> nested mir server manages most client apps the user will be interacting
> with.
>
> Nesting will increase input latency, as now there's not just 3 buffers
> in play, but more (5 yeah?).
>
> I had thought that the double-buffering idea was to try reduce the
> number of buffers being used in the nested case. Sounds like Daniel
> isn't confident that'll work now, which is a pity.
> Thanks
> -G
>
>
>
>



More information about the Mir-devel mailing list