Poor compositing performance on 965Q chipset with intel 2.2.1 driver

[Hugo Mildenberger]

Am Freitag, 9. Mai 2008 20:58 schrieb Steven J Newbury:
> On Fri, 2008-05-09 at 19:31 +0200, Hugo Mildenberger wrote:
> > Am Freitag, 9. Mai 2008 18:48 schrieb Barry Scott:
> > > >> 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.
> >
> > Running "x11perf -shmput500", I get these similar numbers using 965G rev
> > 02:
> >
> > Sync time adjustment is 0.0326 msecs.
> >
> >    3200 reps @   1.7145 msec (   583.0/sec): ShmPutImage 500x500 square
> >    3200 reps @   1.7133 msec (   584.0/sec): ShmPutImage 500x500 square
> >    3200 reps @   1.7132 msec (   584.0/sec): ShmPutImage 500x500 square
> >    3200 reps @   1.7133 msec (   584.0/sec): ShmPutImage 500x500 square
> >    3200 reps @   1.7134 msec (   584.0/sec): ShmPutImage 500x500 square
> >   16000 trep @   1.7135 msec (   584.0/sec): ShmPutImage 500x500 square
> >
> >
> > using current master branch of xf86-video-intel and libpciaccess.
>
> Just as another datapoint:
>
> x11perf - X11 performance program, version 1.2
> The X.Org Foundation server version 10599001 on :0.0
> from infinity
> Fri May  9 19:51:25 2008
>
> Sync time adjustment is 0.0405 msecs.
>
>   12000 reps @   0.5318 msec (  1880.0/sec): ShmPutImage 500x500 square
>   12000 reps @   0.5333 msec (  1880.0/sec): ShmPutImage 500x500 square
>   12000 reps @   0.5312 msec (  1880.0/sec): ShmPutImage 500x500 square
>   12000 reps @   0.5301 msec (  1890.0/sec): ShmPutImage 500x500 square
>   12000 reps @   0.5303 msec (  1890.0/sec): ShmPutImage 500x500 square
>   60000 trep @   0.5313 msec (  1880.0/sec): ShmPutImage 500x500 square
>
> Everything from master branches as today (20080509), GM965.  Linux
> kernel from master branch yesterday with exception of the reversion of
> the "nopage removal" since the mesa/drm module hasn't yet been updated.

Ahem, I thought I were using libpciaccess. But the symbol XSERVER_LIBPCIACCESS
was actually undefined even though libpciaccess is really there. If I
define it manually via make CFLAGS="-DXSERVER_LIBPCIACCESS=1", I get a bunch
of compilation errors, which would be somewhat tedious to fix, and would
awake the suspicion,  that actually no one currently uses libpciaccess with
the intel driver, especially because of the following error:

git/xf86-video-intel/src/reg_dumper/
main.c:70: Fehler: »struct pci_info_rec« hat kein Element namens »device_id«
(which translates to: struct pci_info_rec has no field named "device_id")

The reason is, that "struct pci_info_rec" is defined in

git/xf86-video-intel/src/reg_dumper/reg_dumper.h

like this:
struct pci_info_rec {
    uint16_t chipType;
};


Steven, could you just verify you are actually using
libpciaccess by writing some syntactical illegal scrap within an
#if XSERVER_LIBPCIACCESS guarded block (e.g. into i830_driver.c) and
 recompile the driver in your environment?