The following tests began failing with mesa cda886a4851ab767fba40e8474d6fa8190347e4f: deqp-gles2.functional.texture.completeness.2d.format_mismatch_rgb_rgba deqp-gles2.functional.texture.completeness.cube.format_mismatch_rgba_rgb_level_0_neg_z deqp-gles2.functional.texture.completeness.cube.format_mismatch_rgba_rgb_level_0 deqp-gles2.functional.texture.completeness.cube.format_mismatch_rgb_rgba_level_0_pos_z deqp-gles2.functional.texture.completeness.cube.format_mismatch_rgb_rgba_level_0 deqp-gles2.functional.texture.completeness.2d.format_mismatch_rgba_rgb Sample output: /tmp/build_root/m64/opt/deqp/modules/gles2/deqp-gles2 --deqp-case=dEQP-GLES2.functional.texture.completeness.cube.format_mismatch_rgb_rgba_level_0 --deqp-surface-type=fbo --deqp-log-images=disable --deqp-surface-width=256 --deqp-surface-height=256 dEQP Core 2014.x (0xcafebabe) starting.. target implementation = 'DRM' Test case 'dEQP-GLES2.functional.texture.completeness.cube.format_mismatch_rgb_rgba_level_0'.. Test case duration in microseconds = 16674 us Fail (Image comparison failed) DONE! Test run totals: Passed: 0/1 (0.0%) Failed: 1/1 (100.0%) Not supported: 0/1 (0.0%) Warnings: 0/1 (0.0%) Of the 6 tests, two were previously asserting, and do not constitute a regression: deqp-gles2.functional.texture.completeness.cube.format_mismatch_rgba_rgb_level_0_neg_z deqp-gles2.functional.texture.completeness.cube.format_mismatch_rgb_rgba_level_0_pos_z The bisected patch: Author: Neil Roberts <neil@linux.intel.com> AuthorDate: Thu Nov 19 16:25:21 2015 +0100 Commit: Neil Roberts <neil@linux.intel.com> CommitDate: Wed Jan 13 12:16:31 2016 +0000 i965/gen9: Don't allow the RGBX formats for texturing/rendering The RGBX surface formats aren't renderable so we internally remap them to RGBA when rendering. They are retained as RGBX when used as textures. However since the previous patch fast clears are disabled for surfaces that use a different format for rendering than for texturing. To avoid this situation we can just pretend not to support RGBX formats at all. This will cause the upper layers of mesa to pick an RGBA format internally instead. This should be safe because we always override the alpha component to 1.0 for RGBX in the texture swizzle anyway. We could also do this for all gens except that it's a bit more difficult when the hardware doesn't support texture swizzling. Gens using the blorp have further problems because that doesn't implement this swizzle override. Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
I've posted a patch for this here: http://patchwork.freedesktop.org/patch/70430/ It fixes the tests mentioned above (apart from the 2 known failures) and passes a Jenkins run, but I wasn't able to run a full dEQP comparison. Mark, are these tests only run on some special configuration of Jenkins?
Unfortunately, we haven't had sufficient hardware to enable dEQP on skl for developer branches. That should change in the next few days. I'll add it to the configuration now so it can be easily tested.
Thanks for running the tests again. I've pushed the patch to master. http://cgit.freedesktop.org/mesa/mesa/commit/?id=06b526de0565d5485a2111e3
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.