kc3-lang/angle

2024-11-20T19:47:49

Vulkan: Remove vkAcquireNextImageKHR multi-threading support Currently, it is not possible to call `TryAcquireNextImageUnlocked()` from multiple threads. However, original implementation added multi-threading support for future use. Possible future use: - First thread (where Surface is current) calls `eglPrepareSwapBuffersANGLE()` which will call `TryAcquireNextImageUnlocked()` in the unlocked tail call (without the share group lock). - Other thread (where shared Context is current) calls some EGL/GLES API under the share group lock, that may cause calling `doDeferredAcquireNextImage()` on the Surface from the first thread. Calling this method may call `TryAcquireNextImageUnlocked()` under the share group lock, while it is also called from the first thread in the unlocked tail call. Calling `doDeferredAcquireNextImage()` may also cause swapchain recreation. Taking into account above scenario, current implementation has following bugs: 1. Possibility to recreate the swapchain from other thread, while first thread is going to or calling the `TryAcquireNextImageUnlocked()` function: a) Other thread may call `prepareForAcquireNextSwapchainImage()` because `NeedToProcessAcquireNextImageResult()` is still false until first thread finishes `TryAcquireNextImageUnlocked()` call. Also, checking `NeedToProcessAcquireNextImageResult()` from other thread is not thread safe. b) Other thread finished `TryAcquireNextImageUnlocked()` first, but with `VK_ERROR_OUT_OF_DATE_KHR` error. First thread still did not get the chance to call this function because of OS's thread scheduling delays. Other thread will set `needToAcquireNextSwapchainImage = true` and will start to recreate a swapchain. At this time, first thread will start executing `TryAcquireNextImageUnlocked()`, and because bool is true - it will actually perform ANI during recreate from other thread. 2. Possibility to call `TryAcquireNextImageUnlocked()` with old swapchain. This is similar to (1), but this time call is delayed after swapchain is recreated. Since above scenario currently is not possible and the described future scenario is unlikely to ever happen, instead of fixing above problems this CL removes the multi-threading support to simplify the code and make these bugs N/A. Change removes word "try" from structures, members, and functions because without multithreading there is no need for that and just adds unnecessary complication. It also removes most of the "share group lock" mentions because now this information is irrelevant and may cause confusion. What is relevant is that `AcquireNextImageUnlocked()` MUST only be called from a thread where Surface is current and only CAN access members that is only ever accessed from this thread (regardless if the lock is taken or not). For example, if in the future `unlockedAcquireResult` will be accessed from other thread but with the share group lock held, while `AcquireNextImageUnlocked()` will still only be called from the current thread - then this will be a race condition. Bug: angleproject:42265346 Bug: angleproject:42266579 Change-Id: Ie9be408c0a3b3c1f37ec80727ce5ad2cb8932dad Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6018093 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>