From ac860ed6bbed84f6fc39a9acf53ee87646cfc8dc Mon Sep 17 00:00:00 2001 From: Vladimir Dergachev Date: Fri, 17 Dec 2004 16:50:36 +0000 Subject: =?UTF-8?q?Modified:=20programs/Xserver/hw/xfree86/drivers/ati/rad?= =?UTF-8?q?eon=5Faccel.c=20programs/Xserver/hw/xfree86/drivers/ati/radeon?= =?UTF-8?q?=5Fdri.c=20Move=20DMA=20robustness=20fix=20into=20radeon=5Fdri.?= =?UTF-8?q?c::RADEONEnterServer()=20as=20per=20=20=20=20=20suggestion=20by?= =?UTF-8?q?=20Michel=20D=E4nzer.=20I=20could=20not=20trigger=20a=20lockup,?= =?UTF-8?q?=20even=20with=20r300=5Fdemo=20(possibly=20it=20has=20code=20?= =?UTF-8?q?=20=20=20=20that=20flushes=20cache=20inside=20=3F),=20so=20this?= =?UTF-8?q?=20must=20be=20good=20enough..?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- src/radeon_accel.c | 42 ------------------------------------------ src/radeon_dri.c | 43 +++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 43 insertions(+), 42 deletions(-) diff --git a/src/radeon_accel.c b/src/radeon_accel.c index 3e14217f..ac422571 100644 --- a/src/radeon_accel.c +++ b/src/radeon_accel.c @@ -556,44 +556,6 @@ void RADEONCPFlushIndirect(ScrnInfoPtr pScrn, int discard) buffer->idx); } - /* 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 - */ - - /* On my computer (Radeon Mobility M10) - The fix below results in x11perf -shmput500 rate of 225.0/sec - which is lower than 264.0/sec I get without it. - - On the other hand, not using CP acceleration at all benchmarks - at 144.0/sec. - - For now let us accept this as a lesser evil, especially as the - DRM driver for R300 is still in flux. - - Once the code is more stable this should probably be moved into DRM driver. - */ - - if (info->ChipFamily>=CHIP_FAMILY_R300) - drmCommandNone(info->drmFD, DRM_RADEON_CP_IDLE); - indirect.idx = buffer->idx; indirect.start = start; indirect.end = buffer->used; @@ -633,10 +595,6 @@ void RADEONCPReleaseIndirect(ScrnInfoPtr pScrn) buffer->idx); } - /* Hack for the R300 (see RADEONCPFlushIndirect for explanation) */ - if (info->ChipFamily>=CHIP_FAMILY_R300) - drmCommandNone(info->drmFD, DRM_RADEON_CP_IDLE); - indirect.idx = buffer->idx; indirect.start = start; indirect.end = buffer->used; diff --git a/src/radeon_dri.c b/src/radeon_dri.c index 73349620..22062ec6 100644 --- a/src/radeon_dri.c +++ b/src/radeon_dri.c @@ -354,6 +354,49 @@ static void RADEONEnterServer(ScreenPtr pScreen) if (pSAREAPriv->ctxOwner != DRIGetContext(pScrn->pScreen)) info->RenderInited3D = FALSE; #endif + + /* 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 + */ + + /* On my computer (Radeon Mobility M10) + The fix below results in x11perf -shmput500 rate of 245.0/sec + which is lower than 264.0/sec I get without it. + + Doing the same each time before indirect buffer is submitted + results in x11perf -shmput500 rate of 225.0/sec. + + On the other hand, not using CP acceleration at all benchmarks + at 144.0/sec. + + For now let us accept this as a lesser evil, especially as the + DRM driver for R300 is still in flux. + + Once the code is more stable this should probably be moved into DRM driver. + */ + + if (info->ChipFamily>=CHIP_FAMILY_R300) + drmCommandNone(info->drmFD, DRM_RADEON_CP_IDLE); + + } /* Called when the X server goes to sleep to allow the X server's -- cgit v1.2.3