The following tests began failing with mesa cda886a4851ab767fba40e8474d6fa8190347e4f:
/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)
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:
The bisected patch:
Author: Neil Roberts <firstname.lastname@example.org>
AuthorDate: Thu Nov 19 16:25:21 2015 +0100
Commit: Neil Roberts <email@example.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 <firstname.lastname@example.org>
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.