1823473 - Examine angle for 1 new commits, culminating in 55e2b6daba9d6b10cb2ff97afcf08cece0a43754 (2023-03-20 13:36:00 +0000)

Status: RESOLVED INVALID

(Core :: Graphics, enhancement)

Description

[Update Bot]

We detected new commits to angle on branch 'chromium/5359' which is currently at revision ceec659ac60b0c8ee9d9c602ca1a878ec1d3a88f.

Please review these and determine if an update to the library is necessary.
If no update is necessary, this bug may have its security-group cleared and
set to INVALID. If the issue is security-sensitive it should change to a
security group.

---

55e2b6daba9d6b10cb2ff97afcf08cece0a43754 by Shahbaz Youssefi

https://chromium.googlesource.com/angle/angle/+/55e2b6daba9d6b10cb2ff97afcf08cece0a43754
Authored: 2023-02-16 23:16:46 -0500
Committed: 2023-03-20 13:36:00 +0000

[M108-LTS] Vulkan: Don't close render pass if rebind to same fbo

M108 merge issues:
src/libANGLE/renderer/vulkan/ContextVk.cpp:
- hasActiveRenderPass named hasStartedRenderPass in 108
- getLastRenderPassQueueSerial named getLastRenderPassSerial in 108

In the Vulkan backend, the render pass can occasionally (and
transiently) be in a state of "open but inactive". This is when the
render pass is closed, but has the potential for future modifications
(for example to add a resolve attachment). Under many circumstances, it
is expected that an open render pass cannot be in such a state.

This assumption can be broken in this scenario:

• Open render pass, draw, etc
• Change framebuffer binding
• Change framebuffer binding back to original
• Masked Clear

When ContextVk is synced before clear, it sees that the framebuffer
binding is changed (though it hasn't really), and it closes the render
passes and sets the render pass dirty bit. If a draw were to follow, a
new render pass would have started (unnecessarily). However, in the
case of a masked clear, UtilsVk notices that the render pass is started,
assumes it must be active, and continues recording to it. While the
operation itself succeeds, the assumption that the render pass is active
is false (and fails assertion).

This change makes sure that framebuffer binding change is no-oped if the
framebuffer is the same one that has opened the current render pass. If
any application does unnecessary binding changes and back, it will be
optimized by this change as well.

Bug: chromium:1411210
Change-Id: I37a3a9f2eaa1a81a1b3393840b9458ec71a87377
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4261215
Commit-Queue: Shahbaz Youssefi <[e-mail]>
(cherry picked from commit 05e62f39412e8c6bfc98582f5e7a49041991c97b)
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4303738
Reviewed-by: Shahbaz Youssefi <[e-mail]>

Files Modified:

• src/libANGLE/renderer/vulkan/ContextVk.cpp
• src/tests/gl_tests/ClearTest.cpp
• src/tests/gl_tests/VulkanPerformanceCounterTest.cpp

---

Comment 1

[Kelsey Gilbert [:jgilbert]]

We don't use ANGLE's Vulkan backend.