zink: force texture barriers when performing in-renderpass clears

according to spec, a barrier is required any time the pixels of the
framebuffer are changed. since zink defers clears and runs them at
a later time, it must also be responsible for handling the required
synchronization for such operations

fixes (radv):
KHR-GL46.blend_equation_advanced.blend_all*

fixes #5572

Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15831>

src/gallium/drivers/zink/zink_clear.c

@@ -120,6 +120,19 @@ clear_in_rp(struct pipe_context *pctx,
    struct zink_batch *batch = &ctx->batch;
    zink_batch_rp(ctx);
    VKCTX(CmdClearAttachments)(batch->state->cmdbuf, num_attachments, attachments, 1, &cr);
+   /*
+       Rendering within a subpass containing a feedback loop creates a data race, except in the following
+       cases:
+       • If a memory dependency is inserted between when the attachment is written and when it is
+       subsequently read by later fragments. Pipeline barriers expressing a subpass self-dependency
+       are the only way to achieve this, and one must be inserted every time a fragment will read
+       values at a particular sample (x, y, layer, sample) coordinate, if those values have been written
+       since the most recent pipeline barrier
+
+       VK 1.3.211, Chapter 8: Render Pass
+    */
+   if (ctx->fbfetch_outputs)
+      ctx->base.texture_barrier(&ctx->base, PIPE_TEXTURE_BARRIER_FRAMEBUFFER);
 }
 
 static void