XLibre/xf86-video-ati
1
0
Fork 0
mirror of https://github.com/X11Libre/xf86-video-ati.git synced 2026-03-24 01:24:43 +00:00
Code Issues Packages Projects Releases Wiki Activity

Modified:

Browse Source 
programs/Xserver/hw/xfree86/drivers/ati/radeon_accel.c
programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c
Move DMA robustness fix into radeon_dri.c::RADEONEnterServer() as per
    suggestion by Michel Dnzer.
I could not trigger a lockup, even with r300_demo (possibly it has code
    that flushes cache inside ?), so this must be good enough..
This commit is contained in:
Vladimir Dergachev
2004-12-17 16:50:36 +00:00
parent 3ba5b525c4
commit ac860ed6bb
2 changed files with 43 additions and 42 deletions
Download Patch File Download Diff File Expand all files Collapse all files

42
src/radeon_accel.c
View File

@@ -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;

43
src/radeon_dri.c
View File

@@ -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