kc3-lang/angle

2020-10-01T05:58:44

Vulkan: Fix unresolve disagreement between FB and RP FramebufferVk::updateRenderPass reset the render pass description, but not the framebuffer description. This caused a disagreement between the two regarding which attachments need to be unresolved. Later, FramebufferVk::startNewRenderPass could miscalculate whether a new framebuffer needs to be generated based on changes in unresolve attachments. For example: - say in the first render pass color needs to be unresolved. Both RP and FB desc would remember this (each being keys for their respective caches). - A following operation triggers syncState such that FB desc changes (for example rebind of attachment), which cleared RP desc but not FB desc's unresolve attachment state. - If the next render pass does not require an unresolve (for example due to a clear or invalidate), then the framebuffer is not recreated because according to RP desc at the start and end of FramebufferVk::startNewRenderPass there has been no change in unresolve mask. * At start there's no unresolve because of syncState clearing it. * At end there's no unresolve because there's no need for unresolve. - In the end, the framebuffer used for the first render pass would be used for the second render pass as well. Note that: * The first render pass included an unresolve, i.e. two subpasses. * The second render pass requires one subpass according to its RP desc. It's quite easy to accidentally have the framebuffer correctly recreated (based on the reset RP desc) before FramebufferVk::startNewRenderPass. Note that since syncState has called updateRenderPass, FB desc has necessarily changed, and mFramebuffer is nullptr, so any call to FramebufferVk::getFramebuffer would recreate the framebuffer. Both clear and invalidate call FramebufferVk::getFramebuffer. The issue is reproducible in situations where clear/invalidate has been called before the framebuffer is modified, and then draw is issued after the modification. An ASSERT is added to catch discrepencies between RP desc and FB desc to catch bugs even when the issue doesn't manifest itself as a VVL error. Bug: angleproject:4836 Change-Id: I8a0d116402a6c298377d03e0908baa942019ccd5 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2442379 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>