Bug 18836 - [GEM] Compiz expo plugin causes extremely high CPU usage
Summary: [GEM] Compiz expo plugin causes extremely high CPU usage
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Eric Anholt
QA Contact:
URL:
Whiteboard:
Keywords: NEEDINFO
Depends on:
Blocks:
 
Reported: 2008-12-01 10:50 UTC by Ben Gamari
Modified: 2009-12-11 10:10 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Complete profile (193.71 KB, application/x-Bzip)
2008-12-01 10:53 UTC, Ben Gamari
Details
Sysprof profile of repeatedly using expo plugin (313.25 KB, application/x-bzip)
2009-04-17 08:19 UTC, Ben Gamari
Details
Summary of the previously attached profile (34.27 KB, application/octet-stream)
2009-04-17 08:20 UTC, Ben Gamari
Details

Description Ben Gamari 2008-12-01 10:50:37 UTC
Invoking the compiz expo plugin causes extremely high CPU usage, largely in memcpy, as seen in the following profile,

CPU: Core 2, speed 2200 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (Unhalted core cycles) count 100000
samples  %        image name               app name                 symbol name
-------------------------------------------------------------------------------
  1        1.3e-04  libdricore.so            Xorg                     _mesa_new_z24_renderbuffer_wrapper
358052   46.8660  libc-2.9.so              Xorg                     memcpy
  358052   46.8660  libc-2.9.so              Xorg                     memcpy [self]
-------------------------------------------------------------------------------
55973     7.3264  oprofile                 oprofile                 /oprofile
  55973     7.3264  oprofile                 oprofile                 /oprofile [self]
-------------------------------------------------------------------------------
  2        2.6e-04  libcairo.so.2.10800.0    firefox                  _cairo_clip_intersect_to_rectangle
  263       0.0344  libglib-2.0.so.0.1800.2  firefox                  .fini
25491     3.3366  libflashplayer.so        firefox                  /usr/lib64/mozilla/plugins/libflashplayer.so
  25491     3.3366  libflashplayer.so        firefox                  /usr/lib64/mozilla/plugins/libflashplayer.so [self]
Comment 1 Ben Gamari 2008-12-01 10:53:07 UTC
Created attachment 20718 [details]
Complete profile

Profile of 30 seconds of repeatedly invoking the Expo plugin.
Comment 2 Gordon Jin 2008-12-01 17:39:42 UTC
Please provide related component version and Xorg log, according to http://intellinuxgraphics.org/how_to_report_bug.html.
Comment 3 Ben Gamari 2008-12-01 17:54:25 UTC
Sorry about that, meant to add details in a comment but I was distracted.

Anyways, this is on the GM965 (Dell Latitude D830) on Fedora 10 with xf86-video-intel from git, mesa-7.2-0.13.fc10, xorg-x11-server-Xorg-1.5.3-5.fc10 and a gem enabled kernel (the stock fedora kernel, from for-airlied). 

$ uname -a
Linux mercury.localdomain 2.6.27.5-118.fc10.x86_64 #1 SMP Tue Nov 18 14:11:40 EST 2008 x86_64 x86_64 x86_64 GNU/Linux
Comment 4 Eric Anholt 2008-12-02 14:12:21 UTC
From the callgraph, what GL function is being called that results in the pain?
Comment 5 Ben Gamari 2008-12-02 15:01:41 UTC
(In reply to comment #4)
> From the callgraph, what GL function is being called that results in the pain?
> 

I was trying to figure that out myself. OProfile is pretty finicky with resolving callgraphs. The file I attached is the complete callgraph produced by opreport (bzip2'ed). However, I can't find anything of use other than the first sample that I mentioned in my original description. I can't figure out what calls _mesa_new_z24_renderbuffer_wrapper or for that matter, how execution gets to memcpy.

I've tried running opreport with -g, but naturally it segfaults. Perhaps your oprofile-fu is better than mine?
Comment 6 Ben Gamari 2009-04-17 08:19:54 UTC
Created attachment 24897 [details]
Sysprof profile of repeatedly using expo plugin

(In reply to comment #4)
> From the callgraph, what GL function is being called that results in the pain?
> 

So I just tried the benchmark again, this time with sysprof. While the CPU usage seems lower now, it is still quite studder-y. It seems that the biggest CPU time contribution is from __glXDisp_DrawArrays. The complete profile is attached.

$ xorg-versions.sh 
Xorg components as of Fri Apr 17 11:17:35 EDT 2009
drm: 	1173e7abdcdf758a2403ce921076080c6672c054
xf86-video-intel: 	ebb8d6a13a18138b31ad119be2d3807a1e4010b3
mesa: 	e704de8cb62092f7402cfe99064fcd692e492086
xserver: 	49bd35c28245d2261f17887f03a23deddf57d1e9

Linux mercury.localdomain 2.6.29work #34 SMP PREEMPT Thu Apr 16 12:25:16 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
Comment 7 Ben Gamari 2009-04-17 08:20:19 UTC
Created attachment 24898 [details]
Summary of the previously attached profile
Comment 8 Eric Anholt 2009-04-23 19:19:27 UTC
This appears to work fine with DRI2 -- do you have the problem there as well?
Comment 9 Ben Gamari 2009-04-23 20:55:50 UTC
(In reply to comment #8)
> This appears to work fine with DRI2 -- do you have the problem there as well?
> 

Yeah, I'm running DRI2. Try enabling the benchmark plugin while using expo. On my setup (1920x1200) the framerate drops from 50fps to 15 while expo is activated.
Comment 10 Eric Anholt 2009-07-13 21:16:31 UTC
With Mesa master, I'm getting a drop from 55ish fps to 25ish fps, but CPU usage stays at <10%.  Half fps for rendering a lot more (though really, 55fps to start with?  madness) seems reasonable.

From your profile, your compiz is broken and running indirect instead of direct, thus much higher CPU usage.
Comment 11 Ben Gamari 2009-07-15 07:48:13 UTC

(In reply to comment #10)
> With Mesa master, I'm getting a drop from 55ish fps to 25ish fps, but CPU usage
> stays at <10%.  Half fps for rendering a lot more (though really, 55fps to
> start with?  madness) seems reasonable.

Yeah, Mesa has been much better recently (perhaps inexplicably, has much changed on the efficiency front?). That being said, it is quite . When I looked at the expo plugin with an early version of my wait accounting patch, I saw that it generated quite a few CHANGE_DOMAIN waits. Hopefully now since we have perf support, I'll be able to get some backtraces. And yeah, 50fps could definitely use some work.

> 
> From your profile, your compiz is broken and running indirect instead of
> direct, thus much higher CPU usage.
> 

Not sure why it would be doing that. It doesn't seem to complain during startup. Weird. 
Comment 12 Eric Anholt 2009-10-09 12:53:31 UTC
Any updates here?  From what I saw, expo performance looks to be what's expected, so unless you can identify a bug I'm tempted to close it.
Comment 13 Eric Anholt 2009-12-10 14:19:59 UTC
OK, no feedback, and CPU usage is low, so closing.
Comment 14 Ben Gamari 2009-12-11 10:10:47 UTC
(In reply to comment #13)
> OK, no feedback, and CPU usage is low, so closing.
> 
Ahh, sorry about that. Framerates so seem a little more consistent now. Compiz still maintains a baseline of 55 fps, dropping to 18 or so with the Expo plugin, but I feel like stutters are far less apparent. Strangely, even moving the mouse will cause instantaneous rates to drop to 35 fps. Not sure what to attribute that to. 

(Note: I'm no longer tracking master, grad school has taken its toll on my schedule so I've fallen back to Ubuntu 9.10).


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.