Re: [Mesa3d-dev] r200 and hyperz

[Roland S. <sr...@tu...>]

Stephane Marchesin wrote:
> On 2/27/08, Philipp Klaus Krause <pk...@sp...> 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