On Sat, Nov 21, 2015 at 4:09 PM, Roland Scheidegger <srol...@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 <imir...@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 <srol...@vmware.com>
>
Thanks!
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
