gallium: Fix big-endian addressing of non-bitmask array formats.
authorEric Anholt <eric@anholt.net>
Thu, 15 Aug 2019 22:38:00 +0000 (15:38 -0700)
committerEric Anholt <eric@anholt.net>
Wed, 28 Aug 2019 17:39:36 +0000 (10:39 -0700)
commitd17ff2f7f1864c81c1e00d04baf20f953c6d276a
tree73bb3be0d5af95634b83f36531ed3bf52fc4a1e0
parent0547fdd7ee02b1160dcfa4b8dee23e52ced60599
gallium: Fix big-endian addressing of non-bitmask array formats.

The formats affected are:

- LA x (16_FLOAT, 32_FLOAT, 32_UINT, 32_SINT)
- R8G8B8 x (UNORM, SNORM, SRGB, USCALED, SSCALED, UINT, SINT)
- RG/RGB/RGBA x (64_FLOAT, 32_FLOAT, 16_FLOAT, 32_UNORM, 32_SNORM,
                 32_USCALED, 32_SSCALED, 32_FIXED, 32_UINT, 32_SINT)
- RGB/RGBA x (16_UNORM, 16_SNORM, 16_USCALED, 16_SSCALED,
              16_UINT, 16_SINT)
- RGBx16 x (UNORM, SNORM, FLOAT, UINT, SINT)
- RGBx32 x (FLOAT, UINT, SINT)
- RA x (16_FLOAT, 32_FLOAT, 32_UINT, 32_SINT)

The updated st_formats.c unit test checks that the formats affected by
this change are all array formats in the equivalent Mesa format (if
any).  Mesa's array format definition is clear: the value stored is an
array (increasing memory address) of values of the channel's type.
It's also the only thing that makes sense for the RGB types, or very
large types like RGBA64_FLOAT (A should not move to the low address
because the cpu is BE).

Acked-by: Roland Scheidegger <sroland@vmware.com>
Acked-by: Adam Jackson <ajax@redhat.com>
Tested-by: Matt Turner <mattst88@gmail.com> (unit tests on BE)
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
src/gallium/auxiliary/util/u_format_parse.py
src/mesa/state_tracker/tests/st_format.c