Recent versions of the GLES3 conformance test suite fail this test. #beginTestCaseResult ES2-CTS.gtf.GL2ExtensionTests.egl_image.egl_image <?xml version="1.0"?> <TestCaseResult Version="0.3.2" CasePath="ES2-CTS.gtf.GL2ExtensionTests.egl_image.egl_image" CaseType="SelfValidate"> <Text>GTFExtensionTestEGLImageApply::Apply/error: GL error produced in checkpoint 1</Text> <Text>GTFRunTest: FAIL</Text> <Text>0 passes, 1 failures, test case FAILED!</Text> <Result StatusCode="Fail">Fail</Result> </TestCaseResult> #endTestCaseResult This test used to pass, but... I re-ran this test on Mesa 10.3 on BDW. This is the configuration that was used for the BDW conformance submission. The test failed. I reverted to an older version of the CTS, and re-ran 10.3 on BDW. The test passes, but the same "GL error produced in checkpoint 1" message is produced. It seems this test may have always failed, but the test suite wasn't smart enough to notice. For that reason, I am not marking this as a regression.
Mark: Do any of the CI system fail this test? I didn't see an existing bug for it.
Partially trimmed backtrace. #0 _mesa_error (ctx=0x7ffff7fa3040, error=1282, fmtString=0x7ffff3b8b1e8 "glEGLImageTargetRenderbufferStorage(unsupported image format") at main/errors.c:1471 #1 0x00007ffff3a24bf3 in intel_image_target_renderbuffer_storage ( ctx=0x7ffff7fa3040, rb=0x13f5730, image_handle=0x13500b0) at intel_fbo.c:353 #2 0x00007ffff35f0402 in _mesa_EGLImageTargetRenderbufferStorageOES ( target=36161, image=0x13500b0) at main/fbobject.c:2214 #3 0x0000000000b0b0c3 in RunRenderbufferTest (pTestEGLImage=0x138c7c0, windowWidth=64, windowHeight=64, glEGLImageTargetTexture2DOES=0x7ffff49579a0 <shared_dispatch_stub_1276>, glEGLImageTargetRenderbufferStorageOES=0x7ffff4957980 <shared_dispatch_stub_1275>, image=0x13500b0, format=6408, type=5121) at /home/idr/devel/graphics/ESCTS-3.0.4.0-20150622/conform/GTF_ES/glsl/GTF/Source/GL2ExtensionTests/GTFExtensionTestEGLImage.c:775 #4 0x0000000000b0c915 in GTFExtensionTestEGLImageApply ( pTestEGLImage=0x138c7c0) at /home/idr/devel/graphics/ESCTS-3.0.4.0-20150622/conform/GTF_ES/glsl/GTF/Source/GL2ExtensionTests/GTFExtensionTestEGLImage.c:1366 #5 0x00000000009f3a47 in GTFTestExtensionApply (pTestExtension=0x1355df0) at /home/idr/devel/graphics/ESCTS-3.0.4.0-20150622/conform/GTF_ES/glsl/GTF/Source/GTFTestExtension.c:514
this passes on master for me: http://otc-mesa-ci.jf.intel.com/job/Leeroy/217397/testReport/piglit.es2-cts.gtf.gl2extensiontests/egl_image/egl_image_bdwm64/
This test also passes on 11.0 and 10.6 branches, eg: http://otc-mesa-ci.jf.intel.com/job/Leeroy/206465/testReport/piglit.es2-cts.gtf.gl2extensiontests/egl_image/egl_image_bdwm64/
Hmm... I wonder if non-GBM vs GBM is the difference. Weird.
Patch sent to mesa-dev for review: http://lists.freedesktop.org/archives/mesa-dev/2015-October/097282.html
Fixed by the following commit. This commit should be included in Mesa 11.0.5. commit 7070c8879adff2a1204d7473f119d8194eff919b Author: Ian Romanick <ian.d.romanick@intel.com> Date: Thu Oct 15 12:50:12 2015 -0700 i965: Fix is-renderable check in intel_image_target_renderbuffer_storage Previously we could create a renderbuffer with format MESA_FORMAT_R8G8B8A8_UNORM, convert that renderbuffer to an EGLImage, then FAIL to convert the EGLImage back to a renderbuffer because reasons. Just use the same check in intel_image_target_renderbuffer_storage that brw_render_target_supported uses. There are more checks in brw_render_target_supported, but I don't think they are necessary here. A different approach would be to refactor brw_render_target_supported to take rb->Format and rb->NumSamples as parameters (instead of a gl_renderbuffer) and use the new function here. Fixes: ES2-CTS.gtf.GL2ExtensionTests.egl_image.egl_image Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com> Tested-by: Tapani Pälli <tapani.palli@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92476 Cc: "10.3 10.4 10.5 10.6 11.0" <mesa-stable@lists.freedesktop.org>
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.