Created attachment 119051 [details]
Terminal Output

This tests also fails on HSW-U with the following configuration :


==Test Environment==
--------------------------------------------------
xorg-server-1.17.2
libdrm-2.4.65
xf86-video-intel-2.99.917
mesa-11.1.0-devel (git 6f39546)
libva-1.6.1
intel-driver-1.6.1
cairo-1.14.2


kernel: 4.3.0-rc5-drm-intel-nightly+
commit ce4630de6e6ba63c0477e753510f6294fac9d30c
Author: Matt Roper <matthew.d.roper@intel.com>
Date:   Wed Oct 21 15:05:45 2015 -0700

The following tests keeps fail on BDW-U with the next configuration :

Case list : 
deqp-gles2@functional@texture@vertex@cube@filtering@linear_mipmap_linear_linear_clamp
deqp-gles2@functional@texture@vertex@cube@filtering@linear_mipmap_linear_linear_mirror
deqp-gles2@functional@texture@vertex@cube@filtering@linear_mipmap_linear_nearest_mirror


kernel drm-intel-testing:

commit 91587c722c28c4116dedbfbf08aa874377bc76f8
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Dec 4 17:35:54 2015 +0100

    drm-intel-nightly: 2015y-12m-04d-16h-35m-07s UTC integration manifest


kernel version : 4.4.0-rc3
git url        : git://anongit.freedesktop.org/drm-intel
git branch     : drm-intel-testing
git describe   : drm-intel-next-2015-11-20-rebased-13721-g91587c7

kernel drm-intel-nightly

commit 79686f613b3955a4ed09cee936e7f70ec4e61b67
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Wed Dec 30 14:00:24 2015 +0200

    drm-intel-nightly: 2015y-12m-30d-11h-59m-54s UTC integration manifest


kernel version : 4.4.0-rc6
git url        : git://anongit.freedesktop.org/drm-intel
git branch     : drm-intel-nightly
git describe   : drm-intel-next-2015-12-18-1500-g79686f6

cairo version: 1.15.2 / commit :  db8a7f1 
drm version :  libdrm-2.4.66  / commit : b38a4b2 
intel-driver : 1.6.2 / commit: 683edee
libva version : libva-1.6.2 / commit : 304bc13
mesa version : mesa-11.0.8 / commit : 261daab 
xf86-video-intel version : 2.99.917  / commit : baec802 
xserver version :xorg-server-1.18.0 / commit :7921764

Hi mark.a.janes@intel.com :

Could you tell us which info you need for this bug since i saw that you change the status of this bug to NEEDINFO.

Thanks

I don't have that test case in my deqp runs.  Can you provide the commit you are using for the dEQP test suite?

Dear Reporter,

This Mesa bug has been in the "NEEDINFO" status for over 60 days. I am closing this bug based on lack of response but feel free to reopen if resolution is still needed. Please ensure you're supplying the correct information as requested.

Thank you.

Reopen this bug, since these cases also fails on BXT platform
The following test cases are failing:

deqp-gles2@functional@texture@vertex@cube@filtering@linear_mipmap_linear_linear_clamp		
deqp-gles2@functional@texture@vertex@cube@filtering@linear_mipmap_linear_linear_mirror
deqp-gles2@functional@texture@vertex@cube@filtering@linear_mipmap_linear_nearest_
deqp-gles2@functional@texture@vertex@cube@filtering@linear_mipmap_linear_nearest_mirror

Configuration: 
Apollo Lake NUC
Platform: BOXNUC6CAYH
Processor: Intel Celeron J3455 CPU, quad-core, 1.5 GHz (2.3 GHz burst)
GPU: Intel HD Graphics 500
Software
Linux distribution: 16.04.4 LTS (GNU/Linux 4.13.0-36-generic x86_64)
mesa: master git 1fdb215 commit
Libdrm - 2.4.83 from http://cgit.freedesktop.org/mesa/drm/

more information
These tests are in android dEQP CTS failurelist /cts/master/src/gles2-failures.txt
but they are not tracked as Google internal testcase bugs or hardware issues.
Not sure if it is mesa bug or not.

Created attachment 138053 [details]
failure test report

add the test failure report

I suspect this is an issue with the test.  GLES 3.0 enabled seamless cube map filtering by default, while GLES 2.0 didn't.  But since GLES 2.0 can be legally and silently promoted to 3.0, it's basically undefined whether it's enabled.  There are comments in some of the tests that they try and avoid corner/edge pixels that would hit this undefined behavior, but...the failures are all a single pixel at the very corner.

Notably, these two tests begin to pass if we disable seamless cubemap filtering (which we can't reasonably do):

dEQP-GLES2.functional.texture.vertex.cube.filtering.linear_mipmap_linear_nearest_clamp
dEQP-GLES2.functional.texture.vertex.cube.filtering.linear_mipmap_linear_nearest_mirror

These two continue failing:

dEQP-GLES2.functional.texture.vertex.cube.filtering.linear_mipmap_linear_nearest_repeat
dEQP-GLES2.functional.texture.vertex.cube.filtering.linear_mipmap_linear_linear_repeat

Notably, i965 passes the dEQP-GLES3 versions of the same tests.  I'm not aware of us doing something different for GLES2 and GLES3, so my guess is some bug fix to the tests didn't get copy and pasted back to the older GLES2 test.

More importantly, these are not in the Android CTS mustpass list, which means Google doesn't require them.  If Google doesn't think it's reasonable to require graphics vendors to pass these tests, and neither does Khronos, I'm inclined to agree and not spend any effort fixing them.  I think you should change how you're running the test suite to only run tests in the mustpass list.