desktop-packages team mailing list archive

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

** Description changed:

- Double-buffered compositing performance is poor.
+ Double-buffered compositing performance is sometimes artificially poor
+ on some intel systems. When this happens the frame rate seen is halved -
+ about 30 FPS. However at the same time, Mir is observed to use very
+ little render time and both the CPU and GPU are still mostly idle. It's
+ just the Intel DRM logic sometimes takes two frames (~32ms) to complete
+ a single page flip.
  
- 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.
+ Two known workarounds avoid the issue:
+   (a) Add glFinish() into the mesa DisplayBuffer code; or
+   (b) env INTEL_DEBUG=sync for the Mir server binary.

** Summary changed:

- Double-buffered compositing performance is very poor (30 FPS) on intel
+ Double-buffered compositing performance is sometimes very poor (30 FPS) on intel

** Changed in: mesa (Ubuntu)
   Importance: Undecided => Medium

-- 
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 sometimes very poor (30
  FPS) on intel

Status in Mesa:
  Confirmed
Status in Mir:
  Confirmed
Status in mesa package in Ubuntu:
  Confirmed

Bug description:
  Double-buffered compositing performance is sometimes artificially poor
  on some intel systems. When this happens the frame rate seen is halved
  - about 30 FPS. However at the same time, Mir is observed to use very
  little render time and both the CPU and GPU are still mostly idle.
  It's just the Intel DRM logic sometimes takes two frames (~32ms) to
  complete a single page flip.

  Two known workarounds avoid the issue:
    (a) Add glFinish() into the mesa DisplayBuffer code; or
    (b) env INTEL_DEBUG=sync for the Mir server binary.

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