Vulkan: Optimize sync followed by swap Previously, inserting a sync object immediately caused a submission. That was done in https://chromium-review.googlesource.com/c/angle/angle/+/3200274 to be able to wait until the sync object is signaled without having to wait for whatever is recorded after it until a flush naturally happens. Some applications issue a glFenceSync right before eglSwapBuffers. The submission incurred by glFenceSync disallowed the optimizations that eglSwapBuffers would have done, leading to performance degradations. This could have been avoided if glFenceSync was issued right after eglSwapBuffers, but that's not the case with a number of applications. In this change, when a fence is inserted: - For EGL sync objects, a submission is issued regardless - For GL sync objects, a submission is issued if there is no render pass open - For GL sync objects, the submission is deferred if there is an open render pass. This is done by marking the render pass closed, and flagging the context as having a deferred flash. If the context that issued the fence sync issues another draw call, the render pass is naturally closed and the submission is performed. If the context that issued the fence sync causes a submission, it would have a chance to modify the render pass before doing so. For example, it could apply swapchain optimizations before swapping, or add a resolve attachment for blit. If the context that issued the fence sync doesn't cause a submission before another context tries to access it (get status, wait, etc), the other context will flush its render pass and cause a submission on its behalf. This is possible because the deferral of submission is done only for GL sync objects, and those are only accessible by other contexts in the same share group. Bug: angleproject:7379 Change-Id: I3dd1c1bfd575206d730dd9ee2e33ba2254318521 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3695520 Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org>