| Summary: | [GEM] Compiz expo plugin causes extremely high CPU usage | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Ben Gamari <bgamari> |
| Component: | Drivers/DRI/i965 | Assignee: | Eric Anholt <eric> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | Keywords: | NEEDINFO |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
Complete profile
Sysprof profile of repeatedly using expo plugin Summary of the previously attached profile |
||
|
Description
Ben Gamari
2008-12-01 10:50:37 UTC
Created attachment 20718 [details]
Complete profile
Profile of 30 seconds of repeatedly invoking the Expo plugin.
Please provide related component version and Xorg log, according to http://intellinuxgraphics.org/how_to_report_bug.html. 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 From the callgraph, what GL function is being called that results in the pain? (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? 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 Created attachment 24898 [details]
Summary of the previously attached profile
This appears to work fine with DRI2 -- do you have the problem there as well? (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. 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. (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. 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. OK, no feedback, and CPU usage is low, so closing. (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.