[Mesa-dev] [PATCH] r300g: Fix the ATI1N swizzle.

[Ilia Mirkin]

On Mon, Mar 9, 2015 at 12:11 PM, Stefan Dösinger <stefandoesinger at gmx.at> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Am 2015-03-09 um 16:53 schrieb Stefan Dösinger:
>> I did test if LATC_UNORM and LATC_SNORM still work after my fix.
>> LATC_SNORM is unchanged (broken in the same way as RGTC_SNORM) and
>> LATC_UNORM now has the proper precision like RGTC_UNORM.
> I think the reason why _SNORM is broken is that the way the driver
> tries to emulate them is conceptually broken. It handles them like the
> _UNORM variant, but afterwards does a red = red > 0.5 ? red * 2 - 2 :
> red * 2.

Contrary to the comments, it appears that it actually uses 2.35
instead of 2.0? Haven't done the math, but I guess it makes some cases
work out better...

>
> That may work for an uncompressed signed format, but it doesn't take
> into account the block decompression of RGTC1. For example consider a
> block that has red1 = 0x7f and red2 = 0x80. As an unsigned value, red2
> is the bigger value(127 vs 128). If it is a signed value, red1 is
> bigger (127 vs -128). The only way this will work is if the driver
> adds +128 to red1 and red2 for each block before loading (sucks if
> it's in a PBO) and after sampling does red = red * 2.0 - 1.0. And I'm
> not even sure if that will work. It will at least break exact zeros.

It also has the additional problem that it doesn't do the swizzle
workaround which apparently is necessary even for single-component
textures.

>
> Note that I don't care about the signed RGTC formats. Wine on this
> card will only ever need the unsigned ones, as they match ATI1N and
> ATI2N in d3d.

Makes sense. BTW, I'm in no way knowledgeable about r300... just
seemed like an interesting bit of code to glance at. Hopefully one of
the AMD guys will be able to look at the actual patch.

Cheers,

  -ilia