Mir

Merge lp://qastaging/~vanvugt/mir/earlier-release into lp://qastaging/mir

Proposed by Daniel van Vugt
Status: Merged
Approved by: Daniel van Vugt
Approved revision: no longer in the source branch.
Merged at revision: 2862
Proposed branch: lp://qastaging/~vanvugt/mir/earlier-release
Merge into: lp://qastaging/mir
Diff against target: 164 lines (+107/-0)
4 files modified
src/server/compositor/buffer_queue.cpp (+17/-0)
src/server/compositor/buffer_queue.h (+1/-0)
tests/integration-tests/test_buffer_scheduling.cpp (+54/-0)
tests/unit-tests/compositor/test_buffer_queue.cpp (+35/-0)
To merge this branch: bzr merge lp://qastaging/~vanvugt/mir/earlier-release
Reviewer Review Type Date Requested Status
PS Jenkins bot (community) continuous-integration Approve
Daniel van Vugt Needs Information
Kevin DuBois (community) Approve
Cemil Azizoglu (community) Approve
Alan Griffiths Approve
Chris Halse Rogers Approve
Review via email: mp+267321@code.qastaging.launchpad.net

Commit message

Reintroduce very short* buffer holds so that a starving client can
get a new buffer to render to much sooner, and potentially appear
much smoother (LP: #1480164)

In visual terms this is the equivalent of adding an extra buffer to
the queue without actually needing an extra buffer. It also means
we're now much more likely to be able to keep up using a lower
number of buffers (and hopefully can re-enable double buffering
eventually).

As an added bonus, this also means a compositor can better predict
where in its render loop we're going to block to send responses to
clients (while LP: #1395421 is not resolved), allowing it to defer
or move buffer releases to another thread so as to not slow down
compositing.

* "very short" means for the render time only (often 1ms or less),
  rather than the full frame interval.

To post a comment you must log in.
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

I suspect we need an equivalent test case added to kdub's new suite too?... But it's now Friday night. Later.

Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :
review: Approve (continuous-integration)
Revision history for this message
Alan Griffiths (alan-griffiths) wrote :

*Needs Discussion*

I'm not completely comfortable with the "single monitor" naming here. If I understand the context correctly it identifies that the queue is being consumed by a single compositor (and isn't directly related to the number of monitors).

review: Needs Information
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Fair point.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

To be completely pedantic, "compositor" is not always accurate either. It might be a frame dropper or a snapshot rather than a compositor. We should just call them "consumers" (and clients "producers").

Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :
review: Approve (continuous-integration)
Revision history for this message
Chris Halse Rogers (raof) wrote :

Hm. The various special-cases in BufferQueue are solidifying my belief that we've made an incorrect abstraction.

That said, we'll soon have an opportunity to revisit that in the New Buffer Semantics™, and this looks like a sensible improvement.

review: Approve
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Don't underestimate the value of 600 lines of lowly coupled and thoroughly tested code. The new solution is likely to be bigger, more highly coupled and less mature for quite some time yet.

Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :
review: Approve (continuous-integration)
Revision history for this message
Alan Griffiths (alan-griffiths) wrote :

compositor vs consumers is a preexisting irritation

review: Approve
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

I just noticed, kdub's already using "producer" and "consumer" in new code.

Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :
review: Needs Fixing (continuous-integration)
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :
review: Needs Fixing (continuous-integration)
Revision history for this message
Cemil Azizoglu (cemil-azizoglu) wrote :

ok

review: Approve
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

The autolanding failure seems to be a timing glitch. That failing test relies on real time :P

Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :
review: Needs Fixing (continuous-integration)
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :
review: Needs Fixing (continuous-integration)
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Actually this failure looks suspiciously real and related:
13: [ FAILED ] BufferQueue/WithThreeOrMoreBuffers.queue_size_scales_with_client_performance/1, where GetParam() = 4 (378 ms)

If only I could reproduce it.

Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :
review: Needs Fixing (continuous-integration)
Revision history for this message
Kevin DuBois (kdub) wrote :

lgtm too

review: Approve
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Although I've been landing a lot of proposals by hand during the wily archive transition (CI fails for everyone), this proposal should probably wait. The only place it was ever failing was in CI so I want to see it pass in CI...

Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :
review: Needs Fixing (continuous-integration)
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Measurements:
Maxing out a demo server with 49 clients (which is all my desktop can render smoothly using trunk), I get an improvement in the compositor render time from 3.7ms to 1.6ms using this branch. Also, this branch raises the maximum number of concurrent clients before frames are missed from 49 to 54.

Revision history for this message
Alan Griffiths (alan-griffiths) wrote :

> Measurements:
> Maxing out a demo server with 49 clients (which is all my desktop can render
> smoothly using trunk), I get an improvement in the compositor render time from
> 3.7ms to 1.6ms using this branch. Also, this branch raises the maximum number
> of concurrent clients before frames are missed from 49 to 54.

Interesting.

Any chance of getting these tests automated?

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

I think I can see another location where a similar optimization is required:
  mc::BufferQueue::client_release()

That might explain why this branch still wasn't quite working as well as it should with my qtmir work.

review: Needs Information
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :
review: Needs Fixing (continuous-integration)
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :
review: Approve (continuous-integration)

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
The diff is not available at this time. You can reload the page or download it.

Subscribers

People subscribed via source and target branches