> 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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev