spec_glsl-1.30_execution_tex-miplevel-selection_textureGrad_Cube
spec_glsl-1.30_execution_tex-miplevel-selection_textureGrad_CubeArray
spec_glsl-1.30_execution_tex-miplevel-selection_textureGrad_CubeShadow
above 3 cases fail on SNB+ platforms.

I have run the test on an IvyBridge laptop against Mesa 10.1.3 (Ubuntu's version) and Mesa 9.2.5 (tagged from the repo). In both cases the issue was reproduced.

Created attachment 107052 [details]
Expected output of the test (from NVIDIA proprietary driver)

Created attachment 107053 [details]
SNB output

Created attachment 107054 [details]
SNB output disabling meta fast clear color path

Created attachment 107055 [details]
INTEL_DEBUG=fs output

I spent some time looking into this issue and I have some discoveries to share:

* This issue is reproducible in Ironlake with master branch (66a2fe4cf95f6d4f5bdbfd740314113e87e5649b).

* I first though that the issue could be related something specific to cube map textures but test "bin/tex-miplevel-selection *Lod Cube" passes. So, I compared the INTEL_DEBUG=fs of the latter program with the reported in the bug, they are almost the same: the difference is in the number of parameters sent to the sampler and the uniforms received in the payload. I also read the SNB documentation to check that INTEL_DEBUG=fs is giving the expected output for both cases.

* Then I was suspicious of a misconfigured state message (3DSTATE_WM, 3DSTATE_CONSTANT_PS, SURFACE_STATE, sampling engine messages). After comparing its setup in the source code with SNB documentation, I have not found any misconfigured flag but I could be wrong as it might be something very subtle to be seen at first glance.

* In gen6_update_renderbuffer_surface(), when the gl_target is a cube map texture, the surface type is changed to SURFACE_2D with its depth multiply by 6 (as the cube map has six faces). I modified it but no change in the output. Furthermore, as it is working for other cases (see test in second bullet), I don't think this is related to this bug.

* As this tests renders into each texture by using only glClear() commands, then I looked at the meta fast color clear path. I found that commenting out the meta fast color clear path in brw_clear(), then some color patterns appeared in the output... but they are still wrong (see attachments).

So, I'm running out of ideas to continue analyzing this bug. Maybe someone with more experience in that part of the source code has some ideas that could be worth to try or point out where I made a mistake in my analysis.

I sent a patch for review to the mailing list that fixes this as well as a bunch of similar dEQP tests:
http://lists.freedesktop.org/archives/mesa-dev/2015-February/077733.html

(In reply to Iago Toral from comment #8)
> I sent a patch for review to the mailing list that fixes this as well as a
> bunch of similar dEQP tests:
> http://lists.freedesktop.org/archives/mesa-dev/2015-February/077733.html

Apply this patch, It works well.
output:
libGL: OpenDriver: trying /opt/X11R7/lib/dri/tls/i965_dri.so
libGL: OpenDriver: trying /opt/X11R7/lib/dri/i965_dri.so
Summary: 58212/58212 passed
PIGLIT: {"result": "pass" }

Based on Ironlake, my reports from running this piglit test:

Master Mesa (afeb92220690c8f27cdc56c30e109ca175d51d83)
======================================================
PASS

Mesa 10.5.2
======================================================
Failure:
  Expected level: 0
  Observed: wrong layer/face/slice or wrong level or wrong offset
  Fetch level: 0, baselevel: 0, maxlevel: 0, minlod: 0, maxlod: 0, bias: -5, mipfilter: no
Failure:
  Expected level: 0
  Observed: wrong layer/face/slice or wrong level or wrong offset
  Fetch level: 0, baselevel: 0, maxlevel: 0, minlod: 0, maxlod: 0, bias: -5, mipfilter: yes
...

Looks to be resolved, at least on this hw.

(In reply to Rhys Kidd from comment #10)
> Based on Ironlake, my reports from running this piglit test:
> 
> Master Mesa (afeb92220690c8f27cdc56c30e109ca175d51d83)
> ======================================================
> PASS
> 
> Mesa 10.5.2
> ======================================================
> Failure:
>   Expected level: 0
>   Observed: wrong layer/face/slice or wrong level or wrong offset
>   Fetch level: 0, baselevel: 0, maxlevel: 0, minlod: 0, maxlod: 0, bias: -5,
> mipfilter: no
> Failure:
>   Expected level: 0
>   Observed: wrong layer/face/slice or wrong level or wrong offset
>   Fetch level: 0, baselevel: 0, maxlevel: 0, minlod: 0, maxlod: 0, bias: -5,
> mipfilter: yes
> ...
> 
> Looks to be resolved, at least on this hw.

That is odd, the tests require GL version 3 and Ironlake only supports 2.1. I have in fact tried to run the test in an Ironlake laptop and the test is skipped warning that it does not support the required GL version. That is with Mesa master (ea633db65f) and piglit's master.

(In reply to lu hua from comment #9)
> (In reply to Iago Toral from comment #8)
> > I sent a patch for review to the mailing list that fixes this as well as a
> > bunch of similar dEQP tests:
> > http://lists.freedesktop.org/archives/mesa-dev/2015-February/077733.html
> 
> Apply this patch, It works well.
> output:
> libGL: OpenDriver: trying /opt/X11R7/lib/dri/tls/i965_dri.so
> libGL: OpenDriver: trying /opt/X11R7/lib/dri/i965_dri.so
> Summary: 58212/58212 passed
> PIGLIT: {"result": "pass" }

By the way, this patch was merged in master a few weeks ago.

All platforms but G965 were fixed by

commit 2b1cdb0eddb73f62e4848d4b64840067f1f70865
Author: Iago Toral Quiroga <itoral@igalia.com>
Date:   Tue Feb 24 19:02:50 2015 +0100

    i965: Fix textureGrad with cube samplers

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1452.