Without this stall, the test group ES3-CTS.functional.fbo.msaa.\* hangs
about 1 out of every 2 or 3 times on my Sky Lake GT3 laptop. With the
flush and stall, I can run it 6 times in a row without a hang.
Cc: "17.1" <mesa-sta...@lists.freedesktop.org>
---
src/mesa/drivers/dri/i965/brw_blorp.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c
b/src/mesa/drivers/dri/i965/brw_blorp.c
index 763ce05..38925d9 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.c
+++ b/src/mesa/drivers/dri/i965/brw_blorp.c
@@ -1021,6 +1021,23 @@ intel_hiz_exec(struct brw_context *brw, struct
intel_mipmap_tree *mt,
{
const char *opname = NULL;
+ /* From the Ivy Bridge PRM, Vol. 2, pt. 1, section 11.5.3.1 "Depth
+ * Buffer Clear":
+ *
+ * "If other rendering operations have preceded this clear, a
+ * PIPE_CONTROL with depth cache flush enabled, Depth Stall bit enabled
+ * must be issued before the rectangle primitive used for the depth
+ * buffer clear operation."
+ *
+ * In the Sky Lake and Broadwell docs, this text only appears in the
+ * section on legacy HiZ ops. However, adding it seems to solve some hangs
+ * on Sky Lake so it appears it's needed regardless of which kind of HiZ
+ * operation is performed.
+ */
+ brw_emit_pipe_control_flush(brw,
+ PIPE_CONTROL_DEPTH_CACHE_FLUSH |
+ PIPE_CONTROL_DEPTH_STALL);
+
switch (op) {
case BLORP_HIZ_OP_DEPTH_RESOLVE:
opname = "depth resolve";
--
2.5.0.400.gff86faf
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
