Mesa (staging/20.3): radv: add missing DB flush after depth/stencil resolve operations

[GitLab Mirror]

Module: Mesa
Branch: staging/20.3
Commit: abfbaa8476fe3fdec1250315e97b402355795668
URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=abfbaa8476fe3fdec1250315e97b402355795668

Author: Samuel Pitoiset <samuel.pitoiset at gmail.com>
Date:   Thu Dec 17 12:01:40 2020 +0100

radv: add missing DB flush after depth/stencil resolve operations

I thought this was a bug in CTS but the Vulkan spec says:

    "VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT specifies write access
     to a color, resolve, or depth/stencil resolve attachment during
     a render pass or via certain subpass load and store operations."

So, VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT is used to synchronize
depth/stencil resolve attachments. Yes, it's counterintuitive.

This can't actually be fixed properly for now because RADV performs
the end subpass barrier *before* resolve attachments instead of after.

Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset at gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas at basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8138>
(cherry picked from commit 7880faccc51b68391390071c872f5fea45e41fee)

---

 .pick_status.json                  |  2 +-
 src/amd/vulkan/radv_meta_resolve.c | 20 ++++++++++++++++++++
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/.pick_status.json b/.pick_status.json
index 7f885dcfd33..b5b09c655fe 100644
--- a/.pick_status.json
+++ b/.pick_status.json
@@ -121,7 +121,7 @@
         "description": "radv: add missing DB flush after depth/stencil resolve operations",
         "nominated": true,
         "nomination_type": 0,
-        "resolution": 0,
+        "resolution": 1,
         "master_sha": null,
         "because_sha": null
     },
diff --git a/src/amd/vulkan/radv_meta_resolve.c b/src/amd/vulkan/radv_meta_resolve.c
index 809522bb49a..9e4219458a5 100644
--- a/src/amd/vulkan/radv_meta_resolve.c
+++ b/src/amd/vulkan/radv_meta_resolve.c
@@ -790,6 +790,26 @@ radv_cmd_buffer_resolve_subpass(struct radv_cmd_buffer *cmd_buffer)
 								      subpass->stencil_resolve_mode);
 			}
 		}
+
+		/* From the Vulkan spec 1.2.165:
+		 *
+		 * "VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT specifies
+		 *  write access to a color, resolve, or depth/stencil
+		 *  resolve attachment during a render pass or via
+		 *  certain subpass load and store operations."
+		 *
+		 * Yes, it's counterintuitive but it makes sense because ds
+		 * resolve operations happen late at the end of the subpass.
+		 *
+		 * That said, RADV is wrong because it executes the subpass
+		 * end barrier *before* any subpass resolves instead of after.
+		 *
+		 * TODO: Fix this properly by executing subpass end barriers
+		 * after subpass resolves.
+		 */
+		cmd_buffer->state.flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_DB;
+		if (radv_image_has_htile(dst_iview->image))
+			cmd_buffer->state.flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_DB_META;
 	}
 
 	if (!subpass->has_color_resolve)