Nested servers frame rate
thomas.voss at canonical.com
Wed Dec 18 09:04:02 UTC 2013
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 :)
> 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;
>>> is faster!
>>> Nested 4890
>>> Direct 4400
>>> My best theory right now is that we're crippling Mir in the single server
>>> case due to:
>>> and nesting provides a workaround for that problem by supplying extra
>>> 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.
>>> Can anyone else think why nested would sometimes be faster than not
>>> - Daniel
>>> Mir-devel mailing list
>>> Mir-devel at lists.ubuntu.com
>>> Modify settings or unsubscribe at:
More information about the Mir-devel