Stephane Marchesin wrote: > On 2/27/08, Philipp Klaus Krause <[EMAIL PROTECTED]> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Stephane Marchesin schrieb: >> >> >> > >> > Basically, this means that the zbuffer values cannot be read from the >> > CPU to do proper fallbacks (i.e. for emulating things the card cannot >> > do itself) because the zbuffer is compressed. >> >> >> Does that mean that all programs that read the depth buffer for stuff >> like selection will fail, too? >> > > Yes
Indeed and I'm more worried about that than usual fallbacks, which should never really happen for stuff people care about (the chip does things like line aa just fine, texture border will cause fallback but noone uses it). So reading/writing depth/stencil buffer is just broken with hyperz. Actually, there are some other little bugs too I think - clearing partial buffers (using scissor) doesn't work correctly I assume (since fastz clear will only clear whole tiles - would need to either disable fastz clear in such cases or rather only clear complete tiles and use "normal" clear for partial tiles). Similar, multiple 3d windows might show errors if they happen to share some tiles at their borders. As for reading/writing depth/stencil buffer with hyperz, writing could be fixed by turning each depth/stencil write into a point render instead. However, reading is more difficult. With one approach, you'd first need to read the tile tags from the chip - if it says cleared, the depth value is the last cleared value. If it's not cleared and not compressed, simply read back as usual. If it's not cleared and compressed, read back the tile (1/2 or 1/4 the uncompressed size, can't remember) and decompress in software. With another approach, it might be possible to force the chip to read the depth buffer tile you're interested in (some sort of dummy render), then get the data directly from the (decompressed) z cache (or preferably tell the chip to write it somewhere). I dunno how feasible those approaches really are, both methods seemed rather complex, without knowing how this really should be handled... Though hyperz nowadays seems to be documented (not for r200 however), I haven't looked if there are some more ideas in that area... Roland ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
