Nested servers frame rate

[Kevin Gunn]

I don't have another theory. I would think its the extra "free" buffer
especially with insanely high fps rates.
can we get some mobile device based numbers as well ?
br, kg


On Wed, Dec 18, 2013 at 3:07 AM, Daniel van Vugt <
daniel.van.vugt at canonical.com> wrote:

> 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
>>>>>
>>>>
> --
> Mir-devel mailing list
> Mir-devel at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/mir-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20131218/37a73ee6/attachment.html>