On Friday 24 May 2002 8:49 am, Keith Whitwell scribed numinously:"
> Tim Smith wrote:
> > I have a nice, 100% reliable way to lock up my Radeon 7500 using the
> > most recent CVS. I can do this with Tux Racer, if I play for a couple
> > of courses, but it's much easier to do using the Neverwinter Nights
> > Toolset beta running under WINE, because that's really quite intensive
> > and produces the lockup in about 5 seconds (much longer if debugging is
> > enabled, which seems interesting). This was stable with the drivers in
> > XFree 4.2, except that they would fail to texture things (e.g. the
> > penguin in Tux Racer was a white blob).
> >
> > I've played around with *all* the radeon driver options in XF86Config,
> > to no significant effect (well I managed to lock X on startup with a
> > too-high CPusecTimeout :-). It won't let me assign more than 2MB to
> > BufferSize and I presume there's a good reason for that, so 32 buffers
> > seems the maximum unless the size of each buffer can be reduced. How
> > much of that 64K gets used? Is it worth trying that?
>
> It depends a little on which driver you're using. The two in CVS make
> full use of each buffer & only release it when it's full. XFree 4.2
> driver is pretty primitive in some repects & fires after each (run of
> similar) primitive so can be quite wasteful.
>
> How does the CVS code hold up? You can download binaries from the
> sourceforge download page... URL?
The XFree 4.2 driver is stable, but drops textures on the floor somwhere.
The CVS code produces correct textures, but locks up under heavy use with
the symptoms described. I've been using the binaries from
dri.sourceforge.net to test this with. I also tried the experimental tcl
branch binaries out of curiosity, but my X server segfaulted on startup so
I stopped being so silly :-)
I am using the X server checked out from cvs.dri.sourceforge.net
I've been poking at it a bit more recently, just reading the code to see
what it does because I'm not at the machine in question right now, and I
observe the following in
xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_accel.c, starting at
line 1518
while ( 1 ) {
do {
ret = drmDMA( info->drmFD, &dma );
if ( ret && ret != -EBUSY ) {
xf86DrvMsg( pScrn->scrnIndex, X_ERROR,
"%s: CP GetBuffer %d\n", __FUNCTION__, ret );
}
} while ( ( ret == -EBUSY ) && ( i++ < RADEON_TIMEOUT ) );
if ( ret == 0 ) {
buf = &info->buffers->list[indx];
buf->used = 0;
if ( RADEON_VERBOSE ) {
xf86DrvMsg( pScrn->scrnIndex, X_INFO,
" GetBuffer returning %d\n", buf->idx );
}
return buf;
}
xf86DrvMsg( pScrn->scrnIndex, X_ERROR,
"GetBuffer timed out, resetting engine...\n");
RADEONEngineReset( pScrn );
RADEONEngineRestore( pScrn );
/* Always restart the engine when doing CP 2D acceleration */
RADEONCP_RESET( pScrn, info );
RADEONCP_START( pScrn, info );
}
What's going to happen to the card if drmDMA() returns EAGAIN rather than
EBUSY, which is what it does in the case where radeon_freelist_get returns
NULL? Should the drm kernel module return EBUSY in that circumstance? None
of the userspace parts seem to check for EAGAIN, but all the drm modules
seem to return it when freelist_get falls off the bottom.
--
Tim Smith ([EMAIL PROTECTED])
75% of wookies over the age of three hundred wear hairpieces.
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
