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

[Wladimir J. van der Laan]

On Wed, Nov 01, 2017 at 01:27:30PM -0400, Ilia Mirkin wrote:
> 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,

I'm not - my reason for doing this was to become more familiar with it.

> 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.

Thanks for the explanation, that explains why the combinatorial explosion is
limited to block sizes and SRGB, not other pixel formats.

> 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.

It's possible (the state has to do something), though the blob driver only
reports "GL_KHR_texture_compression_astc_ldr", no HDR support.
(so the piglit "HDR profile" test compares against error-magenta)

Is high-precision sRGB decoding support expected in that case?

Regards,
Wladimir