[Intel-gfx] [ubuntu-x] -intel 2.6.3 uploaded
Peter Clifton
pcjc2 at cam.ac.uk
Tue Mar 24 01:15:52 CET 2009
On Tue, 2009-03-24 at 00:29 +0100, Khashayar Naderehvandi wrote:
> On Mon, Mar 23, 2009 at 11:12 PM, Bryce Harrington <bryce at canonical.com> wrote:
> > On Mon, Mar 23, 2009 at 09:49:38PM +0000, Peter Clifton wrote:
> >> On Mon, 2009-03-23 at 13:12 -0700, Bryce Harrington wrote:
> >> > For those of you who have tested UXA, now that -intel 2.6.3 has been in
> >> > the archive a few days, what are your thoughts on it compared with the
> >> > default EXA?
> >>
> Well, for me things are much better with UXA (on g45), except for one
> thing, which in fact is a show stopper. Namely, the issue that a
> suspend/resume cycle while either compiz or composited kwin is active,
> 2 out of 3 times crashes the server and leaves me at the login window.
> So I'd vote for EXA, although performance is pretty crappy with it.
Ah, I see that too, but hadn't tied it to DRI2 / UXA / Compiz.
> >> I noted this blog post today:
> >>
> >> http://jasondclinton.livejournal.com/72910.html
> >>
> >> And it seems that the cpufreq governer being broken causes low fps / 3D
> >> performance. I seem to recall some kernel fixes in Jaunty to reinstate
> >> the ondemand governor. Perhaps my brief spell with no proper CPU
> >> governor corresponded to the increased FPS.
> >>
> >> (Setting the "performance" governor rather than "ondemand" pushes my
> >> "not a benchmark" glxgears numbers from about 560fps to about 880fps.)
> >
> > Hey, that's interesting. That could also explain why people with
> > exactly the same graphics chipsets are reporting drastically varying
> > performance results.
> >
> > Anyone else with -intel performance troubles see it go away if switching
> > from ondemand to performance?
> >
> I came across that blog post as well and found it interesting. It
> helps performance a little to follow the advice on that blog post when
> running games and the likes. But when I'm talking about reduced
> performance, I'm always talking about compiz and/or composited kwin.
> That is, normal everyday stuff that should be running fine without the
> performance governor. And with EXA normal desktop usage is OK, but not
> great. It should be much better with a g45.
glxgears "looks" CPU bound when running with the "ondemand" governer (it
takes about half the monitoring applet's graph on my core2 duo laptop).
"top" shows otherwise:
(ondemand, running at 800Mhzm both cores)
Cpu0 : 15.3%us, 15.0%sy, 0.0%ni, 68.3%id, 0.0%wa, 1.3%hi, 0.0%si, 0.0%st
Cpu1 : 33.2%us, 24.1%sy, 0.0%ni, 41.8%id, 0.0%wa, 0.9%hi, 0.0%si, 0.0%st
glxgears ~ 500fps.
(performance, running at 2.4Ghz both cores)
Cpu0 : 8.7%us, 6.0%sy, 0.0%ni, 82.0%id, 1.3%wa, 2.0%hi, 0.0%si, 0.0%st
Cpu1 : 11.2%us, 11.2%sy, 0.0%ni, 72.6%id, 0.0%wa, 4.9%hi, 0.0%si, 0.0%st
glxgears ~800fps.
I wonder if the changes in cpufreq are affecting the timing of
opportunities for some required synchronisation between the CPU and GPU.
Clearly the frame-rate doesn't appear to be CPU bound as the blog post
suggests. (Unless some kernel CPU time simply isn't being accounted for,
and is lost to cpufreq and "top".).
Another off the wall idea.. could the platform methods used to change
the speed of the CPU core be somehow triggering similar reduction in
execution speed in the graphics chipset?
Here's a really fun discovery.. I ran a short test program to busy-loop
the CPU. This is with the "performance" governer. After running one
copy, my glxgears fps appeared to increase. Curious, I spawned a second
copy (I have 2 cores of CPU). glxgears fps increased again! (to
~950fps). Just for completeness' sake, I'll note that a third copy slows
it down again somewhat.
The busy-loop programs are keeping the CPU from idling, and perhaps
somehow the residency of lower C states is giving rise to the lower
frame-rates (in spite the CPU being otherwise busy).
Would it be a matter of having the graphics drivers ensure a wakeup is
scheduled at the right time, to decrease bottlenecks due to CPU / GPU
synchronisation? As those who _are_ experts will be able to tell, I have
no real understanding of what the issues at work here might be.
I'm also not a gamer, so can't comment how these findings might apply to
"real-world" work-loads.
BTW: test program:
int main( int argc, char **argv )
{
while (1);
}
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA
Tel: +44 (0)7729 980173 - (No signal in the lab!)
More information about the Intel-gfx
mailing list