Otherwise, we'll try to clear it the first time it's used as a draw so if
you do some multisampled rendering, resolve to an attachment, and then draw
on top of the single-sampled attachment, we might accidentally clear it.
Signed-off-by: Jason Ekstrand <ja...@jlekstrand.net>
Cc: "13.0" <mesa-sta...@lists.freedesktop.org>
---
src/intel/vulkan/anv_blorp.c | 22 +++++++++++++---------
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
index 9ea6e3f..0e70e9b 100644
--- a/src/intel/vulkan/anv_blorp.c
+++ b/src/intel/vulkan/anv_blorp.c
@@ -1185,15 +1185,6 @@ anv_cmd_buffer_resolve_subpass(struct anv_cmd_buffer
*cmd_buffer)
struct anv_framebuffer *fb = cmd_buffer->state.framebuffer;
struct anv_subpass *subpass = cmd_buffer->state.subpass;
- /* FINISHME(perf): Skip clears for resolve attachments.
- *
- * From the Vulkan 1.0 spec:
- *
- * If the first use of an attachment in a render pass is as a resolve
- * attachment, then the loadOp is effectively ignored as the resolve is
- * guaranteed to overwrite all pixels in the render area.
- */
-
if (!subpass->has_resolve)
return;
@@ -1207,6 +1198,19 @@ anv_cmd_buffer_resolve_subpass(struct anv_cmd_buffer
*cmd_buffer)
if (dst_att == VK_ATTACHMENT_UNUSED)
continue;
+ if (cmd_buffer->state.attachments[dst_att].pending_clear_aspects) {
+ /* FINISHME(perf): Skip clears for resolve attachments.
+ *
+ * From the Vulkan 1.0 spec:
+ *
+ * If the first use of an attachment in a render pass is as a
+ * resolve attachment, then the loadOp is effectively ignored
+ * as the resolve is guaranteed to overwrite all pixels in the
+ * render area.
+ */
+ cmd_buffer->state.attachments[dst_att].pending_clear_aspects = 0;
+ }
+
struct anv_image_view *src_iview = fb->attachments[src_att];
struct anv_image_view *dst_iview = fb->attachments[dst_att];
--
2.5.0.400.gff86faf
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
