commit 3dfc800437f79626bfd2158c04b13a5aaae2e016
author Shahbaz Youssefi <syoussefi@chromium.org> Wed Jun 08 14:24:48 2022 -0400
committer Angle LUCI CQ <angle-scoped@luci-project-accounts.iam.gserviceaccount.com> Fri Jun 10 03:15:01 2022 +0000
tree 01a3c332458c17c9575a6d53fe2ec377e018d346
parent 48195ae678d2856e5def43769e8bf02e9d1bb90d

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>