Vulkan: Defer clears even if following command is scissored
Take the following scenario:
1. glClear
2. glScissor(half of framebuffer)
3. glDrawArrays
The clear in step 1 is deferred. When FramebufferVk::syncState is
called in step 3, the deferred clear was applied using
vkCmdClearColorImage because the draw call is scissored. This causes
loadOp=LOAD to be used after the clear because the render pass is
started too small (the same size as the scissor).
This change makes scissored operations also take advantage of
loadOp=LOAD with deferred clears. A number of changes are made to this
effect:
- FramebufferVk::syncState no longer limits collecting deferred clears
to no-scissor.
- FramebufferVk::startNewRenderPass automatically expands the render
area to full size if it's clearing any attachment.
- A number of bugs are fixed where FramebufferVk::flushDeferredClears is
called with the scissor area. Instead, flushDeferredClears now
unconditionally uses the complete render area. Note that these bugs
didn't have symptoms as "scissor" and "deferred clears" were mutually
exclusive.
Bug: angleproject:4988
Change-Id: I24fc3d88bf9c8998869b36c863692d0f0acce994
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2511371Reviewed-by:
Jamie Madill <jmadill@chromium.org>
Reviewed-by:
Tim Van Patten <timvp@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Showing
Please
register
or
sign in
to comment