[Bug 104570] [BISECTED,REGRESSION] Failing copy_image tests on Android dEQP

[bugzilla-daemon at freedesktop.org]

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

            Bug ID: 104570
           Summary: [BISECTED,REGRESSION] Failing copy_image tests on
                    Android dEQP
           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: lemody at gmail.com
        QA Contact: intel-3d-bugs at lists.freedesktop.org

Many dEQP-GLES31.functional.copy_image.* tests failing, will attach a list of
failing tests.

Bisected to following commit:
---- 8< ----
commit fb0e9b5197cb65bde1e116d89acd5deb32f9132c
Author: Jason Ekstrand <jason.ekstrand at intel.com>
Date:   Fri Nov 3 16:11:54 2017 -0700

    i965: Track the depth and render caches separately

    Previously, we just had one hash set for tracking depth and render
    caches called brw_context::render_cache.  This is less than ideal
    because the depth and render caches are separate and we can't track
    moves between the depth and the render caches.  This limitation led
    to some unnecessary flushing around the depth cache.  There are cases
    (mostly with BLORP) where we can end up touching a depth or stencil
    buffer through the render cache.  To guard against this, blorp would
    unconditionally do a render_cache_set_check_flush on it's destination
    which meant that if you did any rendering (including a BLORP operation)
    to a given surface and then used it as a blorp destination, you would
    end up flushing it out of the render cache before rendering into it.

    Things get worse when you dig into the depth/stencil state code for
    regular GL draw calls.  Because we may end up rendering to a depth
    or stencil buffer via BLORP, we did a render_cache_set_check_flush on
    all depth and stencil buffers in brw_emit_depthbuffer to ensure that
    they got flushed out of the render cache prior to using them for depth
    or stencil testing.  However, because we also need to track dirtiness
    for depth and stencil so that we can implement depth and stencil
    texturing correctly, we were adding all depth and stencil buffers to the
    render cache set in brw_postdraw_set_buffers_need_resolve.  This meant
    that, if anything caused 3DSTATE_DEPTH_BUFFER to get re-emitted
    (currently _NEW_BUFFERS, BRW_NEW_BATCH, and BRW_NEW_BLORP), we would
    almost always do a full pipeline stall and render/depth cache flush.

    The root cause of both of these problems is that we can't tell the
    difference between the render and depth caches in our tracking.  This
    commit splits our cache tracking into two sets, one for render and one
    for depth, and properly handles transitioning between the two.  We still
    flush all the caches whenever anything needs to be flushed.  The idea is
    that if we're going to take the hit of a flush and stall, we may as well
    flush everything in the hopes that we can avoid a flush by something
    else later.

    Reviewed-by: Kenneth Graunke <kenneth at whitecape.org>

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