<div style="font-family:'Segoe UI',Arial,Sans-Serif;font-size:10pt;">

    <h1 style="font-size: 150%;font-weight:normal; color:#078DC7;"><a href="https://ci.appveyor.com/project/mesa3d/mesa/build/6145" style="color:#078DC7;">Build mesa 6145 completed</a></h1>


    <p style="color: #888;">
        Commit <a href="">fb0e9b5197</a> by <a href="mailto:jason.ekstrand@intel.com">Jason Ekstrand</a> on 11/3/2017 11:11 PM:
        <br />
        <span style="font-size: 110%;color:#222;">i965: Track the depth and render caches separately\n\nPreviously, we just had one hash set for tracking depth and render\ncaches called brw_context::render_cache.  This is less than ideal\nbecause the depth and render caches are separate and we can't track\nmoves between the depth and the render caches.  This limitation led\nto some unnecessary flushing around the depth cache.  There are cases\n(mostly with BLORP) where we can end up touching a depth or stencil\nbuffer through the render cache.  To guard against this, blorp would\nunconditionally do a render_cache_set_check_flush on it's destination\nwhich meant that if you did any rendering (including a BLORP operation)\nto a given surface and then used it as a blorp destination, you would\nend up flushing it out of the render cache before rendering into it.\n\nThings get worse when you dig into the depth/stencil state code for\nregular GL draw calls.  Because we may end up rendering to a depth\nor stencil buffer via BLORP, we did a render_cache_set_check_flush on\nall depth and stencil buffers in brw_emit_depthbuffer to ensure that\nthey got flushed out of the render cache prior to using them for depth\nor stencil testing.  However, because we also need to track dirtiness\nfor depth and stencil so that we can implement depth and stencil\ntexturing correctly, we were adding all depth and stencil buffers to the\nrender cache set in brw_postdraw_set_buffers_need_resolve.  This meant\nthat, if anything caused 3DSTATE_DEPTH_BUFFER to get re-emitted\n(currently _NEW_BUFFERS, BRW_NEW_BATCH, and BRW_NEW_BLORP), we would\nalmost always do a full pipeline stall and render/depth cache flush.\n\nThe root cause of both of these problems is that we can't tell the\ndifference between the render and depth caches in our tracking.  This\ncommit splits our cache tracking into two sets, one for render and one\nfor depth, and properly handles transitioning between the two.  We still\nflush all the caches whenever anything needs to be flushed.  The idea is\nthat if we're going to take the hit of a flush and stall, we may as well\nflush everything in the hopes that we can avoid a flush by something\nelse later.\n\nReviewed-by: Kenneth Graunke <kenneth@whitecape.org></span>
    </p>

    <p><a href="https://ci.appveyor.com/notifications" style="font-size:85%;color:#999;">Configure your notification preferences</a></p>
</div>