Poor compositing performance on 965Q chipset with intel 2.2.1 driver
michel at tungstengraphics.com
Fri May 9 08:50:39 PDT 2008
On Fri, 2008-05-09 at 18:35 +0300, Marius Gedminas wrote:
> On Fri, May 09, 2008 at 07:39:47AM -0700, Keith Packard wrote:
> > On Fri, 2008-05-09 at 14:11 +0100, Barry Scott wrote:
> > > Using latest libpciaccess makes no difference MTRR status is the same:
> > It's not the MTRRs that are broken, it's the page mapping which is
> > setting the ignore cache and write through bits on each page mapped by
> > libpciaccess. There's a kludge-around which takes advantage of a
> > different kernel bug to clear those bits. A simple test:
> > $ x11perf -shmput500
> > If that gives you a number significantly less than 1000, then your pages
> > are probably mis-mapped.
> Which number is that? The # per second?
> mg at platonas:~ $ x11perf -shmput500
> x11perf - X11 performance program, version 1.5
> The X.Org Foundation server version 10400090 on :0.0
> from platonas
> Fri May 9 18:31:46 2008
> Sync time adjustment is 0.0309 msecs.
> 3200 reps @ 1.6794 msec ( 595.0/sec): ShmPutImage 500x500 square
> 3200 reps @ 1.6568 msec ( 604.0/sec): ShmPutImage 500x500 square
> 3200 reps @ 1.7887 msec ( 559.0/sec): ShmPutImage 500x500 square
> 3200 reps @ 1.6947 msec ( 590.0/sec): ShmPutImage 500x500 square
> 3200 reps @ 1.6732 msec ( 598.0/sec): ShmPutImage 500x500 square
> 16000 trep @ 1.6986 msec ( 589.0/sec): ShmPutImage 500x500 square
> This is with GM965 and intel driver 2.2.1, but I haven't noticed poor
> compositing performance.
EXA in xserver 1.4 had a less optimized ShmPutImage implementation.
I think the mystery could indeed just be due to the different 3D engines
- the infamous issues covered by Carl Worth's blog posts only affect the
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
More information about the xorg