[PATCH 2/2] etnaviv: ASTC texture support

[Wladimir J. van der Laan]

> These formats are in a completely different space from the others, in the
> hardware (programmed through a different register), so IMO it makes sense to
> add a new format bit for it, just like for EXT_FORMAT.
> 
> Relying on mesa's judgement on whether something is astc seems brittle.
> 
> 
> Sorry I do not share this option. Did you had a look at
> https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/auxiliary/util/u_
> format.csv ?
> 
> All astc formats are marked as those and why should we not trust mesa here?

Well vivante's opinion of what an ASTC format might differ from mesa's
some day. I think we should keep specific implementation details
such as what register switches formats contained to our driver.
This keeps etnaviv_format.c self-contained.

It's not like we're running out of bits or something. I really disagree
with calling into mesa for this, at least in the sampler view code.

> Such helper could look like:  https://hastebin.com/jelisigife.m
> 
> Do we need ctx->specs.tex_astc at all? We could simply do it like this in
> etnaviv_screen.c:
> 
> if (util_format_is_astc(format))
>       supported = VIV_FEATURE(screen, chipMinorFeatures4, TEXTURE_ASTC);

It's also using this in the state emit code, where directly calling into
VIV_FEATURE is ugly.

Also, some GPUs seem to have TEXTURE_ASTC but broken ASTC (such as the GC7000lite)
so this logic must be extended some day. Having a specs bit is easier
for that.

(also, vivante is doing away with feature bits on newer GPUs; we're
going to have our own model->specs mapping database like them at some point)

Wladimir