[Mesa-dev] [PATCH 2/2] etnaviv: ASTC texture support
Wladimir J. van der Laan
laanwj at gmail.com
Wed Nov 1 19:32:52 UTC 2017
> 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
More information about the mesa-dev
mailing list