Bug 104570 - [BISECTED,REGRESSION] Failing copy_image tests on Android dEQP
Summary: [BISECTED,REGRESSION] Failing copy_image tests on Android dEQP
Status: RESOLVED DUPLICATE of bug 103746
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Jason Ekstrand
QA Contact: Intel 3D Bugs Mailing List
Depends on:
Reported: 2018-01-10 08:05 UTC by Tapani Pälli
Modified: 2018-01-10 17:58 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

list of failing tests (67.80 KB, text/plain)
2018-01-10 08:06 UTC, Tapani Pälli
change that makes tests pass (580 bytes, patch)
2018-01-10 10:16 UTC, Tapani Pälli
Details | Splinter Review

Description Tapani Pälli 2018-01-10 08:05:58 UTC
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@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@whitecape.org>
Comment 1 Tapani Pälli 2018-01-10 08:06:22 UTC
Created attachment 136644 [details]
list of failing tests
Comment 2 Tapani Pälli 2018-01-10 08:56:09 UTC
When inspecting error masks from log (Result vs Reference), it seems mostly the image is correct but some difference as tiny bits of difference, usually in a corner of the image.
Comment 3 Tapani Pälli 2018-01-10 10:16:46 UTC
Created attachment 136646 [details] [review]
change that makes tests pass
Comment 4 Mark Janes 2018-01-10 17:20:06 UTC
Please track this in the original bug.

*** This bug has been marked as a duplicate of bug 103746 ***
Comment 5 Tapani Pälli 2018-01-10 17:58:28 UTC
(In reply to Mark Janes from comment #4)
> Please track this in the original bug.
> *** This bug has been marked as a duplicate of bug 103746 ***

Oops did not notice there was one! Thanks Mark!

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.