Performance loss with NBS and overlays on

[Kevin DuBois]

If you run a server with overlays enabled on android devices with a client, sporadically, the performance will dip between 1/2 vsync rate and vsync rate. The dip is dependent on load, (it seems loads that tax the system at near-vsync rates seem to cause the problem).

Should be fixed before 0.23 is published, so tagging as critical.

[Kevin DuBois (kdub)]

seems what's happening is an overlaid buffer is returned to the client that has a raised fence. The delay is cleared shortly, but the delay is unnecessary, and when combined with the correct load, causes quantization down to 1/2 vsync (sporaditally). We always have a spare, unfenced buffer around to give out, so we should prefer to give that out.

[Kevin DuBois (kdub)]

still testing branch (its in WIP). Its proving tricky to establish baseline performance when the entire system is integrated.

[Daniel van Vugt (vanvugt)]

Note that overlays with only triple buffers will drop to half frame rate more easily. Because overlays/bypass requires the compositor holds two of the buffers much of the time. So performance is more like double buffering -- you either hit 60Hz or drop all the way to 30Hz.

But I thought NBS had switched to quad-buffering already? That would solve the smoothness problem at least (at the expense of higher latency).

I know all of this is unrelated to fencing issues, but definitely something to keep in mind.

[Mir CI Bot (mir-ci-bot)]

Fix committed into lp:mir at revision None, scheduled for release in mir, milestone 0.24.0

[Launchpad Janitor (janitor)]

This bug was fixed in the package mir - 0.23.0+16.10.20160602.1-0ubuntu1

---------------
mir (0.23.0+16.10.20160602.1-0ubuntu1) yakkety; urgency=medium

  [ Kevin DuBois ]
  * New upstream release 0.23.0 (https://launchpad.net/mir/+milestone/0.23.0)
    - ABI summary:
      . mirclient ABI unchanged at 9
      . mirserver ABI bumped to 40
      . mircommon ABI bumped at 6
      . mirplatform ABI unchanged at 11
      . mirprotobuf ABI unchanged at 3
      . mirplatformgraphics ABI unchanged at 9
      . mirclientplatform ABI unchanged at 5
      . mirinputplatform ABI unchanged at 5
    - Enhancements:
      . Enable internal usage of more flexible graphics buffer submission,
        precursing client API additions.
    - Bug fixes:
      . Potential NBS performance loss after resize (LP: #1579076)
      . Performance loss with NBS and overlays on (LP: #1578159)
      . Mir crashes with useless backtrace when mg::Platform methods throw
        (LP: #1553549)
      . Virtual output is not removed when screencast client disappears
        (LP: #1573572)
      . Can't VT switch from mir_demo_server (any more) (LP: #1576260)
      . mir_demo_server(_minimal): Window movement/resizing stops responding
        when the cursor leaves the surface, and can lead to windows 1px wide
        and unrecoverable. (LP: #1447886)
      . Virtual display output configuration is set to LVDS (LP: #1573782)
      . Mir-on-X11 doesn't pass Alt+primary button drag to Mir (LP: #1575765)
      . Mir-on-X11 breaks mir_proving_server resize logic (LP: #1575192)
      . Resizing can crash mir_demo_server (LP: #1575211)
      . [regression] Cursor stops at phantom edge on M10 and N7 (LP: #1580774)
      . [regression] MIR_CLIENT_PERF_REPORT is showing bogus render times and
        buffer lag (LP: #1581368)
      . Test failures in ClientLogging.reports_performance due to the above
        fix. (LP: #1583970, LP: #1584603, LP: #1584605)
      . Do not throw when creating some objects under HWC 1.5 (LP: #1583086)
      . Correct black frame issue under Xmir (LP: #1584784)

  [ Tarmac, Kevin DuBois <email address hidden>, Daniel van Vugt <email address hidden>, Andreas Pokorny <email address hidden>, Alberto Aguirre ]
  * 0.23.0 Mir release

 -- Kevin DuBois <email address hidden> Thu, 02 Jun 2016 13:18:03 +0000

[Kevin DuBois (kdub)]

right, this was in 0.23, doesnt affect 0.24.

[Kevin DuBois (kdub)]

hmm, seems that I can't target to a released milestone

[Daniel van Vugt (vanvugt)]

I know it looks confusing, but 0.23 and 0.24 get separate bug tasks here because they got different fixes for this bug. The fix landed on 0.24 series after we had branched 0.23. So the two fixes have different histories and need to be tracked separately.