Re: Framebuffer read coherency (r3xx)

[Nicolai H. <nha...@gm...>]

Am Sonntag 08 Juni 2008 03:57:48 schrieb Dave Airlie:
> > Hmm, the radeon_cp_idle() should purge the destination cache (and wait
> > for it too, including checking the DC_BUSY bit).
> > At least the r200 driver has a comment in r200SpanRenderStart (including
> > a dodgy workaround) which sure looks like the same issue to me.
>
> We may purge the cache but not wait for the purge to finish...
>
> Sounds like some experiments time..
>
> There is also possibly a HOST data cache we need to deal with..

Okay, I've done some more poking around. First of all, I found out by mistake 
that the bug *also* appears with stand-alone software rendering Mesa. Since 
standalone Mesa still goes through the (DDX) driver to read and write pixels, 
this is probably some general problem in the driver, both 2D and 3D.

Now, I've played around some more with the test. Note that the exact order of 
operations is:

  Setup();
  Render();
  glReadPixels(11);
  glReadPixels(01);
  glReadPixels(10);
  glReadPixels(00);
  Render();
  glReadPixels(11);
  glReadPixels(01);
  glReadPixels(10);
  glReadPixels(00);
  Render();
  glReadPixels(00); <-- returns stale data
  glReadPixels(10);
  glReadPixels(01);
  glReadPixels(11);

The pixels 00, 10, 01, 11 are at the corner of a square of size 10x10 in the 
following way, i.e. the digits are basically xy-coordinates:

 01 -- 11
  |    |
 00 -- 10

Now the behaviour changes if I remove references to some or all of these 
pixels in the following:

1) Removing any of 01, 10, 11 changes nothing.
2) Removing (00 and 01) OR (10 and 11) [i.e. a column] removes the bug.
3) Removing 01 and 11 [i.e. the top row] causes the second glReadPixels(10) to 
return stale data.
4) Removing 00 and 10 [i.e. the bottom row] causes the second glReadPixels(11) 
to return stale data.
5) Removing all of 01, 10, 11 fixes the bug.

So the bug appears to be related to reading two samples from the same row 
twice.

Furthermore, it turns out that the bug depends on the exact onscreen 
coordinates of the pixels. It turns out that the bug only appears when the 
X-coordinate of the 00 pixel is between 0 and 5 (mod 16) (inclusive). The 
Y-coordinate appears to be entirely irrelevant.

A workaround like the R200 driver had all along in r200_span.c should fix the 
problem, *unless* we happen to be reading from the first row of the 
framebuffer.

cu,
Nicolai