Re: [Dri-devel] Mach64 2D accel problem

[Felix <fx...@gm...>]

On Sun, 30 Jun 2002 15:06:34 -0400 (EDT)
Leif Delgass <lde...@re...> wrote:

> On Sun, 30 Jun 2002, Alan Hourihane wrote:
> 
> > On Sun, Jun 30, 2002 at 12:39:30 +0200, Felix Kühling wrote:
> > > Hi mach64 folks,
> > > 
> > > after several weeks of extreme busyness/absence I am back now and
> > > testing the mach64-0-0-4 and 0-0-5 branches again (still the best I can
> > > do :( ). It's great that you got 2D accel working. However, there is
> > > still one problem.
> > > 
> > > Moving a GL window caused the X-server to segfault with both the latest
> > > versions of mach64-0-0-4 and 0-0-5. Moving any other window while 3D was
> > > active was no problem. I experimented a bit with this and it turned out
> > > that the problem only occurs when I use 
> > > 
> > > Option "XaaNoScreenToScreenCopy"
> > > 
> > > in the Screen section. (I did this since it caused drawing errors in
> > > some situations.)
> > > 
> > > I got a backtrace of the segfault:
> > > 
> > > Program received signal SIGSEGV, Segmentation fault.
> > > 0x00000000 in ?? ()
> > > #0  0x00000000 in ?? ()
> > > #1  0x08741a5f in ?? ()
> > > #2  0x0825129f in ?? ()
> > > #3  0x0817e351 in miMoveWindow (pWin=0x8912d18, x=0, y=0, pNextSib=0x8939780, 
> > >     kind=VTMove) at miwindow.c:553
> > > #4  0x080d8d17 in ConfigureWindow (pWin=0x8912d18, mask=3, vlist=0x88f2088, 
> > >     client=0x88d5560) at window.c:2507
> > > #5  0x080beda2 in ProcConfigureWindow (client=0x88d5560) at dispatch.c:772
> > > #6  0x080b9608 in Dispatch () at dispatch.c:462
> > > #7  0x080cde39 in main (argc=5, argv=0xbffffb84, envp=0xbffffb9c) at main.c:454
> > > 
> > > call LoaderPrintSymbol printed this in XFree86.1.log:
> > > 0x8741138 ATIInitializeXVideo+927
> > > 	Module "/usr/X11R6-mach64005/lib/modules/drivers/atimisc_drv.o"
> > > 	Section ".text"
> > > 0x82511f0 DRICopyWindow+af
> > > 	Module "/usr/X11R6-mach64005/lib/modules/extensions/libdri.a:dri.o"
> > > 	Section ".text"
> > > 
> > > It seems that there is a call to a null pointer in the end. Just a
> > > guess: Could it be a call to the ScreenToScreen copy function which I
> > > disabled in the XF86Config?
> > 
> > Yes. It is indeed the problem. ATIDRIMoveBuffers() calls
> > this XAA function. 
> > 
> > I guess if this is disabled you need to fallback to software
> > copying, or disable DRI (ouch).
> > 
> > Alan.
> 
> I copied the code for ATIDRIMoveBuffers from the radeon driver.  Does 
> radeon have a fallback for this?  ATIDRIInitBuffers also uses XAA 
> functions (SoldFill), but that could be changed to use the drm clear 
> ioctl.  
> 
> Felix, what problems were you seeing with XaaScreenToScreenCopy enabled?  
> If you see a message in the X log about MMIO caching after "Direct
> rendering enabled", try updating from cvs (0-0-5-branch) or using the
> latest binary and see if the problem is still there.

The 2D problems have nothing to do with DRI, I also see them with
XFree86 4.1. I get really messed up graphics in some situations, certain
web sites or gtk+ themes. I could fix one gtk+ theme by changing the
size of the background pixmaps from 4x4 to 8x8 IIRC. There is a
screenshot at www.dd.chalmers.se/~kuhlfeli/GarbledScreenshot.png. One
Website that often reproduces the problem is www.mplayerhq.hu, sometimes
more, sometimes less. I reported the problem twice to xfree86.org, but
got no response. I'm afraid it's broken hardware :(

Felix

               __\|/__    ___     ___     ___
__Tschüß_______\_6 6_/___/__ \___/__ \___/___\___You can do anything,___
_____Felix_______\Ä/\ \_____\ \_____\ \______U___just not everything____
  fx...@gm...    >o<__/   \___/   \___/        at the same time!