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.

1 files changed, 24 insertions, 0 deletions

diff --git a/src/mesa/drivers/dri/r300/radeon_span.c b/src/mesa/drivers/dri/r300/radeon_span.c
index eae09d6b35..f1bc56ea6a 100644
--- 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)