kc3-lang/angle

2024-05-06T11:03:19

Vulkan: Move RefCountedEvent GC and recycler to ShareGroupVk (1/3) One of the problem we had with RefCountedEvents is CPU overhead comes with it, and some part of the CPU overhead is due to atomic reference counting. The RefCountedEvents are only used by ImageHelper and ImageHelpers are per share group, so they are already protected by front end context share lock. The only reason we needs atomic here is due to garbage cleanup, which runs in separate thread and will decrement the refCount. The idea is to move that garbage list from RendererVk to ShareGroupVk so that access of RefCountedEvents are all protected already, thus we can remove the use of atomic. The down side with this approach is that a share group will hold onto its event garbage and not available for other context to reuse. But VkEvents are expected to be very light weighted objects, so that should be acceptable (If not, we can add some limit to the number of events it can hold in the garbage list). This is the first CL in the series. Before this CL, the RefCounteEvents are garbage collected at flushToPrimrary time, at which time we have lost ContextVk information. In order for us to do garbage collect to ShareGroupVk, we need to move the garbage collection process early, before command buffers leaving ContextVk's visibility. For OutsideRenderPassCommands, this is easy to do, we just call flushSetEvents before we call mRenderer->flushRenderPassCommands. For RenderPassCommands, that flushSetEvents call will simply make another copy of RefCountedEvents and add to the garbage list and the actual VkCmdSetEvents are defered at the executeSetEvents call that get called from flushToPrimrary time. Bug: b/336844257 Change-Id: I1948cd8240ff61d407931083b7584a54b1dc6b0d Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5517891 Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>