r300g: fix some bugs with zbuffer compression (v4)

This drops the memblock manager for ZMASK. Instead, only one zbuffer can be
compressed at a time. Note that this does not necessarily have to be slower.
When there is a large number of zbuffers, compression might be used more often
than it was before. It's also easier to debug.

How it works:
1) 'clear' turns the compression on.
2) If some other zbuffer is set or the currently-bound zbuffer is used
   for texturing, the driver decompresses it and then turns the compression off.

Notes:
- The ZMASK clear has been refactored, so that only one packet3 is used to clear
  ZMASK.
- The 8x8 compression mode is disabled. I couldn't make it work without issues.
- Also removed driver-specific stuff from u_blitter.

Driver status:
- RV530 and R580 appear to just work (finally).
- RV570 should work, but there may be an issue that we don't correctly
  calculate the number of dwords to clear, resulting in a partially
  uninitialized zbuffer.
- RS690 misrenders as if no ZMASK clear happened. No idea what's going on.
- RV350 may even hardlock. This issue was already present and this patch doesn't
  fix it.

I think we are still missing some hardware info we need to make the zbuffer
compression work fully.

Note that there is also an issue with HiZ, resulting in a sort of blocky
zigzagged corruption around some objects.

1 files changed, 2 insertions, 0 deletions

diff --git a/src/gallium/drivers/r300/r300_chipset.c b/src/gallium/drivers/r300/r300_chipset.c
index 2b183f6..15dc6d0 100644
--- a/src/gallium/drivers/r300/r300_chipset.c
+++ b/src/gallium/drivers/r300/r300_chipset.c
@@ -424,5 +424,7 @@ void r300_parse_chipset(struct r300_capabilities* caps)
     }
 
     caps->is_rv350 = caps->family >= CHIP_FAMILY_RV350;
+    /* XXX The 8x8 compression mode doesn't always work (piglit/fbo-depth fails). */
+    caps->z_compress = /*caps->is_rv350 ? R300_ZCOMP_8X8 :*/ R300_ZCOMP_4X4;
     caps->dxtc_swizzle = caps->is_r400 || caps->is_r500;
 }