[Mesa-stable] [PATCH v2 2/2] i965/formats: Update the three-channel DXT1 mappings

[Nanley Chery]

On Fri, May 12, 2017 at 01:33:54PM -0700, Nanley Chery wrote:
> The procedure for decompressing an opaque DXT1 OpenGL format is
> dependant on the comparison of two colors stored in the first 32 bits of
> the compressed block. Here's the specified OpenGL behavior for
> reference:
> 
>    The RGB color for a texel at location (x,y) in the block is given by:
> 
>       RGB0,              if color0 > color1 and code(x,y) == 0
>       RGB1,              if color0 > color1 and code(x,y) == 1
>       (2*RGB0+RGB1)/3,   if color0 > color1 and code(x,y) == 2
>       (RGB0+2*RGB1)/3,   if color0 > color1 and code(x,y) == 3
> 
>       RGB0,              if color0 <= color1 and code(x,y) == 0
>       RGB1,              if color0 <= color1 and code(x,y) == 1
>       (RGB0+RGB1)/2,     if color0 <= color1 and code(x,y) == 2
>       BLACK,             if color0 <= color1 and code(x,y) == 3
> 
> The sampling operation performed on an opaque DXT1 Intel format essentially
> hard-codes the comparison result of the two colors as color0 > color1.
> This means that the behavior is incompatible with OpenGL. This is stated
> in the SKL PRM, Vol 5: Memory Views:
> 
>    Opaque Textures (DXT1_RGB)
>       Texture format DXT1_RGB is identical to DXT1, with the exception that the
>       One-bit Alpha encoding is removed. Color 0 and Color 1 are not compared, and
>       the resulting texel color is derived strictly from the Opaque Color Encoding.
>       The alpha channel defaults to 1.0.
> 
>       Programming Note
>       Context: Opaque Textures (DXT1_RGB)
>       The behavior of this format is not compliant with the OGL spec.
> 
> The opaque and non-opaque DXT1 OpenGL formats are specified to be
> decoded in exactly the same way except the BLACK value must have a
> transparent alpha channel in the latter. Use the four-channel BC1 Intel
> formats with the alpha set to 1 to provide the behavior required by the
> spec. Note that the alpha is already set to 1 for RGB formats in
> brw_get_texture_swizzle().

The last sentence actually turned out to be false. I plan to send out a
v3 of this patch along with the Piglit test used to find this issue.