[Mesa-dev] [PATCH] mesa: fix rgtc snorm decoding

Roland Scheidegger sroland at vmware.com
Mon Jul 22 14:42:11 PDT 2013


Am 22.07.2013 22:52, schrieb Matt Turner:
> On Mon, Jul 22, 2013 at 12:22 PM,  <sroland at vmware.com> wrote:
>> From: Roland Scheidegger <sroland at vmware.com>
>>
>> The codeword must be unsigned (otherwise will shift in 1's from above when
>> merging low/high parts so some texels decode wrong).
>> This also affects gallium's util/u_format_rgtc.
>> ---
> 
> Write a piglit test for this too?
> 

To be sure to catch this sort of error a full permutation of all
possible encodings would be necessary (fortunately only for the first 8
pixels in a block). That's 2^24 possibilities (times 2 for the alpha 0
larger / smallerequal than alpha 1). Doesn't seem worth it for something
hw will surely do right (hw surely won't care about bit position).
Granted to test for this specfic bug only one case would be necessary -
I think the few tests which do signed rgtc testing just don't happen to
hit an affected encoding. Are there similar tests for any compressed
formats testing all different encodings?

FWIW the bit extraction is a bit more complicated than I'd like anyway.
Instead of all that magic getting the full block as a 64bit value +
64bit shift (and a mask) would be way simpler. But a) I don't know if
the code generated for 32bit would look all that good (should be ok
though I think) and b) it probably doesn't work on big endian. But that
error definitely wouldn't happen.

Roland


More information about the mesa-dev mailing list