Vulkan: Don't flush deferred clears on READ framebuffer sync

Deferred clears are not collected when syncing the READ framebuffer. Prior to this change, we had in FramebufferVk::syncState: if (READ && deferredClears.any()) { flushDeferredClears(); } However, this is impossible / unnecessary: - Every operation whose syncState (for the DRAW framebuffer) collects deferred clears will flush the deferred clears. In fact, it's an error for the next operation's syncState to encounter pre-existing deferred clears. - The READ framebuffer is synced before the DRAW framebuffer. This makes it impossible for there to be deferred clears when READ is synced. It may be necessary to swap the order in which the READ and DRAW framebuffers are synced. See http://anglebug.com/5266. In that case, if the READ and DRAW framebuffers are identical: - The DRAW framebuffer's sync will collect deferred clears. The READ framebuffer's sync will see deferred clears, but it must not flush them! Bug: angleproject:4988 Change-Id: I179002d739608ccb8bda95d4379dc6d54e2bf4bb Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2511372 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org>

Vulkan: Don't flush deferred clears on READ framebuffer sync
3dfaeeb0 · Shahbaz Youssefi · Commit Bot · 6f755d21 · 3dfaeeb0
Commit 3dfaeeb0 authored Oct 30, 2020 by Shahbaz Youssefi Committed by Commit Bot Nov 06, 2020
Hide whitespace changes
Inline Side-by-side

Showing with 1 addition and 20 deletions

FramebufferVk.cpp src/libANGLE/renderer/vulkan/FramebufferVk.cpp +1 -20

No files found.
--- a/src/libANGLE/renderer/vulkan/FramebufferVk.cpp
+++ b/src/libANGLE/renderer/vulkan/FramebufferVk.cpp
@@ -1663,9 +1663,7 @@ angle::Result FramebufferVk::syncState(const gl::Context *context,
    // Only defer clears for draw framebuffer ops.  Note that this will result in a render area that
    // completely covers the framebuffer, even if the operation that follows is scissored.
-    gl::Rectangle renderArea          = getNonRotatedCompleteRenderArea();
+    bool deferClears = binding == GL_DRAW_FRAMEBUFFER;
-    gl::Rectangle scissoredRenderArea = ClipRectToScissor(context->getState(), renderArea, false);
-    bool deferClears                  = binding == GL_DRAW_FRAMEBUFFER;
    // If we are notified that any attachment is dirty, but we have deferred clears for them, a
    // flushDeferredClears() call is missing somewhere.  ASSERT this to catch these bugs.
@@ -1731,23 +1729,6 @@ angle::Result FramebufferVk::syncState(const gl::Context *context,
        contextVk->updateColorMasks(context->getState().getBlendStateExt());
    }
-    // In some cases we'll need to force a flush of deferred clears. When we're syncing the read
-    // framebuffer we might not get a RenderPass. Also when there are masked out cleared color
-    // channels.
-    if (binding == GL_READ_FRAMEBUFFER && !mDeferredClears.empty())
-    {
-        // Rotate scissoredRenderArea based on the read FBO's rotation (different than
-        // FramebufferVk::getRotatedScissoredRenderArea(), which is based on the draw FBO's
-        // rotation).  Since the rectangle is scissored, it must be fully rotated, and not just
-        // have the width and height swapped.
-        bool invertViewport = contextVk->isViewportFlipEnabledForReadFBO();
-        gl::Rectangle rotatedScissoredRenderArea;
-        RotateRectangle(contextVk->getRotationReadFramebuffer(), invertViewport, renderArea.width,
-                        renderArea.height, scissoredRenderArea, &rotatedScissoredRenderArea);
-        ANGLE_TRY(flushDeferredClears(contextVk));
-    }
    // No-op redundant changes to prevent closing the RenderPass.
    if (mCurrentFramebufferDesc == priorFramebufferDesc)
    {