r300: Workaround hardware readcache problem

This workaround is similar to the one found in r200_span.c.
It seems like some part of the read hardware doesn't realize that
VRAM has changed. By reading from an arbitrary position, this is fixed.

The piglit test bugs/r300-readcache is a regression test for this bug.

diff --git a/src/mesa/drivers/dri/r300/radeon_span.c b/src/mesa/drivers/dri/r300/radeon_span.c
index eae09d6b35eb95dd4939e97e26f7bc1c54eab820..f1bc56ea6a4de5b7a32e5d0cc84afb5ba8de15ee 100644 (file)
--- a/src/mesa/drivers/dri/r300/radeon_span.c
+++ b/src/mesa/drivers/dri/r300/radeon_span.c
@@ -282,6 +282,30 @@ static void radeonSpanRenderStart(GLcontext * ctx)
 #endif
        LOCK_HARDWARE(rmesa);
        radeonWaitForIdleLocked(rmesa);
+
+       /* Read the first pixel in the frame buffer.  This should
+        * be a noop, right?  In fact without this conform fails as reading
+        * from the framebuffer sometimes produces old results -- the
+        * on-card read cache gets mixed up and doesn't notice that the
+        * framebuffer has been updated.
+        *
+        * Note that we should probably be reading some otherwise unused
+        * region of VRAM, otherwise we might get incorrect results when
+        * reading pixels from the top left of the screen.
+        *
+        * I found this problem on an R420 with glean's texCube test.
+        * Note that the R200 span code also *writes* the first pixel in the
+        * framebuffer, but I've found this to be unnecessary.
+        *  -- Nicolai Hähnle, June 2008
+        */
+       {
+               int p;
+               driRenderbuffer *drb =
+                       (driRenderbuffer *) ctx->WinSysDrawBuffer->_ColorDrawBuffers[0];
+               volatile int *buf =
+                       (volatile int *)(rmesa->dri.screen->pFB + drb->offset);
+               p = *buf;
+       }
 }
 
 static void radeonSpanRenderFinish(GLcontext * ctx)