| # Deferred Clears |
| |
| Take the following scenario: |
| |
| 1. Application binds and clears FBO1 |
| 2. Application binds FBO2 and renders to it |
| 3. Application binds FBO1 again and renders to it |
| |
| Steps 2 and 3 each require a render pass for rendering. The clear in step 1 can potentially be done |
| through `loadOp` of the render pass for step 3, assuming step 2 doesn't use the attachments of FBO1. |
| This optimization is achieved in ANGLE by deferring clears. |
| |
| When a clear is issued, one of the following happens: |
| |
| - If a render pass is already open, the framebuffer is cleared inline (using |
| `vkCmdClearAttachments`) |
| - If the clear is not to the whole attachment (i.e. is scissored, or masked), a draw call is used to |
| perform the clear. |
| - Otherwise the clear is deferred. |
| |
| Deferring a clear is done by staging a `Clear` update in the `vk::ImageHelper` corresponding to the |
| attachment being cleared. |
| |
| There are two possibilities at this point: |
| |
| 1. The `vk::ImageHelper` is used in any way other than as a framebuffer attachment (for example it's |
| sampled from), or |
| 2. It's used as a framebuffer attachment and rendering is done. |
| |
| In scenario 1, the staged updates in the `vk::ImageHelper` are flushed. That includes the `Clear` |
| updates which will be done with an out-of-render-pass `vkCmdClear*Image` call. |
| |
| In scenario 2, `FramebufferVk::syncState` is responsible for extracting the staged `Clear` updates, |
| assuming there are no subsequent updates to that subresource of the image, and keep them as |
| _deferred clears_. The `FramebufferVk` call that immediately follows must handle these clears one |
| way or another. In most cases, this implies starting a new render pass and using `loadOp`s to |
| perform the clear before the actual operation in that function is performed. This also implies that |
| the front-end must always follow a `syncState` call with a call to the backend (and for example |
| cannot decide to no-op the call in between). That way, the backend has a chance to flush any |
| deferred clears. |
| |
| If the subsequent call itself is a clear operation, there are further optimizations possible. In |
| particular, the previously deferred clears are overridden by and/or re-deferred along with the new |
| clears. |
