This repository was archived by the owner on Jan 7, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Jan 7, 2023. It is now read-only.
[mesa 19.1.6]android.hardware.nativehardware.cts.AHardwareBufferNativeTests failed #134
Description
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
Activity
tpalli commentedon Oct 3, 2019
This passes fine for me with following Mesa branch (near master):
https://github.com/tpalli/external-mesa/tree/rebase_20190930
renchenglei commentedon Oct 9, 2019
Hi @tpalli, did you also upgrade minigbm to latest?
https://github.com/intel/minigbm
tpalli commentedon Oct 9, 2019
Maybe not (?) I'm just using what comes with 'repo sync'. Will try later if I missed some commits.
tpalli commentedon Oct 10, 2019
OK yeah, now it fails due to incomplete framebuffer. Will investigate.
tpalli commentedon Oct 10, 2019
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 commentedon Oct 10, 2019
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 commentedon Oct 11, 2019
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 commentedon Oct 11, 2019
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 commentedon Oct 11, 2019
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.
tpalli commentedon Oct 11, 2019
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 commentedon Oct 11, 2019
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 commentedon Oct 11, 2019
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 commentedon Oct 11, 2019
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 commentedon Oct 11, 2019
@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!
tpalli commentedon Oct 11, 2019
Thanks @renchenglei, I've created a PR here:
#136
renchenglei commentedon Oct 11, 2019
@tpalli, ok! Thanks a lot!