New issue
Advanced search Search tips

Issue 712299 link

Starred by 1 user

Issue metadata

Status: Archived
Owner:
Closed: Jun 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug



Sign in to add a comment

graphics_dEQP remove also the test before the not passing test

Project Member Reported by ihf@chromium.org, Apr 17 2017

Issue description

In graphics_dEQP we _load_not_passing_cases and avoid running them, as tests known to cause problems should be avoided. One problem with this is that sometimes tests cause problems to the next following test and make it fail. So instead of just removing the failing test we should also remove the test preceding it. Otherwise what happens is that we keep removing good tests that were caused to fail by the bad one, but never remove the actual failure cause.
 

Comment 1 by ihf@chromium.org, May 4 2017

Can you see how to implement this next? I think we will need it.

Comment 2 by pwang@chromium.org, May 8 2017

Is it possible for us to still run the failed cases in normal mode as a separate group alongside the passed tests in hasty mode? As this helps us the identify which failed cases is a false negative.

Comment 3 by ihf@chromium.org, May 9 2017

There are two use cases for running dEQP: bringup of new architectures and for checking regressions. I don't think bringup will be important anymore, so all we care for is effectively and reliably see if some change caused our tests to start failing. And for that it would be enough to run 99.99% of all tests to be very effective.

A different thought:
One thing that CTS does when running dEQP is it allows to rerun failing tests a few times. This takes care of some but not necessarily all failures. Maybe we should do that? I don't know yet.

Comment 4 by pwang@chromium.org, May 25 2017

For gles2-master
kevin, peach_*, veyron_* boards now are passing after the re-run patch 
https://wmatrix.googleplex.com/unfiltered?hide_missing=True&releases=tot&tests=graphics_dEQP.gles2-master&days_back=3
only nyan_*, daisy_* are failing for gles2 right now.

Comment 5 by pwang@chromium.org, Jun 23 2017

Status: Fixed (was: Untriaged)
Based on wmatrix for the past 100 days.

GLES2:
https://wmatrix.googleplex.com/unfiltered?hide_missing=True&releases=tot&tests=graphics_dEQP.gles2-master&days_back=100
                hasty      master
mail-t604:          3           3
tegra:              2           2

GLES3:
https://wmatrix.googleplex.com/unfiltered?hide_missing=True&releases=tot&tests=graphics_dEQP.gles3-master&days_back=100
                hasty      master
broadwell:      flaky       flaky
haswell:            6           6
mali-t604:   12+47=59          59
mali-t628:         12          12
mali-t760:         12          12
mali-t860:    1+12=13          13
rogue:              1           1
sandybridge:   2+8=10          10
tegra:  12+15+3+37=67          67


I think now the hasty file is as reliable as the master-list to detect the failure of the tests.

Comment 6 by dchan@chromium.org, Jan 22 2018

Status: Archived (was: Fixed)

Sign in to add a comment