diff options
author | Marek Olšák <maraeo@gmail.com> | 2011-01-25 05:37:52 +0100 |
---|---|---|
committer | Marek Olšák <maraeo@gmail.com> | 2011-01-27 18:12:01 +0100 |
commit | db299a9f8244d53d9041fcdbd396a77ebe1f9e3e (patch) | |
tree | 60adc94f4a132101be84579bf57988283e20ef90 /src/gallium/drivers/r300/r300_screen_buffer.c | |
parent | 7a4345fd83605695dc641af503f6e87b808b48d7 (diff) |
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.
Diffstat (limited to 'src/gallium/drivers/r300/r300_screen_buffer.c')
0 files changed, 0 insertions, 0 deletions