Mir

[regression] [nonblockswap] BufferConsumingFunctor holds buffers too long, potentially hurting client render throughput

Bug #1308844 reported by Daniel van Vugt
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mir
Fix Released
Medium
Mir development team
mir (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

[regression] Multi-threaded compositor holds buffers too long, potentially hurting client render throughput.

Until recently the compositor only held client buffers as long as it needed them to render and swapbuffers (a couple of milliseconds). However the recent introduction of BufferConsumingFunctor (r1545) means we're holding each buffer for a full 16ms.

We might not see any visible regression on screen yet, but it's a theoretical problem we should address for low-end hardware performance.

Related branches

Changed in mir:
assignee: nobody → Daniel van Vugt (vanvugt)
status: Triaged → In Progress
description: updated
Revision history for this message
Alberto Aguirre (albaguirre) wrote :

"BufferConsumingFunctor (r1545) means we're holding each buffer for a full 16ms."

Correction, the buffer will be held in the WORST CASE 16ms (just as with an actual display that just barely missed its vsync timeline).

The vysnc wait done in BufferConsumingFunctor emulates a running vsync clock not a full 16ms wait.

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

And once it syncs up the first time, with constant frames scheduled it will indefinitely be sync'd up and all frames thereafter sleep for 16ms. So almost always 16ms.

The dynamic timing adjustment in BufferConsumingFunctor appears to be of no value for this reason. You would get the same result with a simple sleep call.

kevin gunn (kgunn72)
summary: - [regression] BufferConsumingFunctor holds buffers too long, potentially
- hurting client render throughput
+ [regression] [nonblockswap] BufferConsumingFunctor holds buffers too
+ long, potentially hurting client render throughput
tags: added: nonblockswap
Revision history for this message
kevin gunn (kgunn72) wrote :

As discussed in the stand-up today.
There's no ill effect seen from a end user point of view on the phone, tablet or xmir.
Based on that, we're accepting this bug as part of the 019 milestone in order to deliver the overall improvement of unblocking events on the phone/tablet.

As for addressing this bug, the team seems to be in agreement on using Chris' proposed solution as an improvement (solving in switching bundle) and a way to correct this issue.
https://code.launchpad.net/~raof/mir/1hz-rendering-always/+merge/216246

kevin gunn (kgunn72)
Changed in mir:
milestone: 0.1.9 → none
milestone: none → 0.1.10
Changed in mir:
assignee: Daniel van Vugt (vanvugt) → Mir development team (mir-team)
tags: added: regression
removed: regression-update
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :

Fix committed into lp:mir/devel at revision None, scheduled for release in mir, milestone Unknown

Changed in mir:
status: In Progress → Fix Committed
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Fix reverted in r1653 due to more serious regressions.

Changed in mir:
status: Fix Committed → In Progress
Changed in mir:
milestone: 0.2.0 → 0.3.0
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :

Fix committed into lp:mir/devel at revision 1675, scheduled for release in mir, milestone Unknown

Changed in mir:
status: In Progress → Fix Committed
Changed in mir:
status: Fix Committed → Fix Released
Changed in mir (Ubuntu):
status: New → Fix Released
Changed in mir (Ubuntu):
importance: Undecided → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.