fdo-mirrors/mesa
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/mesa/mesa.git synced 2026-04-27 11:00:37 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions 1

r300: Workaround hardware readcache problem

Browse source 
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.
This commit is contained in:
Nicolai Haehnle 2008-06-08 22:36:20 +02:00
parent f440b0ddd9
commit 0009973119
1 changed files with 24 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

24
src/mesa/drivers/dri/r300/radeon_span.c
View file

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