intel-batchbuffer problem (was: Re: DRI2 direct rendering)

[Steven J Newbury]

On Wed, 2008-04-02 at 18:14 +0100, Steven J Newbury wrote:
> 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...
> > 
I'm going to be away skiing for the next week but I'm attaching my
Xorg.log file.  The register debug info looks like it might be
indicating my problem.  Hope it helps.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Xorg.0.log
Type: text/x-log
Size: 22687 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20080405/09e99b67/attachment.bin>