[Mesa-dev] [PATCH 3/3] st/mesa: add astc support

[Ilia Mirkin]

On Sat, Nov 21, 2015 at 4:09 PM, Roland Scheidegger <sroland at vmware.com> wrote:
> Am 21.11.2015 um 21:03 schrieb Ilia Mirkin:
>> This doesn't account for the ldr/hdr distinction... that will probably
>> have to be exposed via a separate cap. When relevant hardware appears,
>> this can be worked out.
>>
>> Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>
>> ---
>>  src/mesa/state_tracker/st_extensions.c |  32 ++++-
>>  src/mesa/state_tracker/st_format.c     | 231 +++++++++++++++++++++++++++++++++
>>  2 files changed, 262 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/mesa/state_tracker/st_extensions.c b/src/mesa/state_tracker/st_extensions.c
>> index 99e96e1..a2418e2 100644
>> --- a/src/mesa/state_tracker/st_extensions.c
>> +++ b/src/mesa/state_tracker/st_extensions.c
>> @@ -343,7 +343,7 @@ struct st_extension_cap_mapping {
>>
>>  struct st_extension_format_mapping {
>>     int extension_offset[2];
>> -   enum pipe_format format[8];
>> +   enum pipe_format format[32];
>>
>>     /* If TRUE, at least one format must be supported for the extensions to be
>>      * advertised. If FALSE, all the formats must be supported. */
>> @@ -569,6 +569,36 @@ void st_init_extensions(struct pipe_screen *screen,
>>            PIPE_FORMAT_BPTC_RGB_FLOAT,
>>            PIPE_FORMAT_BPTC_RGB_UFLOAT } },
>>
>> +      { { o(KHR_texture_compression_astc_ldr) },
>> +        { PIPE_FORMAT_ASTC_4x4,
>> +          PIPE_FORMAT_ASTC_5x4,
>> +          PIPE_FORMAT_ASTC_5x5,
>> +          PIPE_FORMAT_ASTC_6x5,
>> +          PIPE_FORMAT_ASTC_6x6,
>> +          PIPE_FORMAT_ASTC_8x5,
>> +          PIPE_FORMAT_ASTC_8x6,
>> +          PIPE_FORMAT_ASTC_8x8,
>> +          PIPE_FORMAT_ASTC_10x5,
>> +          PIPE_FORMAT_ASTC_10x6,
>> +          PIPE_FORMAT_ASTC_10x8,
>> +          PIPE_FORMAT_ASTC_10x10,
>> +          PIPE_FORMAT_ASTC_12x10,
>> +          PIPE_FORMAT_ASTC_12x12,
>> +          PIPE_FORMAT_ASTC_4x4_SRGB,
>> +          PIPE_FORMAT_ASTC_5x4_SRGB,
>> +          PIPE_FORMAT_ASTC_5x5_SRGB,
>> +          PIPE_FORMAT_ASTC_6x5_SRGB,
>> +          PIPE_FORMAT_ASTC_6x6_SRGB,
>> +          PIPE_FORMAT_ASTC_8x5_SRGB,
>> +          PIPE_FORMAT_ASTC_8x6_SRGB,
>> +          PIPE_FORMAT_ASTC_8x8_SRGB,
>> +          PIPE_FORMAT_ASTC_10x5_SRGB,
>> +          PIPE_FORMAT_ASTC_10x6_SRGB,
>> +          PIPE_FORMAT_ASTC_10x8_SRGB,
>> +          PIPE_FORMAT_ASTC_10x10_SRGB,
>> +          PIPE_FORMAT_ASTC_12x10_SRGB,
>> +          PIPE_FORMAT_ASTC_12x12_SRGB } },
> Seems a bit excessive to check support for all formats - I'd guess all
> hw really would support just all or none. But this follows what is done
> for other formats, so why not.

It caught a bug I had where I accidentally forgot about 4 of the
formats due to... not sure why tbh. But they got lost in the driver
list somehow.

> I'm actually somewhat surprised there isn't any code somewhere assuming
> npot block size :-).

Probably there are some. I suspect that align() gets used somewhere
and it'll break. We'll find those in due time...

> FWIW we couldn't actually express the "real" 3d compressed astc formats
> in gallium util format code (as we only have block width/height, not
> depth), but apparently this is still something not implemented even with
> astc hdr (still just sliced 3d).

Right, not sure if any hw implements this either... this is the
OES_texture_compression_astc functionality.

>
> For the series:
> Reviewed-by: Roland Scheidegger <sroland at vmware.com>
>

Thanks!