[Bug 107117] mesa-18.1: regression with TFP on intel

[bugzilla-daemon at freedesktop.org]

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

            Bug ID: 107117
           Summary: mesa-18.1: regression with TFP on intel
           Product: Mesa
           Version: git
          Hardware: Other
                OS: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Drivers/DRI/i965
          Assignee: intel-3d-bugs at lists.freedesktop.org
          Reporter: fourdan at xfce.org
        QA Contact: intel-3d-bugs at lists.freedesktop.org

Created attachment 140469
  --> https://bugs.freedesktop.org/attachment.cgi?id=140469&action=edit
Simple reproducer

Description:

Received a report downstream (xfce) that GL backend of the compositor would
produce a blank screen after upgrading mesa to 18.1 (works with 18.0).

I am by no mean a GL expert, so it might be an issue with my code, a simple
reproducer is attached.

How reproducible:

Always

Steps to reproduce:

1. Build and run the attached reproducer
   $ gcc -g tfp-test.c -o tfp-test $(pkg-config --cflags --libs epoxy xrender
xfixes xcomposite x11)
   $ ./tfp-test

Actual result:

A blank window.

Expected result:

A window with a red square.

Additional information:

 * Using texture type GL_TEXTURE_RECTANGLE_ARB
 * Using texture target GLX_TEXTURE_RECTANGLE_EXT
 * Using texture format GLX_TEXTURE_FORMAT_RGBA_EXT
 * And renderer is “Mesa DRI Intel(R) Haswell Mobile ”

I ran a “git bisect” but half of the steps would end with an assertion failed
in mesa so I am not entirely sure the bisection is accurate (I marked the
segfault as bad commit as well, lacking a actual result to see).

The assertion failed is:

intel_mipmap_tree.c:1301: intel_miptree_match_image: Assertion
`image->TexObject->Target == mt->target' failed.

Eventually, “git bisect” gave:

00926a2730190500a6a854659b193b022b92db2b is the first bad commit
commit 00926a2730190500a6a854659b193b022b92db2b
Author: Jason Ekstrand <jason.ekstrand at intel.com>
Date:   Tue Sep 12 14:26:04 2017 -0700

    i965/tex_image: Reference the renderbuffer miptree in setTexBuffer2

    The old code made a new miptree that referenced the same BO as the
    renderbuffer and just trusted in the memory aliasing to work.  There are
    only two ways in which the new miptree is liable to differ from the one
    in the renderbuffer and neither of them matter:

     1) It may have a different target.  The only targets that we can ever
        see in intelSetTexBuffer2 are GL_TEXTURE_2D and GL_TEXTURE_RECTANGLE
        and the difference between the two doesn't matter as far as the
        miptree is concerned; genX(update_sampler_state) only looks at the
        gl_texture_object and not the miptree when determining whether or
        not to use normalized coordinates.

     2) It may have a very slightly different format.  Again, this doesn't
        matter because we've supported texture views for quite some time so
        we always look at the gl_texture_object format instead of the
        miptree format for hardware setup anyway.

    On the other hand, because we were recreating the miptree, we were using
    intel_miptree_create_for_bo which doesn't understand modifiers.  We
    really want this function to work without doing a resolve so long as you
    have modifiers so we need to fix that.

    Reviewed-by: Kenneth Graunke <kenneth at whitecape.org>
    Reviewed-by: Chad Versace <chadversary at chromium.org>

:040000 040000 ed8106be921e3dcba1f784d4bb28b8983a23ebeb
d095e5ec1ce035cae4770fc2a8d8b06433cfb1d7 M      src

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