desktop-packages team mailing list archive

[Daniel van Vugt <daniel.van.vugt@xxxxxxxxxxxxx>]

As I've tracked the issue into the intel driver code and the workarounds
for test case A don't help B, we might have to split this bug in two.

** Description changed:

  Double-buffered compositing performance is poor.
  
  Fortunately we don't use double-buffering in our default compositor
  (mostly), and Ubuntu touch does not use the default compositor either.
  However, if you make the compositor double-buffered, then it quickly
  drops down to 30 FPS while not consuming any significant CPU or render
  time.
  
  Test case A:
  Convert your compositor to double buffering by the code change suggested in bug 1350725.
  
- Test case B:
+ Test case B (different bug?):
  Switch all clients to double-buffering using this branch:  lp:~vanvugt/mir/double
  and then start a nested server.
  
  Now start a bunch of clients, and you will find they slow down to 30 FPS
  after only starting a few. This does not happen with the default triple
  buffered compositor.
  
  I've been ignoring this issue for a little while [1] thinking I had simply run out of power, although suspected that can't be right as this is a powerful quad-core i7 and it's slowing down with only 10 clients.
  [1] https://bugs.launchpad.net/mir/+bug/1350725/comments/1
  
  Now today test case B has revealed (via MIR_CLIENT_PERF_REPORT) that the
  slowdown happens without using any significant render time (less than 2
  ms) and without using any significant CPU (less than 20% of one out of
  four cores).
  
  So the conclusion is our default compositor is probably holding buffers
  for a little too long somewhere. Because that's the only sensible reason
  I can think of for my system to bog down to 30 FPS without stressing the
  CPU or GPU. We've got poor parallelism in our code somewhere. And once
  that's solved, we'll be able to make further improvements such as
  resolving bug 1350725.

** Changed in: mir
     Assignee: Cemil Azizoglu (cemil-azizoglu) => Daniel van Vugt (vanvugt)

** Bug watch added: freedesktop.org Bugzilla #86366
   https://bugs.freedesktop.org/show_bug.cgi?id=86366

** Also affects: mesa via
   https://bugs.freedesktop.org/show_bug.cgi?id=86366
   Importance: Unknown
       Status: Unknown

** Also affects: mesa (Ubuntu)
   Importance: Undecided
       Status: New

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to mesa in Ubuntu.
https://bugs.launchpad.net/bugs/1377872

Title:
  Double-buffered compositing performance is very poor (30 FPS)

Status in Mesa:
  Unknown
Status in Mir:
  In Progress
Status in “mesa” package in Ubuntu:
  New

Bug description:
  Double-buffered compositing performance is poor.

  Fortunately we don't use double-buffering in our default compositor
  (mostly), and Ubuntu touch does not use the default compositor either.
  However, if you make the compositor double-buffered, then it quickly
  drops down to 30 FPS while not consuming any significant CPU or render
  time.

  Test case A:
  Convert your compositor to double buffering by the code change suggested in bug 1350725.

  Test case B (different bug?):
  Switch all clients to double-buffering using this branch:  lp:~vanvugt/mir/double
  and then start a nested server.

  Now start a bunch of clients, and you will find they slow down to 30
  FPS after only starting a few. This does not happen with the default
  triple buffered compositor.

  I've been ignoring this issue for a little while [1] thinking I had simply run out of power, although suspected that can't be right as this is a powerful quad-core i7 and it's slowing down with only 10 clients.
  [1] https://bugs.launchpad.net/mir/+bug/1350725/comments/1

  Now today test case B has revealed (via MIR_CLIENT_PERF_REPORT) that
  the slowdown happens without using any significant render time (less
  than 2 ms) and without using any significant CPU (less than 20% of one
  out of four cores).

  So the conclusion is our default compositor is probably holding
  buffers for a little too long somewhere. Because that's the only
  sensible reason I can think of for my system to bog down to 30 FPS
  without stressing the CPU or GPU. We've got poor parallelism in our
  code somewhere. And once that's solved, we'll be able to make further
  improvements such as resolving bug 1350725.

To manage notifications about this bug go to:
https://bugs.launchpad.net/mesa/+bug/1377872/+subscriptions