[mesa 19.1.6]android.hardware.nativehardware.cts.AHardwareBufferNativeTests failed

[renchenglei]

One android.hardware.nativehardware.* case failedon Android 10 with mesa 19.1.6.

android.hardware.nativehardware.cts.AHardwareBufferNativeTests#SingleLayer_ColorTest_GpuColorOutputAndSampledImage_R10G10B10A2_UNORM

This issue also could be reproduced on Android 10 with mesa 19.0.6.
We have tried with upstream master branch(e4a52bd), and this issue is still here
We revert following commit d2b60e4 in mesa, case could pass and no regression from dEQP and other cts modules.

commit d2b60e433e50032e398fb92181f22a78601a5538
Author: Nicolai Hähnle <nicolai.haehnle@amd.com>
Date:   Wed Sep 27 15:25:10 2017 +0200

    mesa/main: R10G10B10_(A2) formats are not color renderable in ES

    The EXT_texture_type_2_10_10_10_REV (ES only) states the following issue:

       "1. Should textures specified with this type be renderable?

        UNRESOLVED: No.  A separate extension could provide this functionality."

    This partially fixes
    dEQP-GLES3.functional.fbo.completeness.renderable.texture.color0.{rgb,rgba}_unsigned_int_2_10_10_10_rev

    Reviewed-by: Marek Olšák <marek.olsak@amd.com>

Steps to reproduce this issue(run with cts packages):

run cts -m CtsNativeHardwareTestCases -t android.hardware.nativehardware.cts.AHardwareBufferNativeTests#SingleLayer_ColorTest_GpuColorOutputAndSampledImage_R10G10B10A2_UNORM

[tpalli]

This passes fine for me with following Mesa branch (near master):
https://github.com/tpalli/external-mesa/tree/rebase_20190930

[renchenglei]

Hi @tpalli, did you also upgrade minigbm to latest?
https://github.com/intel/minigbm

[tpalli]

Maybe not (?) I'm just using what comes with 'repo sync'. Will try later if I missed some commits.

[tpalli]

OK yeah, now it fails due to incomplete framebuffer. Will investigate.

[tpalli]

Yeah, in this case for some reason the internalformat is unsized GL_RGBA while spec only allows explicitly sized internal format. Will need to see why this is happening.

[renchenglei]

Here we add render usage for RGBA1010102 as some other cases ask for render usage.
https://github.com/intel/minigbm/pull/88/files#diff-44dcf7ec91657ef4bd641a0d29fa81b5R111
Not sure if it is reasonable to add RGBA1010102 to renderable format.

[tpalli]

IMO it is OK to add RGBA1010102 as renderable format, we do support this and there are many other tests rendering to this format with Mesa. This seems to go via glEGLImageTargetTexture2DOES path, maybe something is going wrong already there, we should check how the texture bound to that EGLImage was generated.

[tpalli]

This fixes the issue:
https://gitlab.freedesktop.org/tpalli/mesa/commit/86259b7936877c7a9c6b4ea216449615ac078068

However, it's not quite clear to me why the original internalformat is GL_RGBA and if that is actually a bug in the test itself. Will need to investigate more.

[renchenglei]

Thanks @tpalli! Could you also help to create one PR on github? We may include the PR, and create one EB, and then have one round of full test.
I also have some debugging work for this issue before. And found there is some issue that RBGA1010102 is removed from renderable format. When I added it back, issue also could be gone.
I reverted following commit d2b60e4 in mesa, case could pass and no regression from dEQP and other cts modules. Not sure if this is right.

commit d2b60e433e50032e398fb92181f22a78601a5538
Author: Nicolai Hähnle <nicolai.haehnle@amd.com>
Date:   Wed Sep 27 15:25:10 2017 +0200

    mesa/main: R10G10B10_(A2) formats are not color renderable in ES

    The EXT_texture_type_2_10_10_10_REV (ES only) states the following issue:

       "1. Should textures specified with this type be renderable?

        UNRESOLVED: No.  A separate extension could provide this functionality."

    This partially fixes
    dEQP-GLES3.functional.fbo.completeness.renderable.texture.color0.{rgb,rgba}_unsigned_int_2_10_10_10_rev

    Reviewed-by: Marek Olšák <marek.olsak@amd.com>

[tpalli]

Yes I noticed this but Nicolai's commit looks good to me. GLES does not allow rendering to texture with unsized format (such as GL_RGBA), it should allow only GL_RGB10_A2 so that should be valid restriction. I will need to check if my patch is indeed correct or if there is a bug in the test. I believe that meanwhile it should be safe to use my patch as a WA, I'm currently running it through Mesa CI and will report if there are any regressions from it.

[renchenglei]

ok, got it, thanks a lot! Once there is no regression, please help create one PR, we would trigger one round of full CTS GFX test. :)

[tpalli]

So ... I'm still a bit confused with how Celadon trees work. I keep using 'project-celadon' but now and then some trees should be used from 'intel' instead. For which tree should I send this PR for?

[tpalli]

I sent here MR against Mesa master:
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2305

If my fix is not correct, we probably hear it from there :)

[renchenglei]

@tpalli, thanks a lot for the MR. If possible, please help send this PR to 'intel'.
'project-celadon' is some like "release" branch. We need confirm the quality of whole image.
'intel' is our internal developing branch. We will rebase new mesa version to 'intel', and then fix Android specific issues. Once it is stable. We will push 'intel' to 'project-celadon'(most of time, we need pass CTS GFX test and sanity test). Currently, mesa on 'project-celadon' is 19.0.6. mesa version of 'intel' is 19.1.6. Now, we are working to fix all CTS issues based on 19.1.6. Once all are fixed, we will push 19.1.6 to 'project-celadon'. :)
We could push the PR to 'intel' and build EB on gfx build bot, the difference between 'intel' and 'project-celadon' is four gfx repos: minigbm, mesa, libdrm and hwc. The new changes is on 'intel'.
Hope this could help on the confusion, if any other confusion, please help point out, thanks a lot!