[Bug 91114] ES3-CTS.gtf.GL3Tests.shadow.shadow_execution_vert fails

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91114

            Bug ID: 91114
           Summary: ES3-CTS.gtf.GL3Tests.shadow.shadow_execution_vert
                    fails
           Product: Mesa
           Version: git
          Hardware: Other
                OS: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Drivers/DRI/i965
          Assignee: idr at freedesktop.org
          Reporter: lemody at gmail.com
        QA Contact: intel-3d-bugs at lists.freedesktop.org

bisected to:
--- 8< ---
2b1cdb0eddb73f62e4848d4b64840067f1f70865 is the first bad commit
commit 2b1cdb0eddb73f62e4848d4b64840067f1f70865
Author: Iago Toral Quiroga <itoral at igalia.com>
Date:   Tue Feb 24 19:02:50 2015 +0100

    i965: Fix textureGrad with cube samplers

    We can't use sampler messages with gradient information (like
    sample_g or sample_d) to deal with this scenario because according
    to the PRM:

    "The r coordinate and its gradients are required only for surface
    types that use the third coordinate. Usage of this message type on
    cube surfaces assumes that the u, v, and gradients have already been
    transformed onto the appropriate face, but still in [-1,+1] range.
    The r coordinate contains the faceid, and the r gradients are ignored
    by hardware."

    Instead, we should lower this to compute the LOD manually based on the
    gradients and use a different sample message that takes the computed
    LOD instead of the gradients. This is already being done in
    brw_lower_texture_gradients.cpp, but it is restricted to shadow
    samplers only, although there is a comment stating that we should
    probably do this also for samplerCube and samplerCubeArray.

    Because of this, both dEQP and Piglit test cases for textureGrad with
    cube maps currently fail.

    This patch does two things:
    1) Activates the texturegrad lowering pass for all cube samplers.
    2) Corrects the computation of the LOD value for cube samplers.

    I had to do 2) because for cube maps the calculations implemented
    in the lowering pass always compute a value of rho that is twice
    the value we want (so we get a LOD value one unit larger than we
    want). This only happens for cube map samplers (all kinds). I am
    not sure about why we need to do this, but I suspect that it is
    related to the fact that cube map coordinates, when transported
    to a specific face in the cube, are in the range [-1, 1] instead of
    [0, 1] so we probably need to divide the derivatives by 2 when
    we compute the LOD. Doing that would produce the same result as
    dividing the final rho computation by 2 (or removing a unit
    from the computed LOD, which is what we are doing here).

    Fixes the following piglit tests:
    bin/tex-miplevel-selection textureGrad Cube -auto -fbo
    bin/tex-miplevel-selection textureGrad CubeArray -auto -fbo
    bin/tex-miplevel-selection textureGrad CubeShadow -auto -fbo

    Fixes 10 dEQP tests in the following category:
    dEQP-GLES3.functional.shaders.texture_functions.texturegrad.*cube*

    Reviewed-by: Ben Widawsky <ben at bwidawsk.net>

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20150626/cc695574/attachment.html>