Re: [Dri-devel] Savage 2D corruption workaround

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

On Sun, 21 Dec 2003 08:35:14 -0500
Keith Whitwell <ke...@tu...> wrote:

> Felix Kühling wrote:
> > I recompiled a static Xserver so that could get a backtrace inside the
> > driver. This is the result:
> > 
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x080532e3 in SavageHelpSolidROP (pScrn=0x8624270, fg=0xbffff724, pm=-1,
> >     rop=0xbffff728) at savage_accel.c:758
> > 758         pm &= infoRec->FullPlanemask;
> > (gdb) bt
> > #0  0x080532e3 in SavageHelpSolidROP (pScrn=0x8624270, fg=0xbffff724, pm=-1,
> >     rop=0xbffff728) at savage_accel.c:758
> > #1  0x080636e1 in SAVAGEDRISetupForSolidFill (pScrn=0x8624270, color=0, rop=0,
> >     planemask=4294967295) at savage_dri.c:1956
> > #2  0x08062e87 in SAVAGEDRIInitBuffers (pWin=0x87dd650, prgn=0x87e1350,
> >     index=0) at savage_dri.c:1676
> > #3  0x0849ee66 in DRIWindowExposures (pWin=0x87dd650, prgn=0x87e1350,
> >     bsreg=0x0) at dri.c:1569
> > #4  0x081c90f2 in miHandleValidateExposures (pWin=0x87dd948) at miwindow.c:468
> > #5  0x0814f8c1 in MapWindow (pWin=0x87dd650, client=0x87588b8) at window.c:2841
> > #6  0x08126641 in ProcMapWindow (client=0x87588b8) at dispatch.c:688
> > #7  0x08125e9c in Dispatch () at dispatch.c:450
> > #8  0x0813d3d4 in main (argc=11, argv=0xbffffd84, envp=0xbffffdb4)
> >     at main.c:435
> > 
> > Apperently the DRI code in the savage driver uses accel functions even
> > if acceleration is disabled. Maybe you can try disabling individual XAA
> > acceleration functions. See the XF86Config-4 manual page for details.
> > There are lots of options like XaaNoCPUToScreenColorExpandFill.
> 
> This probably won't work as the type of operations above aren't going through 
> XAA to reach the accel functions, but instead calling them directly.

The idea is that the driver thinks accel is enabled so it'll initialize
the XAA and we don't get a segfault (hopefully). Still XAA won't use the
accelerated functions if they are disabled by Xaa... options. I havn't
looked into the details, so I may be missing something. Anyway, the hope
is that the accelerated functions are responsible for the corruption
Maximo is observing. To find that out is the whole purpose of these
experiments. ;-)

> 
> There are two cases that spring to mind where this happens:
> 
> 	- New window creation
> 		- A solid fill blit is used to initialize the back and depth buffers.  I've 
> never really been convinced that it was the job of the X server to do this 
> initialization, but in any case it (or the 3D driver) could just as easily 
> issue a 'clear' ioctl to the drm.

There is no clear ioctl in the savage driver ATM. In fact there are no
driver-specific ioctls at all (only for mapping PCI DMA buffers if AGP
is not available). All hardware access is done in user space. :-/

> 
> 	- Window moves
> 		- Copy blits are used to move the contents of the back and depth buffers to 
> their new locations.
> 		
> 
> Both of these operations can be disabled at the expense of some corruption at 
> the times of these events.  Look in the _dri.c file in the 2d driver for where 
> these are being called.

It's always good to have several options. Maximo, you can try this too
if you still get segfaults when disabling individual acceleration
functions.

> 
> Keith

------------    __\|/__    ___     ___       -------------------------
 Felix       ___\_e -_/___/ __\___/ __\_____   You can do anything,
   Kühling  (_____\Ä/____/ /_____/ /________)  just not everything
 fx...@gm...       \___/   \___/   U        at the same time.