[Mesa-dev] [PATCH 0/2] etnaviv: ASTC texture support

[Ilia Mirkin]

On Wed, Nov 1, 2017 at 1:19 PM, Wladimir J. van der Laan
<laanwj at gmail.com> wrote:
> Add ASTC texture support for hardware that supports this
> (currently only GC3000 on i.MX6qp is known to have this).
>
> Piglit output:
>
>     $ bin/khr_compressed_astc-miptree_gles2
>     PIGLIT: {"subtest": {"LDR Profile" : "pass"}}
>     PIGLIT: {"subtest": {"HDR Profile" : "pass"}}
>     PIGLIT: {"subtest": {"sRGB decode" : "pass"}}
>     Probe at (144,44)
>     Expected: 0.972549 0.972549 0.972549 1.000000
>     Observed: 0.984314 0.984314 0.984314 1.000000
>     piglit: error: Miplevel 0
>     piglit: error: Mode ldrs Block 4x4.
>     PIGLIT: {"subtest": {"sRGB decode full precision" : "fail"}}
>     PIGLIT: {"subtest": {"sRGB skip decode" : "pass"}}
>
> This means all block sizes are working, and basic RGB/sRGB.
>
> Not sure why "sRGB decode full precision" is not passing,
> probably the hw just doesn't do that.

On the off chance that you're not intimately familiar with ASTC,
there's the concept of decoding into UNORM8 and FP16's. I don't mean
the external view of it, but internal as part of the decompression.
The end result is what it is, but with FP16 you get more precision esp
when doing sRGB correction (perhaps only when you do sRGB correction).

"""
    If sRGB conversion is enabled, the top 8 bits of the interpolation
    result for the R, G and B channels are passed to the external sRGB
    conversion block. Otherwise, if C = 65535, then the final result is
    1.0 (0x3C00) otherwise C is divided by 65536 and the infinite-precision
    result of the division is converted to FP16 with round-to-zero
    semantics.
"""

And HDR is supposed to be all-FP16. Anyways, I wouldn't be surprised
if some of those UNK's enable FP16 decoding.

  -ilia