Only on haswell, this category of tests fails with:
Image comparison failed:
allowed position deviation = (2, 2, 0)
color threshold = (8, 8, 8, 0)
Correction. These tests are flaky on HSW. I've disabled them in the CI until this bug is addressed.
These tests may have been failing on haswell because those machines were updated to Linux 4.7.
After updating a skylake machine to linux 4.7, I see similar failures.
Tapani, can you confirm?
these tests are skipped on my SKL machine:
"NotSupported (EGL_EXT_buffer_age is not supported at teglBufferAgeTests.cpp:401)
and fail constantly on HSW machine:
"Fail (Fail, buffer content is not well preserved when age > 0)"
dEQP version on both machines matches:
and Mesa as well:
kernel on SKL is drm-nightly 4.8.0+, HSW has 4.7.9-200.fc24.x86_64. Then on top of this I have a feeling that this test will behave differently on DRI2 vs DRI3 because of the preserved bit support ...
I'll have to figure out first what is the requirement for EGL_EXT_buffer_age support to be there.
It looks like tests always verify the content no matter if preseved bit is set, I've sent a patch to Google and will be waiting for their feedback.
Please attach the patch here, and I'll use it in my testing.
Created attachment 128391 [details] [review]
Patches changes test to verify buffer pixels only when preserved bit is set.
From the dEQP test engineers:
From: Mika Isojarvi <email@example.com>
Subject: Re: dEQP-EGL.functional.buffer_age.no_preserve bug
To: Mark Janes <firstname.lastname@example.org>
Cc: deqp-external-requests <email@example.com>
Date: Fri, 09 Dec 2016 13:52:15 -0800
[ multipart/alternative ]
[ text/plain ]
The preserve bit is not relevant for the EGL buffer age extensions. Setting
the preserve bit means that the color buffer must be preserved over the
eglSwapBuffers() call. So the color buffer content at the end of the frame
and at the beginning of the next frame must be exactly same. The EGL buffer
age extension allows querying the age of the color buffers contents at the
beginning of the frame e.g. if the driver returns 2 then the color buffers
contents must match the content two frames ago(or it can return 0 if the
color buffer contents don't match any previous frame). This guarantee does
not require that the color buffer preserved bit is set.
The test case is using preserve bit to check that if the preserve bit is
set then buffer age is always 1. Meaning that the color buffer contents are
the same as at the end of the previous frame.
Right, now I remember how this is supposed to work. So Mesa is quite likely just simply setting wrong age then, will continue investigation.
Updating some status here since I've been debugging this for quite a long time now ... :/
Mesa returns buffer age of 0 for the fresh buffers correctly and after this the age is always 2 (double buffering) in my system (using dri3). I implemented alternative age calculation for dri3 buffers but it comes to the same result of 2 which I believe is correct. Right now I'm trying to understand the failure from test POV which is comparing the reference renderer images to the gles2 renderer. I'm using test "odd_clear_render_even_none" which is the 'simple case'.
I've noticed at least one thing that is causing issues with tests that use the type 'none' as one method. In those tests there are frames when nothing happens between 2 swapbuffer commmands, in these cases it looks like the backbuffer contents do not change (swap does not happen?). I will attach 2 images from apitrace where first one is regular one of the test and in 2nd one I'm making a empty clear (with scissor 0,0,0,0) in case nothing happens in that frame.
Created attachment 128709 [details]
apitrace snapshot for "odd_clear_render_even_none"
Created attachment 128710 [details]
apitrace snapshot for "odd_clear_render_even_none" with dummy clear
Created attachment 128769 [details] [review]
Here's a hack patch to dEQP that makes all of these tests pass. I think I understand why bad stuff happens, however I'm not sure how to make things work correctly yet.
Created attachment 128770 [details] [review]
patch sent to mesa-dev, this fixes all failures for me and no regressions seen in CI
Author: Tapani Pälli <firstname.lastname@example.org>
Date: Thu Jan 5 13:40:35 2017 +0200
i965: call intel_prepare_render always when reading pixels
Currently we do this only in the fallback code (when tiled memcpy
version failed) but it needs to be done always so that we have
correct read and write buffer in place. No regressions seen in CI.
Signed-off-by: Tapani Pälli <email@example.com>
Reviewed-by: Kenneth Graunke <firstname.lastname@example.org>
Reviewed-by: Chad Versace <email@example.com>