summaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers/dri/i965/brw_context.h
diff options
context:
space:
mode:
authorJason Ekstrand <[email protected]>2017-11-03 16:11:54 -0700
committerJason Ekstrand <[email protected]>2017-11-13 21:51:59 -0800
commitfb0e9b5197cb65bde1e116d89acd5deb32f9132c (patch)
tree5587da4bf48642f3fc7e68f4a92b0053bfbcfa72 /src/mesa/drivers/dri/i965/brw_context.h
parentd6d0ac95d5d77bd18b2064c3ed9aad70cf38cb6f (diff)
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 <[email protected]>
Diffstat (limited to 'src/mesa/drivers/dri/i965/brw_context.h')
-rw-r--r--src/mesa/drivers/dri/i965/brw_context.h7
1 files changed, 7 insertions, 0 deletions
diff --git a/src/mesa/drivers/dri/i965/brw_context.h b/src/mesa/drivers/dri/i965/brw_context.h
index 8aa0c5ff64c..7457aba54a3 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -703,6 +703,13 @@ struct brw_context
struct set *render_cache;
/**
+ * Set of struct brw_bo * that have been used as a depth buffer within this
+ * batchbuffer and would need flushing before being used from another cache
+ * domain that isn't coherent with it (i.e. the sampler).
+ */
+ struct set *depth_cache;
+
+ /**
* Number of resets observed in the system at context creation.
*
* This is tracked in the context so that we can determine that another