[enhancement] Mir protocol design prevents clients from ever being more than double-buffered

Bug #1253868 reported by Daniel van Vugt on 2013-11-22
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

The Mir protocol design prevents clients from ever being able to gain a performance advantage beyond double-buffering. This means clients which do a lot of rendering need to keep up with double-buffering deadlines to meet the compositor's frame rate. And they can never take advantage of the catch-up that triple (or more) buffers should provide to eliminate missed frames.

The problem is:
  rpc next_buffer(SurfaceId) returns (Buffer);

When a client tells the server that SurfaceId is ready for rendering, it must then wait synchronously for a single Buffer in return. Thus even if the surface has more than two buffers, the protocol design forces clients to only be able to handle two at once.

This causes a performance bottleneck where even though the server might have free buffers ready to send to the client, it can't do so until the client calls next_buffer a sufficient number of times.

The solution would be to not make next_buffer return a Buffer. Instead have buffers arrive from the server asynchronously, as soon as they can. Much like the way we deliver MirEvent's.

kevin gunn (kgunn72) on 2014-02-20
tags: added: enhancement
summary: - Mir protocol design prevents clients from ever being more than double-
- buffered
+ [enhancement] Mir protocol design prevents clients from ever being more
+ than double-buffered
Daniel van Vugt (vanvugt) wrote :

I just noticed the new callback/completion stuff in SwitchingBundle prevents clients from holding multiple buffers. We've gone backwards a little on this one.

Kevin DuBois (kdub) wrote :

There was some discussion on this desired improvement in the context of some work I embarked upon to implement some android-specific performance optimizations. The thread is still active, so I'll try to summarize the thoughts on the bug in the thread after its settled down.

Daniel van Vugt (vanvugt) wrote :

Actually I think this bug was possibly resolved by the new(er) callback approach. We now send buffer replies to clients from multiple points asynchronously (ASAP) from within BufferQueue. So clients are no longer always waiting for a whole frame, unless the queue is full.

Changed in mir:
status: Triaged → Fix Released
Daniel van Vugt (vanvugt) wrote :

Triaged again. Now we're talking about fixing this issue properly in the protocol.

Changed in mir:
status: Fix Released → Triaged
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers