On Mon, 2008-04-14 at 22:21 +0200, Matthieu Baechler wrote:> Le lundi 14 avril 2008 à 13:57 -0400, Alex Deucher a écrit :> > On Mon, Apr 14, 2008 at 1:49 PM, Matthieu Baechler <m.baechler@xxxxxxx> wrote:> > > Le lundi 14 avril 2008 à 16:31 +0200, Michel Dänzer a écrit :> > >> > > > > Is there something we can do to avoid these migration ?> > > >> > > > A good start is usually finding out why it's falling back to software.> > > > You can change RADEON_TRACE_FALL to 1 in> > > > xf86-video-ati/src/radeon_exa.c, rebuild the driver, re-run the test and> > > > put up the log file (compressed if it's very big) somewhere for us to> > > > look at.> > >> > > I put my Xorg.log there : http://pastebin.com/m2717acea> > > > see bugs:> > http://bugs.freedesktop.org/show_bug.cgi?id=15371> > http://bugs.freedesktop.org/show_bug.cgi?id=15334> > I patched my radeon driver with patches from #15371, and it reduces> migration a lot.> The same gnome-system-monitor test case dropped from 20% to 5% of CPU.> I didn't noticed any regression. Is there something preventing from> pushing it to master ? I don't think so, somebody just needs to get around to it. > While I am at this, the next CPU killer seems to be this one (browsing> the internet triggers this) :> > R200CheckCompositeTexture: Unsupported picture format 0x1011000> > This time I checked bugzilla, I found nothing about it. That's the a1 (single bit alpha) format, which EXA doesn't accelerateyet. This could be related to non-antialiased fonts. BTW, as you're using current xserver code, Option "EXAOptimizeMigration"might help, but read its description in the exa manpage first. -- Earthling Michel Dänzer | http://tungstengraphics.comLibre software enthusiast | Debian, X and DRI developer _______________________________________________xorg mailing listxorg@xxxxxxxxxxxxxxxxxxxxxxxxx://lists.freedesktop.org/mailman/listinfo/xorg