DRI2 direct rendering

[Steven J Newbury]

On Wed, 2008-04-02 at 15:43 +0100, Steven J Newbury wrote:
> > On Tue, 2008-04-01 at 20:50 +0800, Kristian Høgsberg wrote:
> > > On Tue, Apr 1, 2008 at 5:25 AM, Jin, Gordon <gordon.jin at intel.com>
> > > wrote:
> > > > Kristian H?gsberg wrote on Tuesday, April 01, 2008 5:35 AM:
> > > >
> > > >
> > > > > Hi,
> > > >  >
> > > >  > I just committed the last big chunk of DRI2 work, the direct
> > > rendering
> > > >  > support.  With this, we can now do direct rendering to redirected
> > > >  > windows and GLX_EXT_texture_from_pixmap even works, so compiz
> > > (and
> > > >  > other Open GL compositing managers) can run in direct rendering
> > > mode
> > > >  > too.
> > > >  >
> > > >  > I ended up rolling a couple of changes into the direct rendering
> > > work
> > > >  > and the commits in mesa and xserver grew much bigger than what I
> > > would
> > > >  > have liked.  Short story is that the DRI2 interface and the
> > > legacy
> > > >  > interface diverged and I had to break the DRI interface again.
> > > So I
> > > >  > decided to make a couple of changes I'd been considering, most
> > > >  > noticably, the GLX specifc, open coded __GLcontextModes struct is
> > > no
> > > >  > longer part of the DRI driver interface, and with it glcore.h is
> > > also
> > > >  > gone.  This change is the cause of most of the code churn.  I
> > > could
> > > >  > have tried to split the commits up in a couple of independent
> > > commits,
> > > >  > but it would be a lot of work and I figured it'd be nice to only
> > > have
> > > >  > one commit that breaks the interface.
> > > >  >
> > > >  > The upshot is that git xserver AIGLX needs git mesa DRI driver
> > > and for
> > > >  > DRI2, get the latest version of the xf86-video-intel
> > > intel-batchbuffer
> > > >  > branch too.
> > > >
> > > >  Is there an option to disable DRI2 (or say, switch to legacy DRI)
> > > for those who would stick to xf86-video-intel master branch (or 2.3)
> > > at this point?
> > > 
> > > Yes, if you're not running the batchbuffer branch of the intel driver,
> > > none of this will kick in.  The DRI2 code paths are triggered by the
> > > DDX driver initializing the DRI2 module in the X server, which then
> > > will allow the AIGLX code or libGL to initialize in DRI2 mode.  If
> > > you're running the master intel driver or the batchbuffer branch with
> > > 'Option "DRI2" "off"', the DRI2 module won't get initialized and
> > > everything should work as before.  If you see regressions in this
> > > case, I'd like to hear about them.
> > > 
> 
> I've been trying to use intel-batchbuffer on and off for the last few
> weeks on a DELL Latitude D830:
> 
> 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960
> Integrated Graphics Controller (rev 0c)
> 
> I'm using git master versions of xorg-server, mesa, drm etc.  Everything
> compiles fine and it correctly enables DRI2 etc, seems very fast, but
> causes the GM965 to lockup when moving windows under a compositing
> window manager (tested with kwm4 (EXA) and metacity, compiz just locks
> up straight away), also while moving a window it also appears to flicker
> (kwm also shows random black rectangles over various parts of the
> desktop if there is more than 1 window) and jump around, often
> compressing the vertical dimension of the window.  After locking up it
> falls back to the console but is left in a state such that the driver
> can not re-initialise the hardware, the text console is still working
> ok.  A hard reboot is required before the xserver will fire up again.

I've decided to give it another go.  After it crashes subsequent
attempts to bring up the xserver result in:

(II) intel(0): [DRI2] Setup complete
(II) intel(0): Current clock rate multiplier: 1
(II) intel(0): Fixed memory allocation layout:
(II) intel(0): 0x00000000-0x0001ffff: ring buffer (128 kB)
(II) intel(0): 0x0077f000:            end of stolen memory
(II) intel(0): 0x0077f000-0x0b5cffff: DRI memory manager (178500 kB)
(II) intel(0): 0x10000000:            end of aperture
(II) intel(0): BO memory allocation layout:
(II) intel(0): 0x0077f000:            start of memory manager 
(II) intel(0): 0x00800000-0x0160ffff: front buffer (14400 kB) X tiled
(II) intel(0): 0x01610000-0x0161ffff: exa G965 state buffer (64 kB)
(II) intel(0): 0x01620000-0x01629fff: HW cursors (40 kB)
(II) intel(0): 0x0b5d0000:            end of memory manager
(WW) intel(0): ESR is 0x00000010, page table error
(WW) intel(0): PGTBL_ER is 0x00000010, display A pte
(WW) intel(0): PRB0_CTL (0x0001f001) indicates ring buffer enabled
(WW) intel(0): PRB0_HEAD (0x0081fa38) and PRB0_TAIL (0x0001da60)
indicate ring
(WW) intel(0): Existing errors found in hardware state.

... and that's the end of the log.

> Option "ExaNoComposite" "false" stops it crashing, but also obviously
> isn't ideal!
This option is now fixed so that should now read:
 Option "ExaNoComposite" "true"

It does seem to make it stable, but 3D is also much slower. 

There seems to be no working vblank interrupt, could this be related?
My kernel log gets filled with: "trying to get vblank count for disabled
pipe 0"

> 
> I can do more testing and get logs etc, but I am a little wary, I had to
> just send the machine to be repaired by DELL due to memory failure, and
> I'm a little concerned it may have been aggravated by testing this
> driver...
>