hi, folks,
In radeon_dri.c, there is a routine RADEONEnterServer(). I can't understand
the
comment for the workaround at the end of this routine. Could you please help me
and if possible?
According to the comments, when R300 gets locked because some accel code fails
to set the 3D cache flush registers before sending WAIT_UNTIL_IDLE, an ioctl
DRM_RADEON_CP_IDLE to kernel can unlock it. Is it really useful ? what I mean
is
why an ioctl DRM_RADEON_CP_IDLE can unlock the R300's draw engine ?
In my understanding, the user-land radeon driver doesn't have COMMIT_RING()
as
kernel radeon driver, instead it just does ADVANCE_RING() (at the last step of
RADEON_WAIT_UNTIL_IDLE). So, the WAIT_UNTIL_IDLE operation doesn't update the
tail
pointer for CP ring, as a result, this CP commands in ring buffer are NOT
committed to CP at all and won't be executed. And the ioctl triggers kernel
driver to commit the CP command to CP in radeon_do_cp_idle(), it is the
COMMIT_RING() that works.
So, I imagine that I can replace the ioctl with a COMMIT_RING() operation. Is
my
understanding right ?
thanks,
ChaoHong
static void RADEONEnterServer(ScreenPtr pScreen)
{
ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum];
RADEONInfoPtr info = RADEONPTR(pScrn);
RADEONSAREAPrivPtr pSAREAPriv;
RADEON_MARK_SYNC(info, pScrn);
pSAREAPriv = DRIGetSAREAPrivate(pScrn->pScreen);
if (pSAREAPriv->ctxOwner != DRIGetContext(pScrn->pScreen))
info->XInited3D = FALSE;
/* TODO: Fix this more elegantly.
* Sometimes (especially with multiple DRI clients), this code
* runs immediately after a DRI client issues a rendering command.
*
* The accel code regularly inserts WAIT_UNTIL_IDLE into the
* command buffer that is sent with the indirect buffer below.
* The accel code fails to set the 3D cache flush registers for
* the R300 before sending WAIT_UNTIL_IDLE. Sending a cache flush
* on these new registers is not necessary for pure 2D functionality,
* but it *is* necessary after 3D operations.
* Without the cache flushes before WAIT_UNTIL_IDLE, the R300 locks up.
*
* The CP_IDLE call into the DRM indirectly flushes all caches and
* thus avoids the lockup problem, but the solution is far from ideal.
* Better solutions could be:
* - always flush caches when entering the X server
* - track the type of rendering commands somewhere and issue
* cache flushes when they change
* However, I don't feel confident enough with the control flow
* inside the X server to implement either fix. -- nh
if (info->ChipFamily>=CHIP_FAMILY_R300)
drmCommandNone(info->drmFD, DRM_RADEON_CP_IDLE);
}
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
