On Tue, Mar 24, 2009 at 12:15:52AM +0000, Peter Clifton wrote: > On Tue, 2009-03-24 at 00:29 +0100, Khashayar Naderehvandi wrote: > > On Mon, Mar 23, 2009 at 11:12 PM, Bryce Harrington <[email protected]> > > 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.
Is there a bug report open on this issue? (If not, someone care to submit one?) > > >> 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? Heh, that's what I was just wondering looking at those numbers. I assume you've verified you're not using software rendering in glxinfo (I'd guess the fps numbers would be lower in such a case anyway.) > 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). Interesting, that does suggest some sort of processor sleep/wakeup overhead effect. > I'm also not a gamer, so can't comment how these findings might apply to > "real-world" work-loads. I've been encouraging people to run 3D games (I've tested with sauerbraten) as a more realistic workload. Bryce -- Ubuntu-x mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-x
