On Fri, 26 Oct 2001, Manuel Teira wrote: > I have been looking to the register caching. I don't know if this caching has > sense once the DRI is also writing directly to some of the registers. I saw > seldom times this in my XFree log file: > .. $REGISTER_NAME write cache disabled!
I've noticed that too. > this is written by the Mach64Sync function, that compares all the cached > register values with the actual values ( and shows that error when values > differ). I commented out the register caching when trying to find the DMA > problem (it's still commented out in the branch code). I've also noticed that > the other drivers (RADEON , R128) don't use the caching 'feature'. > > I've also seen the outm/inm outf macros (atimach64io.h). These are the ones > that provides the cache features. I wonder if we should block the hardware > for any of these macros (to guarantee that the FIFO entries are true). > Anyway, I think that there are still race conditions, because this kind of > code: > ... > ATIMach64WaitForFIFO(pATI, 6); > outf(SRC_OFF_PITCH, pATIHW->src_off_pitch); > outf(SRC_Y_X, SetWord(pATIHW->src_x, 1) | SetWord(pATIHW->src_y, 0)); > outf(SRC_HEIGHT1_WIDTH1, > SetWord(pATIHW->src_width1, 1) | SetWord(pATIHW->src_height1, 0)); > outf(SRC_Y_X_START, > SetWord(pATIHW->src_x_start, 1) | SetWord(pATIHW->src_y_start, 0)); > outf(SRC_HEIGHT2_WIDTH2, > SetWord(pATIHW->src_width2, 1) | SetWord(pATIHW->src_height2, 0)); > outf(SRC_CNTL, pATIHW->src_cntl); > ... > > If we only block the ouf macros and the WaitForFIFO macro separately, we > cannot guarantee that there will be 6 free slots once the WaitForFIFO has > finished (because of the DRM). > > So, what I think we should do is: > > 1.- Block all the code that matches the previous template (mainly in > atimach64.c) , in this way: > DRILock( pScreenInfo->pScreen ); > ATIMach64WaitForFIFO( pATI, n ); > /* > * Here the outf stuff > */ > DRIUnlock( pScreenInfo->pScreen ); > > 2.-Disable the Register Caching for all the registers. Perhaps we could later > enable the caching for the registers that are not used by the drm driver. Sounds reasonable. I guess this is the function of the CCE stuff in the r128 driver (although that seems to be a hardware feature, it loads microcode at initialization)? > Talking about the Q3 hang when switching vts: > I don't know if this is the problem, but the other drivers (RADEON, R128) has > a DRILock (DRIUnlock) calls when doing enterVT (leaveVT), that mach64 hasn't. > I will try to test this behaviour today (once I have Q3 installed ;-) ). > > > > > > On another note, I'm attaching a small patch to fix a few things. > > [snip] > At a first glance, it looks fine. I will apply it to the branch once that I > see that works fine on my machine. Actually, the stuff in AGPInit should probably be disabled (just move the #endif back to the end before the return) for now since it seems to cause texture corruption. Once we get the driver actually using AGP then we can enable it. -- Leif Delgass _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
