Subject: Nested servers frame rate

From: Daniel van Vugt <[email-masked]>
Date: Wed, 18 Dec 2013 16:43:13 +0800

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.

Can anyone else think why nested would sometimes be faster than not nested?

- Daniel

---

From: Thomas Voß <[email-masked]>
Date: Wed, 18 Dec 2013 09:58:50 +0100

On Wed, Dec 18, 2013 at 9:43 AM, Daniel van Vugt
<[email-masked]> 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:
> 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

> --
> Mir-devel mailing list
> [email-masked]
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/mir-devel

---

From: Daniel van Vugt <[email-masked]>
Date: Wed, 18 Dec 2013 17:01:49 +0800

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.

---

From: Thomas Voß <[email-masked]>
Date: Wed, 18 Dec 2013 10:04:02 +0100

On Wed, Dec 18, 2013 at 10:01 AM, Daniel van Vugt
<[email-masked]> wrote:
> 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

>>> nesting
>>> levels

---

From: Daniel van Vugt <[email-masked]>
Date: Wed, 18 Dec 2013 17:07:38 +0800

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.

---

From: Kevin Gunn <[email-masked]>
Date: Wed, 18 Dec 2013 10:45:46 -0600

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 <
[email-masked]> wrote:

> I'll work on getting numbers. In the mean time, any other theories on why
> nesting is sometimes faster?
>
>>> we
>>>>> nested
>>>>> server
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/mir-devel
>