From c5d8c8db3e75976687bfb364f0a7b235c7ae8793 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Michel=20D=C3=A4nzer?= Date: Sat, 24 Jun 2006 16:01:19 +0200 Subject: Bug #7274: Fix corruption with 'small' accelerated DownloadFromScreen transfers. --- src/radeon_exa_funcs.c | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) (limited to 'src/radeon_exa_funcs.c') diff --git a/src/radeon_exa_funcs.c b/src/radeon_exa_funcs.c index bc22147..a86e148 100644 --- a/src/radeon_exa_funcs.c +++ b/src/radeon_exa_funcs.c @@ -51,6 +51,7 @@ #endif #endif +#include #include #include "radeon.h" @@ -379,7 +380,7 @@ FUNC_NAME(RADEONDownloadFromScreen)(PixmapPtr pSrc, int x, int y, int w, int h, #endif while (h) { - int oldhpass = hpass; + int oldhpass = hpass, i = 0; src = (CARD8*)scratch->address + scratch_off; @@ -394,8 +395,19 @@ FUNC_NAME(RADEONDownloadFromScreen)(PixmapPtr pSrc, int x, int y, int w, int h, x, y, 0, 0, w, hpass); } - /* Wait for previous blit to complete */ - RADEONWaitForIdleMMIO(pScrn); + /* + * Wait for previous blit to complete. + * + * XXX: Doing here essentially the same things this ioctl does in + * the DRM results in corruption with 'small' transfers, apparently + * because the data doesn't actually land in system RAM before the + * memcpy. I suspect the ioctl helps mostly due to its latency; what + * we'd really need is a way to reliably wait for the host interface + * to be done with pushing the data to the host. + */ + while ((drmCommandNone(info->drmFD, DRM_RADEON_CP_IDLE) == -EBUSY) + && (i++ < RADEON_TIMEOUT)) + ; /* Kick next blit */ if (hpass) -- cgit v1.2.3