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

[Ilia Mirkin]

On Thu, Nov 2, 2017 at 7:55 AM, Wladimir J. van der Laan
<laanwj at gmail.com> wrote:
> 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?

Hrmph. I wonder if this is all in reference to the void extent
decoding text: See C.2.23 in the spec:

"""
    The reason for the storage of UNORM16 values in the LDR case is due
    to the possibility that the value will need to be passed on to sRGB
    conversion. By storing the color value in the format which comes out
    of the interpolator, before the conversion to FP16, we avoid having
    to have separate versions for sRGB and linear modes.
"""

Not entirely sure what that piglit is testing for. dEQP has a whole
bunch of ASTC tests if you can run them. The piglit doesn't enable the
lower tolerance for that subtest (since is_srgb_test remains false),
so perhaps that's not in line with the spec? Or just a common hw
implementation bug?

  -ilia