Intel ( i845G ) profiling

[Eric Anholt]

On Wed, 2008-03-05 at 11:04 -0800, Eric Anholt wrote:
> On Wed, 2008-03-05 at 15:44 +1100, Daniel Kasak wrote:
> > Some discussion regarding EXA performance for my graphics chip motivated
> > me to do some profiling. 
> > 
> > I've used 2 different apps to benchmark, expedite ( an evas-based
> > benchmark from the Enlightenment team ) and an internal application
> > which uses Gtk2. I tested with a couple of different driver setups
> > ( exa, xaa, xaa with no-offscreen-pixmaps ). I also tested some
> > combinations with a compositing manager named ecomorph, which is a port
> > of compiz to run on Enlightenment. Profiling was done with sysprof from
> > svn.
> > 
> > For the expedite tests, I ran the full auto test, with various renderers
> > ( software, xrender, gl ). I kept the output of each expedite run ( see
> > the .txt files in the profile tarball ). Quite counter-intuitively,
> > expedite gives EXA a better score overall than XAA. I'm not sure what to
> > say about that. Certainly for some benchmarks it scores lower. I suppose
> > Gtk2 makes most use of those features which EXA doesn't score so well at
> > in the expedite tests? Or something like that. At any rate, all of the
> > apps that I use are Gtk2 apps ( other than Enlightenment ).
> > 
> > For the internal application ( see
> > http://entropy.homelinux.org/axis/images/client_services.png for a
> > screenshot ), I loaded it up, moved to a client, and then clicked on
> > each of the pages. I waited until the page finished rendering, then I
> > clicked on the next page. With XAA, each page will render in just under
> > half a second, which isn't too bad. With EXA, each page takes between 1
> > and 2 seconds, which is quite noticably slower than XAA, and a little
> > painful to watch. Whack a compositing manager on top, and it gets worse
> > still ( ie completely unusable, whereas with XAA it's OK ... not
> > brilliant, but OK ).
> > 
> > A tarball of the sysprof profiles and expedite output can be found at:
> > http://entropy.homelinux.org/intel_benchmarking.tar.bz2
> > 
> > Software setup - all these are compiled with gcc-4.1.2 with
> > CFLAGS="-march=pentium4 -g -O2 -pipe -ftracer -fweb" ...
> >  - mesa-7.0.2
> >  - xorg-server-1.4.0.90
> >  - xf86-video-i810-2.2.0.90
> >  - libpixman-0.1.6
> >  - glibc-2.7
> > 
> > If someone wants me to profile something different, please feel free to
> > ask :)
> 
> Excellent, this is what I was hoping someone would do.  So, from your
> profile, you're spending 67% of cpu in memcpying data out for software
> fallbacks from the composite path.  I'm betting TTM will improve that
> somewhat (you're avoiding an uncached copy in favor of cached access,
> but there's clflushing and chipset flushing going on to make that
> possible).
> 
> But the real problem is that you're hitting the software fallback path
> at all.  Looking over the code, it looks like we're falling back on
> rendering from a8 textures because you're on 830 or 845.  That would be
> all non-subpixel text.  Ouch.  You could remove the #ifdef I830DEBUG
> guard around #define DEBUG_I830FALLBACK to confirm that that's where the
> majority of your fallbacks are occurring.
> 
> If so, the reason we're falling back is because the A8 format (0,0,0,a)
> is unsupported on that chipset.  But we've got the I8 format which
> produces (a,a,a,a), and if we're using the a8 picture as a
> non-component-alpha mask, we'll only use that fourth component.  For a
> more general implementation, those color channels could be treated as
> zero by using ARGx_SEL_ONE | ARGx_INVERT when reading them instead of
> ARGx_SEL_TEXELy.

Untested patch is up at:
git://people.freedesktop.org/~anholt/xf86-video-intel i845-render-fix

-- 
Eric Anholt                             anholt at FreeBSD.org
eric at anholt.net                         eric.anholt at intel.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20080311/69421daa/attachment.pgp>