commit 9475ac4094664b3fef2d709911553abde7c1e305
author Shahbaz Youssefi <syoussefi@chromium.org> Wed Nov 15 15:25:06 2023
committer Angle LUCI CQ <angle-scoped@luci-project-accounts.iam.gserviceaccount.com> Thu Mar 28 02:18:58 2024
tree 011634c778ddcbc552851bb7a5cc045898464336
parent 085ff15a9f4c31c6bdf18d5e55642b1740103d5d

Vulkan: Make efficient MSAA resolve possible

Prior to this change, using a resolve attachment to implement resolve
through glBlitFramebuffer was done by temporarily modifying the source
FramebufferVk's framebuffer description.  This caused a good deal of
complexity; enough to require the render pass to be immediately closed
after this optimization.
The downsides to this are:

- Only one attachment can be efficiently resolved
- There is no chance for the MSAA attachment to be invalidated

In this change, resolve attachments that are added because of
glBlitFramebuffer are stored in the command buffer, with the
FramebufferVk completely oblivious to them.  When the render pass is
closed, either the FramebufferVk's original framebuffer object is used
(if no resolve attachments are added) or a temporary one is created to
include those resolve attachments.

With the above method, the render pass is able to accumulate many
resolve attachments as well as have its MSAA attachments be invalidated
before it is flushed.

For a FramebufferVk that is resolved in this way, there used to be two
framebuffers created each time and thrown away as the code alternated
between starting a render pass without a resolve attachment and then
closing with one.  With this change, there is now one framebuffer
(without resolve attachments) that is cached in FramebufferVk (and is
not recreated every time), and only the framebuffer with resolve
attachments is recreated every time.

Ultimatley, when VK_KHR_dynamic_rendering is implemented in ANGLE, there
would be no framebuffers to create and destroy, and this change paves
the way for that support too.

WindowSurfaceVk framebuffers are still imagefull.  Making them imageless
adds unnecessary complication with no benefit.

-----------------

To achieve efficient MSAA rendering on tiling hardware, applications
should do the following:

```
glBindFramebuffer(GL_FRAMEBUFFER, msaaFBO);

// Clear the framebuffer to avoid a load
// Or invalidate, if not needed to load:
// glInvalidateFramebuffer(GL_DRAW_FRAMEBUFFER, ...);
glClear(...);

// Draw calls

// Resolve into the single sampled framebuffer
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, resolveFBO);
glBlitFramebuffer(...);
// Immediately discard the contents of the MSAA buffer, to avoid store
glInvalidateFramebuffer(GL_READ_FRAMEBUFFER, ...);
```

The above would translate to the following Vulkan render pass:

- MSAA LOAD_OP_CLEAR/DONT_CARE
- MSAA STORE_OP_DONT_CARE
- Resolve LOAD_OP_DONT_CARE
- Resolve STORE_OP_STORE

This makes sure the MSAA data doesn't leave the tile memory and greatly
reduces bandwidth usage.

Once anglebug.com/4892 is fixed, this would also allow the MSAA image
to never be allocated either.

Bug: angleproject:7551
Bug: angleproject:8625
Change-Id: Ia9f4d20863d76a013d8495033f95c7b39f77e062
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5388492
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>