Vulkan: Fix invalidate + deferred clear Imagine the following scenario: 1. Clear draw framebuffer 2. Invalidate draw framebuffer 3. Copy from read framebuffer into texture that is attached to draw framebuffer 4. Draw again into draw framebuffer At step 2, FramebufferVk::syncState is called which extracts the clear and stores it in mDeferredClears, but since the framebuffer description hasn't changed, a new render pass is not started. At step 3, the texture attached to the draw framebuffer is used as copy destination, but its clear which is stored in the (apparently irrelevant) draw framebuffer is not flushed. At step 4, a new render pass is started which clears the draw framebuffer, trampling the copy in step 3. This change makes sure invalidate results in a flushDeferredClears(). With glInvalidateFramebuffer() (not glInvalidateSubFramebuffer()), the deferred clears for invalidated framebuffers are discarded first. It is unknown whether there are similar situations where syncState gathers deferred clears, but they are not flushed before the attachments are updated outside the framebuffer. To catch similar bugs in the future, assertions are added to FramebufferVk::syncState such that if a dirty bit is set for the contents of an attachment, we can make sure there are no prior deferred clears stored for that attachment. Bug: angleproject:4862 Change-Id: Idb1a08b53e7f011f0fc9a54d478289030b6d77a8 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2308034 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>