Nested servers frame rate

[Daniel van Vugt]

I'll work on getting numbers. In the mean time, any other theories on 
why nesting is sometimes faster?

I think the first logical step is to assume nesting shouldn't be faster. 
But instead non-nested is being throttled somehow, like already described.


On 18/12/13 17:04, Thomas Voß wrote:
> On Wed, Dec 18, 2013 at 10:01 AM, Daniel van Vugt
> <daniel.van.vugt at canonical.com> wrote:
>> The issue is in your response: "almost immediately" :)
>>
>> At present, "almost immediately" means waiting for a round trip. Whereas we
>> can do better than that in theory, by pushing free buffers to the client as
>> soon as they're available.
>>
>
> Fair, but I would like to see numbers on the roundtrip penalty you are
> suspecting here, first :)
>
> Cheers,
>
>    Thomas
>
>>
>>
>> On 18/12/13 16:58, Thomas Voß wrote:
>>>
>>> On Wed, Dec 18, 2013 at 9:43 AM, Daniel van Vugt
>>> <daniel.van.vugt at canonical.com> wrote:
>>>>
>>>> At first glance, comparing frame rates between direct (single) and nested
>>>> (double) server configurations reveals nothing unexpected...
>>>>
>>>> Full screen
>>>> Direct (bypass) 2600
>>>> Direct (bypass off) 2400
>>>> Nested (bypass) 2450
>>>> Nested (bypass off) 2330
>>>>
>>>> But for surfaces which can't be bypassed, something strange happens;
>>>> nesting
>>>> is faster!
>>>>
>>>> Windowed
>>>> Nested 4890
>>>> Direct 4400
>>>>
>>>> My best theory right now is that we're crippling Mir in the single server
>>>> case due to:
>>>> https://bugs.launchpad.net/mir/+bug/1253868
>>>> and nesting provides a workaround for that problem by supplying extra
>>>> levels
>>>> of buffering.
>>>
>>>
>>> Not sure I'm following your reasoning here: The bug states exactly the
>>> opposite, i.e., additional buffering wouldn't help.
>>> In addition: I do not see how a steady-state update scheme on the
>>> client-side is a problem here. If there are more than two buffers
>>> available per surface, the client almost immediately receives a new
>>> buffer when it calls next_buffer. Sure, there is always only one
>>> buffer in flight, but I cannot see why this would lead to the numbers
>>> you are reporting here.
>>>
>>> Cheers,
>>>
>>>     Thomas
>>>
>>>>
>>>> Can anyone else think why nested would sometimes be faster than not
>>>> nested?
>>>>
>>>> - Daniel
>>>>
>>>> --
>>>> Mir-devel mailing list
>>>> Mir-devel at lists.ubuntu.com
>>>> Modify settings or unsubscribe at:
>>>> https://lists.ubuntu.com/mailman/listinfo/mir-devel