kc3-lang/angle

2024-05-06T12:36:20

Vulkan: Move RefCountedEvent GC and recycler to ShareGroupVk (2/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. This is the second CL in the series. In this CL, we added RefCountedEventsGarbageRecycler to the ShareGroupVk which is responsible to garbage collect and recycle RefCountedEvent. Since most of ImageHelper code have only access to Context argument, for convenience we also stored the RefCountedEventsGarbageRecycler pointer in the vk::Context for easy access. vk::Context argument is also passed to RefCounteEvent::init and release function so that it has access to the recycler. The garbage collection happens when RefCountedEvent is needed. The per renderer recycler is still kept to hold the RefCounteEvents that gets released from ShareGroupVk or when it is released without access to context information. Bug: b/336844257 Change-Id: I36fe5d1c8dacdbe35bb2d380f94a32b9b72bbaa5 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5529951 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>