Mir

Merge lp:~vanvugt/mir/fix-1420678 into lp:mir

Proposed by Daniel van Vugt
Status: Merged
Approved by: Daniel van Vugt
Approved revision: no longer in the source branch.
Merged at revision: 2323
Proposed branch: lp:~vanvugt/mir/fix-1420678
Merge into: lp:mir
Diff against target: 107 lines (+53/-19)
2 files modified
src/server/compositor/buffer_queue.cpp (+0/-19)
tests/unit-tests/compositor/test_buffer_queue.cpp (+53/-0)
To merge this branch: bzr merge lp:~vanvugt/mir/fix-1420678
Reviewer Review Type Date Requested Status
Chris Halse Rogers Approve
PS Jenkins bot (community) continuous-integration Approve
Alan Griffiths Approve
Review via email: mp+249456@code.launchpad.net

Commit message

Fix the multi-monitor frame sync logic to support high speed
compositors (tm) which only need to hold buffers very briefly
(introduced in r2183). (LP: #1420678)

Both the multi-monitor frame sync logic and the optimization of r2183
behave correctly independently. It's only when combined that they start
to interfere with each other. But we'd very much like to keep both...

To post a comment you must log in.
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :
review: Needs Fixing (continuous-integration)
Revision history for this message
Alan Griffiths (alan-griffiths) wrote :

Failure in ServerShutdown.normal_exit_removes_endpoint appears to be unrelated valgrind issue

4: [ RUN ] ServerShutdown.normal_exit_removes_endpoint
4: ==27126==
4: ==27126== HEAP SUMMARY:
4: ==27126== in use at exit: 13,363 bytes in 53 blocks
4: ==27126== total heap usage: 533,640 allocs, 533,587 frees, 34,288,827 bytes allocated
4: ==27126==
4: ==27126== LEAK SUMMARY:
4: ==27126== definitely lost: 0 bytes in 0 blocks
4: ==27126== indirectly lost: 0 bytes in 0 blocks
4: ==27126== possibly lost: 944 bytes in 9 blocks
4: ==27126== still reachable: 12,419 bytes in 44 blocks
4: ==27126== suppressed: 0 bytes in 0 blocks
4: ==27126== Reachable blocks (those to which a pointer was found) are not shown.
4: ==27126== To see them, rerun with: --leak-check=full --show-leak-kinds=all
4: ==27126==
4: ==27126== For counts of detected and suppressed errors, rerun with: -v
4: ==27126== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
4: /tmp/buildd/mir-0.11.0bzr2317pkg0vivid957/tests/mir_test_framework/interprocess_client_server_test.cpp:153: Failure
4: Value of: result.exit_code
4: Expected: is equal to 0
4: Actual: 1 (of type int)
4: [ FAILED ] ServerShutdown.normal_exit_removes_endpoint (532 ms)

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

I don't see any problems with this, but I don't feel confident that it covers all cases. Further opinions would be good.

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

Arguably a more elegant solution was what I had up to r2316. That just removed the whole block of code (removed the double buffering fix for LP: #1319765).

But I too would like a third more elegant solution... Haven't found it yet. It's hard to make logic changes there and still pass all the existing tests (which is good at least).

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. This doesn't look incorrect, but it also looks like it's papering over a problem elsewhere.

I *think* this might be an artefact of an incorrect fix for bug #1319765? The problem identified there being that there's no additional composition scheduled when the client has submitted a frame and is blocking for its next buffer. This was solved by fake-consuming the client frame; it would seem to be more correct to ensure that the frame that the client has already submitted appropriately triggers composition?

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

It would take me a while to get my head around the problem again. Sounds like we might have been papering over bug 1395581, which was only fixed very recently.

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

raof: Fixed. Thanks!

It's complicated. Took two brains and the coordination of three different bug fixes to realise the interplay...

Revision history for this message
Chris Halse Rogers (raof) wrote :

Looks good now.

review: Approve

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
=== modified file 'src/server/compositor/buffer_queue.cpp'
--- src/server/compositor/buffer_queue.cpp 2015-01-22 09:12:04 +0000
+++ src/server/compositor/buffer_queue.cpp 2015-02-17 06:41:51 +0000
@@ -271,25 +271,6 @@
271 if (nbuffers <= 1)271 if (nbuffers <= 1)
272 return;272 return;
273273
274 /*
275 * We can't release the current_compositor_buffer because we need to keep
276 * a compositor buffer always-available. But there might be a new
277 * compositor buffer available to take its place immediately. Moving to
278 * that one immediately will free up the old compositor buffer, allowing
279 * us to call back the client with a buffer where otherwise we couldn't.
280 */
281 if (current_compositor_buffer == buffer.get() &&
282 !ready_to_composite_queue.empty())
283 {
284 current_compositor_buffer = pop(ready_to_composite_queue);
285
286 // Ensure current_compositor_buffer gets reused by the next
287 // compositor_acquire:
288 current_buffer_users.clear();
289 void const* const impossible_user_id = this;
290 current_buffer_users.push_back(impossible_user_id);
291 }
292
293 if (current_compositor_buffer != buffer.get())274 if (current_compositor_buffer != buffer.get())
294 release(buffer.get(), std::move(lock));275 release(buffer.get(), std::move(lock));
295}276}
296277
=== modified file 'tests/unit-tests/compositor/test_buffer_queue.cpp'
--- tests/unit-tests/compositor/test_buffer_queue.cpp 2015-01-22 09:12:04 +0000
+++ tests/unit-tests/compositor/test_buffer_queue.cpp 2015-02-17 06:41:51 +0000
@@ -489,6 +489,44 @@
489 }489 }
490}490}
491491
492TEST_F(BufferQueueTest, multiple_fast_compositors_are_in_sync)
493{ // Regression test for LP: #1420678
494 for (int nbuffers = 3; nbuffers <= max_nbuffers_to_test; ++nbuffers)
495 {
496 mc::BufferQueue q(nbuffers, allocator, basic_properties, policy_factory);
497
498 // Client generates first frame
499 auto handle1 = client_acquire_async(q);
500 ASSERT_TRUE(handle1->has_acquired_buffer());
501 auto client_id1 = handle1->id();
502 handle1->release_buffer();
503
504 // Client generates second frame
505 auto handle2 = client_acquire_async(q);
506 ASSERT_TRUE(handle2->has_acquired_buffer());
507 auto client_id2 = handle2->id();
508 handle2->release_buffer();
509
510 // Many monitors... verify they all get the first frame.
511 for (int monitor = 0; monitor < 10; monitor++)
512 {
513 void const* user_id = reinterpret_cast<void const*>(monitor);
514 auto comp_buffer = q.compositor_acquire(user_id);
515 ASSERT_EQ(client_id1, comp_buffer->id());
516 q.compositor_release(comp_buffer);
517 }
518
519 // Still many monitors... verify they all get the second frame.
520 for (int monitor = 0; monitor < 10; monitor++)
521 {
522 void const* user_id = reinterpret_cast<void const*>(monitor);
523 auto comp_buffer = q.compositor_acquire(user_id);
524 ASSERT_EQ(client_id2, comp_buffer->id());
525 q.compositor_release(comp_buffer);
526 }
527 }
528}
529
492TEST_F(BufferQueueTest, compositor_acquires_frames_in_order)530TEST_F(BufferQueueTest, compositor_acquires_frames_in_order)
493{531{
494 for (int nbuffers = 2; nbuffers <= max_nbuffers_to_test; ++nbuffers)532 for (int nbuffers = 2; nbuffers <= max_nbuffers_to_test; ++nbuffers)
@@ -1236,6 +1274,14 @@
1236 q.client_release(client_acquire_sync(q));1274 q.client_release(client_acquire_sync(q));
12371275
1238 q.compositor_release(b);1276 q.compositor_release(b);
1277
1278 /*
1279 * Update to the original test case; This additional compositor acquire
1280 * represents the fixing of LP: #1395581 in the compositor logic.
1281 */
1282 if (q.buffers_ready_for_compositor(this))
1283 q.compositor_release(q.compositor_acquire(this));
1284
1239 auto handle = client_acquire_async(q);1285 auto handle = client_acquire_async(q);
1240 // With the fix, a buffer will be available instantaneously:1286 // With the fix, a buffer will be available instantaneously:
1241 ASSERT_TRUE(handle->has_acquired_buffer());1287 ASSERT_TRUE(handle->has_acquired_buffer());
@@ -1272,6 +1318,13 @@
1272 1318
1273 q.compositor_release(b);1319 q.compositor_release(b);
12741320
1321 /*
1322 * Update to the original test case; This additional compositor acquire
1323 * represents the fixing of LP: #1395581 in the compositor logic.
1324 */
1325 if (q.buffers_ready_for_compositor(this))
1326 q.compositor_release(q.compositor_acquire(this));
1327
1275 auto z = client_acquire_async(q);1328 auto z = client_acquire_async(q);
1276 ASSERT_TRUE(z->has_acquired_buffer());1329 ASSERT_TRUE(z->has_acquired_buffer());
1277 z->release_buffer();1330 z->release_buffer();

Subscribers

People subscribed via source and target branches