kc3-lang/angle/src/libANGLE/renderer/vulkan/CommandProcessor.cpp

src/libANGLE/renderer/vulkan/CommandProcessor.cpp

Log

Author Commit Date CI Message
Charlie Lao dbdc9551 2024-09-16T10:19:47 Vulkan: Let asyncCommandBufferReset control garbage cleanup So that people can toggle the flag to compare perf/power difference with async thread doing garbage clean up AND command buffer reset. This also renames feature flag asyncCommandBufferReset to asyncCommandBufferResetAndGarbageCleanup to reflect the implementation. Bug: b/255411748 Change-Id: Id459e6f4dc81ec76b6c0c2dba0db46041ea6ae8a Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5867389 Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Shahbaz Youssefi 7d461b21 2024-07-10T14:11:53 Revert "Vulkan: Use VK_KHR_dynamic_rendering[_local_read]" This reverts commit c379ff48043a47e444c388c45270db40d3172d50. Reason for revert: Regresses CPU perf and memory when _not_ using DR Original change's description: > Vulkan: Use VK_KHR_dynamic_rendering[_local_read] > > Bug: angleproject:42267038 > Change-Id: I1f4eb0f309992a9c1c287a69520dadf5eff23b26 > Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5637155 > Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> > Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> > Reviewed-by: Charlie Lao <cclao@google.com> Bug: angleproject:42267038 Change-Id: I3865f0d86813f0eeb9085a92875a33bd449b907f Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5691337 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi c379ff48 2024-06-10T22:01:57 Vulkan: Use VK_KHR_dynamic_rendering[_local_read] Bug: angleproject:42267038 Change-Id: I1f4eb0f309992a9c1c287a69520dadf5eff23b26 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5637155 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Reviewed-by: Charlie Lao <cclao@google.com>
Charlie Lao 9d124c35 2024-05-21T10:36:27 Vulkan: Store QueueIndex in DeviceQueueMap VkGetDeviceQueue call takes two indices: queueFamilyIndex and queueIndex. Right now DeviceQueueMap only stores queueFamilyIndex. This CL also stores queueIndex in the DeviceQueueMap. In later CL, we are going to expose this queueIndex to vk::Context and vk::ImageHelper along with queueFamilyIndex. In order to do it in a cleaner way, this CL mostly involves cleanup. Previously DeviceQueueMap is a subclass of angle::PackedEnumMap. In this CL, DeviceQueueMap has mQueueAndIndices data member that maps priority to devicePriority/queueIndex/VkQueue. Previously DeviceQueueMap was created in Renderer::createDeviceAndQueue() and then passed to CommandQueue::init(), which copies to mQueueMap. This CL removes the copy. It now calls mQueueMap.initialize() directly from CommandQueue::init(). This CL also cleans up relationship between QueueFamily and DeviceQueueMap. Before this CL, QueueFamily::initializeQueueMap() initialiazes DeviceQueueMap object. After this CL, that logic now moves to DeviceQueueMap::initialize(). QueueFamily no longer modifies DeviceQueueMap class. No functional change is expected. Bug: b/337135577 Change-Id: I3f96fb78aedc89d96d6235b060c88b769bdd1e24 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5553066 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao ea36ed34 2024-05-21T10:03:51 Vulkan: Rename mIndex to mQueueFamilyIndex In preparation for the later CLs that expose the VkQueue index to vk::Context, this CL renames mIndex to mQueueFamilyIndex so that we do not confused what *index* really means. No functional change expected. Bug: b/337135577 Change-Id: I6a089716a9586e9c404ec6c1d557a563dccf927c Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5553086 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Shahbaz Youssefi 2eed792c 2024-04-15T01:09:57 Vulkan: Use angle::SimpleMutex with async command queue This change lets ANGLE test the waters with angle::SimpleMutex with functionality that is currently mostly exercised by tests. Bug: angleproject:8667 Change-Id: Icf3a021da1f0a2e1c9235ed518bcb9e378b09cfa Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5446560 Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Roman Lavrov <romanl@google.com>
Shahbaz Youssefi 9475ac40 2023-11-15T10:25:06 Vulkan: Make efficient MSAA resolve possible Prior to this change, using a resolve attachment to implement resolve through glBlitFramebuffer was done by temporarily modifying the source FramebufferVk's framebuffer description. This caused a good deal of complexity; enough to require the render pass to be immediately closed after this optimization. The downsides to this are: - Only one attachment can be efficiently resolved - There is no chance for the MSAA attachment to be invalidated In this change, resolve attachments that are added because of glBlitFramebuffer are stored in the command buffer, with the FramebufferVk completely oblivious to them. When the render pass is closed, either the FramebufferVk's original framebuffer object is used (if no resolve attachments are added) or a temporary one is created to include those resolve attachments. With the above method, the render pass is able to accumulate many resolve attachments as well as have its MSAA attachments be invalidated before it is flushed. For a FramebufferVk that is resolved in this way, there used to be two framebuffers created each time and thrown away as the code alternated between starting a render pass without a resolve attachment and then closing with one. With this change, there is now one framebuffer (without resolve attachments) that is cached in FramebufferVk (and is not recreated every time), and only the framebuffer with resolve attachments is recreated every time. Ultimatley, when VK_KHR_dynamic_rendering is implemented in ANGLE, there would be no framebuffers to create and destroy, and this change paves the way for that support too. WindowSurfaceVk framebuffers are still imagefull. Making them imageless adds unnecessary complication with no benefit. ----------------- To achieve efficient MSAA rendering on tiling hardware, applications should do the following: ``` glBindFramebuffer(GL_FRAMEBUFFER, msaaFBO); // Clear the framebuffer to avoid a load // Or invalidate, if not needed to load: // glInvalidateFramebuffer(GL_DRAW_FRAMEBUFFER, ...); glClear(...); // Draw calls // Resolve into the single sampled framebuffer glBindFramebuffer(GL_DRAW_FRAMEBUFFER, resolveFBO); glBlitFramebuffer(...); // Immediately discard the contents of the MSAA buffer, to avoid store glInvalidateFramebuffer(GL_READ_FRAMEBUFFER, ...); ``` The above would translate to the following Vulkan render pass: - MSAA LOAD_OP_CLEAR/DONT_CARE - MSAA STORE_OP_DONT_CARE - Resolve LOAD_OP_DONT_CARE - Resolve STORE_OP_STORE This makes sure the MSAA data doesn't leave the tile memory and greatly reduces bandwidth usage. Once anglebug.com/4892 is fixed, this would also allow the MSAA image to never be allocated either. Bug: angleproject:7551 Bug: angleproject:8625 Change-Id: Ia9f4d20863d76a013d8495033f95c7b39f77e062 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5388492 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 914fe61b 2024-03-15T13:20:49 Vulkan: Rename RendererVk.* to vk_renderer.* Done in a separate CL from the move to namespace vk to avoid possible rebase-time confusion with the file name change. Bug: angleproject:8564 Change-Id: Ibab79029834b88514d4466a7a4c076b1352bc450 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5370107 Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Shahbaz Youssefi 60aaf4a0 2024-03-14T12:58:56 Vulkan: Move renderer to namespace vk This class is agnostic of EGL. This change moves it to namespace vk for use with the OpenCL implementation Bug: angleproject:8564 Change-Id: I57f7807d6af8b3d5d7f8efbaf8b5d537a930f881 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5371324 Reviewed-by: Austin Annestrand <a.annestrand@samsung.com> Reviewed-by: Geoff Lang <geofflang@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi d4281637 2023-11-15T13:17:36 Add names to worker threads Bug: angleproject:8417 Change-Id: I5841d194cb695387aa8fe48638cc025173152347 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5034797 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 6f794eab 2023-10-05T11:23:30 Change angle::FixedQueue's storage from std::array to std::vector Right now angle::FixedQueue uses std::array as the storage. In the case when queue is full, the only choice is to wait for dequeue thread to run until there is more room to enqueue. This CL try to add extra flexibility. In this CL< it switches storage to std::vector so that we could reallocate to double the storage when it is full. The trick is that before doing that, you must ensure no one is accessing the queue other than check the size. In a lot of usage cases that is easy to do by just grabbing the necessary locks. Bug: b/302739073 Change-Id: Ibefe0fd0e3e89c17dd6ee2cac6adc3368122adb9 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4915811 Reviewed-by: Hailin Zhang <hailinzhang@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Mohan Maiya ec89b1a2 2023-09-11T12:25:10 Vulkan: Bugfix in waitForResourceUseToFinishWithUserTimeout The commit 6d282d62b39b177e5762e01de3d382984494f07d introduced a bug where <result> was not being set in all code paths, now we do. Bug: b/255411748 Bug: angleproject:8340 Change-Id: Ic191f9e09c35a64ae2393d9670a3a9e33cd5e102 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4854941 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: mohan maiya <m.maiya@samsung.com> Reviewed-by: Charlie Lao <cclao@google.com>
Shahbaz Youssefi 571b4cdb 2023-08-14T16:55:28 Vulkan: Move pipeline/desc-set layout creation to link job The pipeline and desc-set layout caches are consequently made thread-safe. The reference counter on the layouts are also made atomic. With this change, practically all of the link in the Vulkan backend is moved to the link job. Bug: angleproject:8297 Change-Id: Iba694ece5fc5510d34cce2c34441ae08ca5bb646 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4774787 Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Amirali Abdolrashidi 5f9548c3 2023-05-19T11:51:04 Vulkan: Free the garbage memory before realloc Currently image allocations fall back to system memory in case of a device OOM. However, in some cases, it is also possible to gain some memory by freeing garbage memory from the device. This allows us to keep the allocation on the device memory. * Updated the image allocation fallback, so we will try cleaning the garbage memory through the renderer before retrying the allocation. * finishOneCommandBatchAndCleanup() in RendererVk, which will call a similar function in its CommandQueue. It will be called until there are no more in-flight submissions. * The existing finishOneCommandBatchAndCleanup() in CommandQueue has been renamed to finishOneCommandBatchAndCleanupImpl(). * Updated the flags used for VMA image allocations. If any device memory is freed after garbage cleanup to make enough space for the new allocation, it will take precedence over the system memory. * Added unit tests in which a new image allocation could happen on the device after freeing the garbage memory. * They use a 2D texture and a 2D texture array for garbage. Bug: b/280304441 Change-Id: Ia5e605e180833b44af8c77550ab1b0b8ba21724e Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4547941 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Igor Nazarov 255c6738 2023-04-28T21:08:01 Vulkan: Fix flaky linux-asan-test failure with asyncCommandQueue Regression from this commit: Vulkan: Clean up CommandProcessor::queuePresent https://chromium-review.googlesource.com/c/angle/angle/+/4257927 Details: - `CommandProcessor::processTask()` handles `CustomTask::Present`; - It calls `CommandProcessor::present()` that assigns `swapchainStatus->isPending = false`; - `CommandProcessor` thread is suspended for a while...; - `WindowSurfaceVk::destroy()` calls `waitForPresentToBeSubmitted()`; - It sees that `swapchainStatus->isPending == false` and skips waiting; - `WindowSurfaceVk` (and `SwapchainStatus` ) instance is destroyed; - `CommandProcessor` thread resumes and checks `task->getSwapchainStatus()->lastPresentResult` - ASAN failure. The 460 bytes offset is `SwapchainStatus::lastPresentResult` member inside `WindowSurfaceVk` instance. Test that failed: ImageTest.ValidationGLEGLImageExternal/ES2_Vulkan_SwiftShader_AsyncCommandQueue ==27108==ERROR: AddressSanitizer: heap-use-after-free on address 0x61e0000eea4c at pc 0x7f98434e0e10 bp 0x7f98363c0a70 sp 0x7f98363c0a68 READ of size 4 at 0x61e0000eea4c thread T29 #0 0x7f98434e0e0f in rx::vk::CommandProcessor::processTask(rx::vk::CommandProcessorTask*) src/libANGLE/renderer/vulkan/CommandProcessor.cpp:664:59 0x61e0000eea4c is located 460 bytes inside of 2880-byte region [0x61e0000ee880,0x61e0000ef3c0) freed by thread T0 here: #0 0x5651c72a563d in operator delete(void*) /b/s/w/ir/cache/builder/src/third_party/llvm/compiler-rt/lib/asan/asan_new_delete.cpp:152:3 #1 0x7f9843f4c8c9 in SafeDelete<rx::SurfaceImpl> src/common/angleutils.h:285:5 previously allocated by thread T0 here: #0 0x5651c72a4ddd in operator new(unsigned long) /b/s/w/ir/cache/builder/src/third_party/llvm/compiler-rt/lib/asan/asan_new_delete.cpp:95:3 #1 0x7f9843a38599 in rx::DisplayVkXcb::createWindowSurfaceVk(egl::SurfaceState const&, long) src/libANGLE/renderer/vulkan/linux/xcb/DisplayVkXcb.cpp:99:12 Bug: b/269524271 Change-Id: Ie70bc9e2b89267653ddb6b3a30c1a67e22864f26 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4491743 Commit-Queue: Igor Nazarov <i.nazarov@samsung.com> Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Igor Nazarov 903d9fdf 2023-01-19T15:37:45 Vulkan: Implement ExternalFence for use in SyncHelperNativeFence `ExternalFence` allows concurrent usage in `CommandQueue` and `SyncHelperNativeFence` classes eliminating need of additional `vkQueueSubmit()` call. Waiting in `CommandQueue` on `QueueSerial` or `ResourceUse` will ensure corresponding state of the native FD (because `CommandQueue` will wait on the same FD instead of some other fence). After this change there will be only single `vkQueueSubmit()` call from the `SyncHelperNativeFence::initializeWithFd()` method. This CL and the follow-up is sufficient to fix the bugs below. Bug: angleproject:8115 Bug: angleproject:8117 Test: angle_end2end_tests --gtest_filter=EGLSyncTest.AndroidNativeFence_ExternalFenceWaitVVLBug* Change-Id: Ic562ecc71a95203454a1dc438589a13bcf3bff7f Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4392879 Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Igor Nazarov <i.nazarov@samsung.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Igor Nazarov e24f4519 2023-01-19T02:30:39 Vulkan: Add externalFence into submitCommands() Currently one-off fence in the `queueSubmitOneOff()` is used only in `SyncHelperNativeFence::initializeWithFd()` to submit external fence. Other `queueSubmitOneOff()` calls may use `QueueSerial` instead of a fence. Providing `fence` into `queueSubmitOneOff()` prevents tracking that submission with `QueueSerial`. Therefore using `mUse` to collecting `mFenceWithFd` as garbage will not work as intended. This CL removes `fence` from `queueSubmitOneOff()` and adds optional `externalFence` into `submitCommands()` instead. Providing `externalFence` will cause additional `vkQueueSubmit()` call: - first submission will submit everything as usual except using the `externalFence`. - second, will only submit internal `CommandQueue` fence for `QueueSerial` tracking. As the result of this CL, call to `initializeWithFd()` will always produce two (2) `vkQueueSubmit()` calls. Previously it may be one (1) or two (2) submissions. Future CL will reduce submission count to one (1). If add additional submission into `queueSubmitOneOff()` instead of `submitCommands()`, then maximum number of submissions will be three (3). Bug: angleproject:8117 Change-Id: I6f1ec12682aaab71bfc871e665fec2659df96b26 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4392877 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Charlie Lao 90539b10 2023-04-24T16:36:01 Vulkan: Clean up some of trace events CommandBuffer::begin/end/reset events are too fine grain. The trace event retireFinishedCommandsLocked already covers reset. Also made flushImpl generate event only if we did submit, if we end up early out, that is not interesting. Also add event for fenceWait, since that is quite important for performance investigation, sometimes an indication of bad synchronization. Bug: b/277644512 Change-Id: I7d2f6d0716a83bf3b88a9e590ddc042b038b347a Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4471747 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Charlie Lao 65ed3050 2023-04-04T11:57:38 Vulkan: Let recordWriteBarrier use CommandBufferHelper This is preparation for next CL. It changes OutsideRenderPassCommandBuffer argument to OutsideRenderPassCommandBufferHelper for recordWriteBarrier() and recordReadBarrier() calls, so that it has access to the helper object (will be used in next CL). It passes CommandsState to executeBarriers() instead of PrimaryCommandBuffer. No actual functionality change is expected. Bug: b/275624771 Change-Id: Ia06a0398a127539b0b642005803a498cb2a9d7f1 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4400407 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 20f875f8 2023-04-05T09:47:46 Vulkan: Add commandQueueWaitSemaphoresTotal perf counter This counts total number of wait semaphores we submitted. This will be used to write test to ensure that we insert wait semaphores properly in future CLs. Bug: b/275624771 Change-Id: I5b8e209500ff553617f6b30c2f8b4626d29c0e6a Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4400823 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Charlie Lao <cclao@google.com>
Igor Nazarov 9a2ef389 2023-04-04T14:57:09 Vulkan: Minor protected submitCommands() optimization. Bug: angleproject:3965 Change-Id: I52a7597f1dd3bdaf4a221c6b6338caa1577c08f9 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4392876 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Igor Nazarov 9524c639 2023-01-17T18:47:47 Vulkan: Fix Secondary Command Buffers with asyncCommandQueue. This change fixes following errors (asyncCommandQueue = true): 1. "vkEndCommandBuffer()" called from "asyncCommandQueue" thread. Call stack: vkEndCommandBuffer() VulkanSecondaryCommandBuffer::end() OutsideRenderPassCommandBufferHelper::flushToPrimary() CommandQueue::flushOutsideRPCommands() CommandProcessor::processTask() Fixed by calling "vkEndCommandBuffer()" from the Context thread in the new "OutsideRenderPassCommandBufferHelper::detachCommandPool()" method. 2. "vkAllocateCommandBuffers()/vkBeginCommandBuffer()" called from "asyncCommandQueue" thread. Call stack: vkAllocateCommandBuffers()/vkBeginCommandBuffer() VulkanSecondaryCommandBuffer::initialize() <*>CommandBufferHelper::initializeCommandBuffer() <*>CommandBufferHelper::reset() <*>CommandBufferHelper::flushToPrimary() CommandQueue::flush<*>Commands() CommandProcessor::processTask() Fixed by calling "vkAllocateCommandBuffers()/vkBeginCommandBuffer()" from the Context thread in the new "<*>CommandBufferHelper::attachCommandPool()" method. 3. "SecondaryCommandPool::collect()" called from "asyncCommandQueue" thread without synchronization. Call stack: SecondaryCommandPool::collect() rx::vk::RecycleCommandBufferHelper() CommandBufferRecycler<>::recycleCommandBufferHelper) RendererVk::recycle<*>CommandBufferHelper() CommandProcessor::processTask() No need for this call, because "SecondaryCommandPool" is already detached. Notes: This CL not only fixes errors, but also optimizes CommandBufferHelper recycling. Before, there was no recycling plus unnecessary "VulkanSecondaryCommandBuffer" allocation/freeing. Further optimization may add multiple "VkCommandPool"s to the "SecondaryCommandPool" to allow resetting buffers in the async thread. Bug: angleproject:6811 Bug: angleproject:6100 Change-Id: I7004c27a112e916c5c973b43b137193017d6aa3d Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4342189 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Igor Nazarov 7d1a401b 2023-01-17T18:45:55 Vulkan: Fix freeing not completed Secondary Command Buffers. Problem: - Protected Context flushes its commands to the Protected Primary Command Buffer; - Unprotected Context flushes its commands to the Unprotected Primary Command Buffer; - Context with different "egl::ContextPriority" may flush commands into different Primary Command Buffers. - Secondary Command Buffers from all Contexts end-up in the single "CommandBufferRecycler::mSecondaryCommandBuffersToReset" list; - One of the Contexts submits its Primary Command Buffer, and attaches current "mSecondaryCommandBuffersToReset" list to the "CommandBatch"; - Secondary Command Buffers of other Contexts may be collected and later freed by "SecondaryCommandPool" without submitting/completion corresponding Primary Command Buffers. Fix: - Moving "mSecondaryCommandBuffersToReset" to the new "SecondaryCommandBufferCollector" class. - Separate "SecondaryCommandBufferCollector" instance is stored in the "CommandQueue" for each current Primary Command Buffer. Additionally fixes "asyncCommandQueue" related problem: "releaseCommandBuffersToReset()" may get outdated results if flush is not yet executed in the "asyncCommandQueue" thread. Bug: angleproject:6100 Change-Id: I7df161ac1f999fb34d4eccaebb603c58ecb1ac11 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4334579 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Igor Nazarov 9b6368cc 2023-03-14T14:48:30 Vulkan: Fix freeing Secondary Command Buffers from wrong thread. Problem: - Secondary Command Buffers are freed in the "CommandQueue" class. - This may happen from any Context thread that calls "checkCompletedCommands()" or "finish<*>()" methods. - As the result, one Command Buffer may be freed from one thread, while other Command Buffer from the same "VkCommandPool" is allocated/reset/recorded in the other thread. Vulkan spec demands external "VkCommandPool" synchronization for any modifications (begin/end/reset/free/cmd) on its "VkCommandBuffer"s. Fix: - Added new "rx::vk::SecondaryCommandPool" class that replaces the "rx::vk::CommandPool" wrapper. - This class has "collect()" method for storing "VkCommandBuffer"s. Collected buffers are freed from the correct thread on the next "allocate()" call. This CL only fixes the problem, keeping Secondary Command Buffer memory management as is (allocate/free single buffer without reuse). In the future CLs this behavior may be changed (reuse buffers, reset/free entire pools). Bug: angleproject:6100 Change-Id: If938416c4df4fe55f0cfb418b6759721ac53098b Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4334577 Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Igor Nazarov <i.nazarov@samsung.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Igor Nazarov 29f80eda 2023-03-15T14:59:26 Vulkan: Hot fix crash when using Invalid VkSemaphore Object. Problem started after the commit: b194c21ad30145ca15153a93425a37a8211df373 Vulkan: Enforce ContextPriority in ShareGroup and with EGLImage Happens only with enabled "asyncCommandQueue" feature: - "RendererVk::submitPriorityDependency()" creates "Vk::Semaphore" object on the stack. - Then submits this Semaphore with "queueSubmitWaitSemaphore()" method. - "vk::Semaphore" passed to the "CommandProcessor"s "enqueueSubmitOneOffCommands()" method where stored in the "CommandProcessorTask". - Stack "vk::Semaphore" object garbage collected by the "RendererVk" and then destroyed. - "CommandProcessorTask" now points to the invalid memory. This CL changes usage of "vk::Semaphore" and "vk::Fence" pointers in the "CommandProcessor.h" classes to Vulkan Handles. This will make API consistent, fix this problem, and avoid similar problems in the future. Issue discovered while testing ANGLE as a system driver on S906B with "asyncCommandQueue" enabled. Several system processes crashed with VVL: VUID-VkSubmitInfo-pWaitSemaphores-parameter(ERROR / SPEC):msgNum: -1328048864 - Validation Error: [ VUID-VkSubmitInfo-pWaitSemaphores-parameter ] Object 0: handle = 0xb4000078c1aab430, type = VK_OBJECT_TYPE_INSTANCE; | MessageID = 0xb0d79520 | Invalid VkSemaphore Object 0xb400007831740b98. The Vulkan spec states: If waitSemaphoreCount is not 0, pWaitSemaphores must be a valid pointer to an array of waitSemaphoreCount valid VkSemaphore handles (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-VkSubmitInfo-pWaitSemaphores-parameter) Bug: angleproject:8039 Change-Id: I8818288b9783b5c5a7970bf82ec721452ae57471 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4339758 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Igor Nazarov 4edccb15 2023-01-17T16:17:35 Vulkan: Fixed Context Priority mixing problems. Problem details: - Each "egl::ContextPriority" may have separate "VkQueue". - "CommandQueue" only has two "PrimaryCommandBuffer"s for normal and protected content. - Commands from multiple "ContextVk" may be written to a single "PrimaryCommandBuffer". - That "PrimaryCommandBuffer" may be randomly submitted to different "VkQueue"s. - As the result - Commands from a single "ContextVk" may be submitted to multiple "VkQueue"s. Fix details: - Created separate "PrimaryCommandBuffer" (lazily allocated) for each "egl::ContextPriority". - Commands with different priorities can't be mixed in a single "PrimaryCommandBuffer". - Therefore - Commands from a single "ContextVk" will be submitted to a single "VkQueue". - No difference for applications that use single "egl::ContextPriority" for all Contexts. Notes: Another problem when resource is used in multiple Contexts with different "VkQueue" (Priority). One solution is to use Semaphores. Another is to enfore same Priority for all Contexts in a Share Group and Default Priority when using EGLImage. This solution was submitted in the previous CL: Vulkan: Enforce ContextPriority in ShareGroup and with EGLImage Below test fails on G996B without this CL. Bug: angleproject:8039 Test: angle_end2end_tests --gtest_filter=MultithreadingTestES3.ContextPriorityMixing* Change-Id: Iaa57826ca55956944f922813fcfac42f1a764dbb Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4194183 Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Igor Nazarov <i.nazarov@samsung.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Igor Nazarov 267c556e 2023-03-06T18:03:36 Vulkan: Move PersistentCommandPool out of the CommandsState. Refactoring before the actual fix. Bug: angleproject:8039 Change-Id: Ib240cb9a2e9b92eab120c946b15ac285b939c7db Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4307875 Commit-Queue: Igor Nazarov <i.nazarov@samsung.com> Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 991fca06 2023-03-06T10:31:48 Vulkan: Minor clean up in CommandProcessor.cpp Minor clean up per the feedback from already merged CLs. Bug: b/255411748 Change-Id: I3d0148700cf79fa597e260e7192d419198f9749f Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4311756 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Igor Nazarov fee173f9 2023-01-17T18:45:41 Vulkan: Fix freeing Command Buffers with wrong Pool. Problem: - Multiple Contexts flushes it's commands to the Primary Command buffer; - Secondary Command Buffers from all Contexts end-up in the single "CommandBufferRecycler::mSecondaryCommandBuffersToReset" list; - One of the Contexts submits all these commands, and attaches it's "VkCommandPool" to the "CommandBatch". - This "VkCommandPool" will be used to free "VkCommandBuffer"s from all Contexts and pools. Fix: - Attaching "VkCommandPool" to each "VulkanSecondaryCommandBuffer" instance. - "vkFreeCommandBuffers()" is called from the new "VulkanSecondaryCommandBuffer::free()" method. Bug: angleproject:6100 Change-Id: Ic4d66d8b0f71e5ff06047004ed21428d6dce385b Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4300870 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com>
Charlie Lao 256e7d6d 2023-03-02T13:23:11 Vulkan: Always checkCompletedCommands from finishResourceUse There is one difference in crrev.com/c/4244823, that before the CL, we always check every command to see if it finished or not. After the CL, we stop as soon as we find ResourceUse is finished. This CL gets back old behavior to help speed up garbage collection. Bug: chromium:1420669 Change-Id: I6bf833bd3347ee683b6b9d78628ac9618845c9e2 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4304802 Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao 044612ec 2023-02-27T14:59:29 Vulkan: Remove iterator from FixedQueue class Previously there was code that still walking each element of FixedQueue, that was mostly removed in previous CLs. The only remaining usage is for assertion which the value is minimal. This CL removes the iterator from FixedQueue so that it behaves just like queue, thus avoiding potential risk of misuse. Bug: b/255411748 Change-Id: I4c0debf5b6c8b603e384c681f1a123c2ee06dcbb Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4294695 Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao 31bd0c58 2023-03-01T10:52:30 Vulkan: Do immediate cleanup after finishOneCommandBatch This is follow up for crrev.com/c/4244823. This adds postSubmitCheck in RendererVk::queueSubmitOneOff(). It adds immediate clean up in finishOneCommandBatch and renamed to finishOneCommandBatchAndCleanup. Bug: b/255411748 Change-Id: I1d3dbd7dfe9642f4bc77b17552281a4c7b6c2d69 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4300098 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Igor Nazarov <i.nazarov@samsung.com> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Charlie Lao e88b061c 2023-02-17T13:36:24 Vulkan: Follow up fix and enable asyncCommandBufferReset flag This CL makes any follow up fix for crrev.com/c/4244823 and enables asyncCommandBufferReset feature flag. It changes CommandQueue::checkCompletedCommands only do the check and update mLastCompletedSerials. It makes async command processor thread always call checkCompletedCommands if mNeedCommandsAndGarbageCleanup is true so that we can clean up more garbages. This CL also makes garbage clean up always done in async thread even if asyncCommandBufferReset is disabled. Bug: b/255411748 Change-Id: I1d63aa9f1f565d81780a39c29b919da3dd5a68be Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4264175 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Auto-Submit: Charlie Lao <cclao@google.com>
Charlie Lao 6d282d62 2023-02-08T16:51:07 Vulkan: Move retireFinishedCommands/garbageCleanup to worker thread This CL separate out the logic of mLastCompletedQueueSerial update and retireFinishedCommands and garbage clean up into different functions. At submission, previously we are always check fence and update mLastCompletedQueueSerials and calling reset on finished commands and do garbage clean up. With this CL, we only do the fence check and update mLastCompletedQueueSerials. Then it request worker thread to do the command buffer reset and garbage cleanup. We uses the CommandProcessor's thread for the reset and cleanup, since async submission path needs to handle this clean up anyway. This CL also added a new feature flag asyncCommandBufferReset and it is disabled right now. This will be enabled in the follow up CL. Bug: b/255411748 Change-Id: I6da558f8d4c962eb038e2378ccc76c464101cde2 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4244823 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Auto-Submit: Charlie Lao <cclao@google.com> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Charlie Lao e1dfc00a 2023-02-15T16:21:37 Vulkan: Make waitForPendingPresent drain work in the calling thread Since we are waiting, there is no point to have work done in CommandProcessor's worker thread. It can just wait and drain the task in the calling thread. This is consistent with waitForResourceUseToBeSubmitted. This allows us to remove mutex and condition variable from SwapchainStatus. Bug: b/269524271 Change-Id: I9d7e17c77c879b6957fc3b74aab02f7f5c9db052 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4257252 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Ian Elliott <ianelliott@google.com>
Charlie Lao 79bfee1c 2023-02-15T15:33:56 Vulkan: Clean up CommandProcessor::queuePresent Right now queuePresent API returns VkResult in two places, via return value and SwapchainStatus structure. This CL makes it only return via SwapchainStatus::lastPresentResult so that two code path are the same. Bug: b/269524271 Change-Id: I7ab3c2bee08961a10718a2e5daa1c7f03e97e85d Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4257927 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Ian Elliott <ianelliott@google.com>
Charlie Lao c402ea1c 2023-02-15T12:01:38 Vulkan: Rename hasUnfinishedUse to hasResourceUseFinished Most usage of hasUnfinishedUse is for !hasUnfinishedUse, and there was feedback that negative API is not preferred. This CL changes it to positive API name. Similarly renamed hasUnsubmittedUse to hasResourceUseSubmitted. Bug: b/267348918 Change-Id: Idb10b0f998ec50116ffb6aada19a98a516e87824 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4257105 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 5dba27e0 2023-02-15T10:24:38 Vulkan: CommandProcessor API name clean up This CL is mechanical change only and limited to CommandProcessor class. This CL renames submitCommands to enqueueSubmitCommands, queueSubmitOneOff to enqueueSubmitOneOffCommand, queuePresent to enqueuePresent, flushWaitSemaphores to enqueueFlushWaitSemaphores, flushOutsideRPCommands to enqueueFlushOutsideRPCommands, flushRenderPassCommands to enqueueFlushRenderPassCommands. This CL also renames CommandProcessor::mLastSubmittedSerial to mLastEnqueuedSerials, and getLastSubmittedSerial to getLastEnqueuedSerial, hasUnsubmittedUse to hasResourceUseEnqueued (opposite meaning). Bug: b/267348918 Change-Id: I611889815f5824837dc6e0f547e3cddc595d447b Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4255809 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao c4912744 2023-02-15T09:55:09 Vulkan: Clean up CommandProcessor mutex name This CL is mechanical change only and limited to CommandProcessor class. It renames mTasks to mTaskQueue, renames mWorkerMutex to mTaskEnqueueMutex, rename mSubmissionMutex to mTaskDequeueMutex. Bug: b/267348918 Change-Id: I7a8c6820eb3bd27d4e6aacb1abe7275f3c0ec5c5 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4255807 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Igor Nazarov f2617a09 2023-02-13T20:59:05 Vulkan: Minor fix when waitFor*ToBeSubmitted() may skip error. Calling "checkAndPopPendingError()" without "mSubmissionMutex" lock may cause situation, when new error is added to "mErrors" right after the call. This new error may be for the work we are waiting for, and it processing will be skipped. Current CommandProcessor error handing should be rewritten in the future anyway, but I think this minor error should be addressed now. Bug: b/267348918 Change-Id: I65c49f7dc8e1984696d464c38f13fcdce93337bf Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4245421 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Igor Nazarov 91d55479 2023-02-13T21:18:13 Vulkan: reverted back SuballocationGarbage logic. This commit: Vulkan: Switch CommandQueue::mInflightCommands to FixedQueue ad81cc95509379a213b9fddc6e7fe1cafc79115a changes how SuballocationGarbage is processed in the "submitCommands()" method. New logic allows clearing entire "mInFlightCommands" queue. In case if this change was intentional, it should also remove this text from the comment: // But if there is only one command buffer in flight, we do not wait // here to ensure we keep GPU busy. Bug: b/267682377 Change-Id: Ia280c468c79f45dd44791cff09887982094521e3 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4245422 Commit-Queue: Igor Nazarov <i.nazarov@samsung.com> Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Igor Nazarov aa1f7e19 2023-02-08T21:05:35 Vulkan: Fix CommandQueue Wait Semaphores asyncCommandQueue race. Recently implemented fix has a problem: When using "asyncCommandQueue", wait semaphores flush performed in the context thread, while submit in the async thread. Both operations protected by the mutex, so there is no data race or other UB. It is a potential performance problem: submit operation may attach wait semaphores prematurely, before corresponding commands flushed into the primary command buffer. Fix adds "CustomTask::FlushWaitSemaphores" to ensure wait semaphores and commands flushed in order. Bug: angleproject:7995 Change-Id: I7d3cfad867c59d3cd0a5c0bb3f81ae8d98238362 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4231844 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Charlie Lao b2cfe726 2023-02-07T14:35:24 Vulkan: Make queueSubmit without holding CommandQueue::mMutex VkQueueSubmit and VkQueuePresent could potentially take long. Right now it is called while holding CommandQueue::mMutex lock. In previous CL we moved mInFlightCommands to FixedQueue, which allows push/pop occur concurrently. This CL moves queueSubmit and queuePresent to not take mMutex but uses mSubmissionMutex. This allows other thread to checkCompletedCommands etc while we doing submit/present. The tricky part is that mPrimaryCommands is shared between all contexts. It can contain commands from different contexts, thus the vkQueueSubmit ordering must strictly follow the order of RendererVk::submitCommands() call. The mMutex and mQueueSubmitMutex are managed in a way that does the lock relay so that we always have a lock covering the submitCommands call all the way to vkQueueSubmit. Bug: b/267682377 Change-Id: Ic556cd4c64d334ad1cfc68942b803e401c6b0cc1 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4218198 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 5d97cbd1 2023-02-07T12:54:26 Vulkan: Move post submit code into a separate function This CL is mostly a clean up and refactoring and prepare for next CL. No actual functionality change is expected. It added a new function for the post queueSubmit logic. It moves CommandQueue::queueSubmit() into the same location as queuePresent. Bug: b/267682377 Change-Id: I240934dc4db06ce1277955938427a9e257211277 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4226006 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Igor Nazarov 7da34485 2023-01-17T16:17:51 Vulkan: Changed "asyncCommandQueue" Pending Present info logic. Required for future commits. Details: - Fixes possible stale result in "CommandProcessor::mSwapchainStatus" after WindowSurfaceVk destruction. - Fixes possible dead-lock when the old "getLastPresentResult()" method might be called more than once. - New implementation allows waiting multiple times (and multiple threads) for the same Present result. Before commit: 31c4093651079775acf34ea1bb06bdabb4ea4386 Vulkan: Rework present semaphore recycling There was assert in CTS: dEQP-EGL.functional.swap_buffers_with_damage.resize_before_swap.* Assert failed in ~SwapchainCleanupData (../../src/libANGLE/renderer/vulkan/SurfaceVk.cpp:669): swapchain == VK_NULL_HANDLE Because of the stale "CommandProcessor::mSwapchainStatus" and a race-condition as the result. The "Vulkan: Rework present semaphore recycling" did not fix the problem, but rather changed undefined behavior symptom. Bug: None Change-Id: Idf08a29265a43c711941b142001eb4380e2aa2b6 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4194184 Commit-Queue: Igor Nazarov <i.nazarov@samsung.com> Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Igor Nazarov 8b9bd182 2023-02-08T16:17:10 Vulkan: Refactoring to use ProtectionType enum instead of bool This is a second stage of refactoring that was started here: Vulkan: Minor CommandQueue implementation refactoring. 0210b46d35b51ea04bddafb48ba406a87c39e58e Enumeration renamed: CommandContent -> ProtectionType. Currently interfaces of ContextVk/RendererVk/CommandQueue use "hasProtectedContent" boolean. Internally CommandQueue uses "vk::ProtectionType" enumeration to separate states related to Unprotected/Protected commands. This CL replaces boolean with enumeration for consistency. Bug: angleproject:7995 Change-Id: Ibb98cce661358d464be7c6a8367a1297d7093b1c Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4232114 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Igor Nazarov b6cc5754 2023-01-17T16:17:22 Vulkan: Fixed Wait Semaphores problems. This feature fixes 2 problems. 1. Swapchain Image Acquire Semaphore added to wait list AFTER rendering commands: - Make Window Surface current. - Clear Window Surface (Image is Acquired). - Perform rendering to the Window Surface. - Change to other Surface (for example: PbufferSurface) using the same Context. - Unmake Context from current to ensure commands are submitted. - Rendering commands to the Window Surface will be submitted without Acquire Semaphore. 2. Context from other thread may submit command of another Context without proper Wait Semaphores: - Make Window Surface current in the first context. - Clear Window Surface (Image is Acquired). - Perform rendering to the Window Surface. - Call "glBeginQuery()/glEndQuery()" (or other commands) - this will flush command to the Primary Command Buffer without submitting. - In other Thread and Context make some Surface current (for example: PbufferSurface). - Clear that surface with scissor and unmake Context from current to ensure commands are submitted. - Rendering commands to the Window Surface from the first Context will be submitted without Acquire Semaphore. - Problem will happen even if add Wait Semaphore BEFORE writing rendering commands. Bug: angleproject:7995 Test: angle_end2end_tests --gtest_filter="EGLSurfaceTest.WaitSemaphoreAddedAfterCommands*" Test: angle_end2end_tests --gtest_filter="EGLSurfaceTest.CommandsSubmittedWithoutWaitSemaphore*" Change-Id: I28174ff98fdd09b4117962fc0810cfeeb2a4d1f1 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4194182 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com>
Shahbaz Youssefi b3846714 2022-11-28T11:05:05 Vulkan: Feature to make async queue slow for testing Bug: angleproject:6746 Change-Id: I2573cae2dcf42d177168c55bc2a6d8bb012dde18 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4227986 Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com>
Shahbaz Youssefi 28da0a3e 2022-11-28T14:43:10 Vulkan: Avoid swapchain recreation on present mode change Bug: angleproject:7878 Change-Id: I5a36c206dc8feb640fc684f92c10c26628633601 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4088907 Reviewed-by: Ian Elliott <ianelliott@google.com> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jeff Vigil <j.vigil@samsung.com>
Charlie Lao ad81cc95 2023-02-01T16:23:02 Vulkan: Switch CommandQueue::mInflightCommands to FixedQueue mInflightCommands has a limit of size. With std::dequeue, we may end up resize the storage which means moving elements around. This CL switches it to use angle::FixedQueue. This also allows us to make calls to CommandQueue like checkCompletedCommands while other context doing queueSubmit/queuePresent in the future CLs. Bug: b/267682377 Change-Id: Id29641d37929328d00c5b52c019eea34f7189d0c Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4214507 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Charlie Lao 11951f2f 2023-01-31T09:56:16 Vulkan: Add FixedQueue class for CommandProcessor::mTask This CL adds FixedQueue class. It uses std::array for the storage. It supports concurrent push and pop from two different threads. If producer want to push from two different threads, then proper mutex must be used to ensure the access is serialized. Similarly if consumers want to pop from two different threads, a mutex must be used to ensure serialized access. Caller must ensure queue is not empty before pop and not full before push. This CL switches CommandProcessor::mTasks to FixedQueue and moved mSubmissionMutex to protect the serialized submission (i.e, pop from queue). mWorkerMutex is still used to protect push operation. With this change, we now supports continued enqueue to mTask of CommandProcessor while other context is doing CommandProcessor::waitForResourceUseToBeSubmitted(). Bug: b/267348918 Change-Id: I6c5fe288436daa7e0f3bcbbcd16c5d2e5e27f2e9 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4210653 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao b930cdbf 2023-01-31T12:27:42 Vulkan: Make CommandProcessor only wait for required work CommandProcessor::waitForResourceUseToBeSubmitted() is waiting for all works in the mTasks to be submitted. This CL makes it only wait until the requested ResourceUse has been submitted to vulkan. The reason waitForResourceUseToBeSubmitted is currently waiting for all mTasks to empty is because submission can only occur in worker thread. In this CL, this has been changed so that submission can come from any thread. In the case of waitForResourceUseToBeSubmitted, since we are waiting, we could rather just drain the mTasks in the calling thread. This avoid thread hoping, and more importantly, able to get rid of the idle conditional variables and make code simpler. Bug: b/267348918 Change-Id: Ia55dc4bc93925cf926aad5b53936cbc42036ac38 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4210650 Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Igor Nazarov 0210b46d 2023-02-01T14:01:59 Vulkan: Minor CommandQueue implementation refactoring. This is a preparation for the follow-up wait semaphore bug fix. Bug: angleproject:7995 Change-Id: Ie509366d5bbb73b32ba6c0e6a0ac8357c450fbbc Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4215391 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Igor Nazarov 786d237f 2023-01-26T22:24:03 Vulkan: Fixed bug in rx::vk::SharedFence with repeated init(). Bug: b/261106868 Test: angle_white_box_tests VulkanSharedFenceTest* Change-Id: I1e657a52332b2166f05841f91747b1bfec1504e7 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4194177 Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao 53b65950 2023-01-27T13:17:13 Vulkan: Fold ThreadSafeCommandProcessor back to CommandProcessor In earlier CL crrev.com/c/4156637, I added ThreadSafeCommandProcessor to wrap CommandProcessor public APIs with a mutex lock. This CL folds ThreadSafeCommandProcessor back into CommandProcessor so that we only have one class to deal with. CommandProcessor itself is thread safe already, we really do not need mutex for that. The only place that might still need the mutex in ThreadSafeCommandProcessor is that while we wait for mTasks to become empty, previously the lock in ThreadSafeCommandProcessor will block context from submitting new work to mTasks. In order to keep that behavior, mSubmissionMutex is added just for this purpose. Bug: b/266605181 Change-Id: If8844a3000712bf4fcf89a4f8098b7a745a30e99 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4198480 Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 0cdecfad 2023-01-27T10:38:31 Vulkan: Merge ThreadSafeCommandQueue back into CommandQueue In earlier CL crrev.com/c/4156637, I added ThreadSafeCommandQueue to wrap CommandQueue public APIs with a mutex lock. Then in the following CLs we have switched CommandProcessor and RendererVk to use ThreadSafeCommandQueue. Now CommandQueue class is only been used by ThreadSafeCommandQueue. This CL folds ThreadSafeCommandQueue back into CommandQueue so that we only have one CommandQueue class to deal with. This CL groups the CommandQueue's public and private APIs into separate groups. Bug: b/266605181 Change-Id: I94c6c949e0ed14583c38284a216f7a3e2010e98d Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4118856 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 54f44639 2023-01-17T13:07:57 Vulkan: Make RendererVk only have one CommandQueue object Right now RendererVk have two CommandQueue objects: one owned by RendererVk (used for synchronous submission) and another owned by CommandProcessor (used for async submission). Since async submission is a feature flag that will never change once RendererVk initialized, we are only using one CommandQueue. This CL changes CommandProcessor's mCommandQueue to a pointer that points to RendererVk::mCommandQueue. The added benefit of this is that it allows me to remove bunch of CommandQueue property query APIs from CommandProcessor since these property has nothing to do with "command". CommandProcessor class is actually reduced to command processing. Bug: b/266605181 Change-Id: I1f33db14ee29e2c0aa7850de98b2d7c3823126b6 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4174874 Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 226fd666 2023-01-20T10:26:34 Vulkan: Make CommandProcessor::checkCompletedCommands immediate check This checkCompletedCommands() method is trying to do immediate mLastCompletedSerials update. For async command submission, there is no point to insert a token for CommandProcessor::checkCompletedCommands since it is not waiting for all queued commands to be submitted. And even worse, for async submission, it is also not doing immedidate queue serial update. For example, SyncHelper::getStatus() we do call checkCompletedCommands to ensure the queue serials are up to date, but with async submisison, this has no immediate effect, which may cause test like FenceNVTest.BasicOperations/ES3_Vulkan_AsyncCommandQueue to fail because queue serial is not kept up to date even though we did wait for fence to finish. This CL removes CustomTask::CheckCompletedCommands token and just calls mCommandQueue.checkCompletedCommands() immediately. This CL only affects asynchronous command submission code path. Bug: b/266220198 Bug: angleproject:7884 Change-Id: I3226bc9b337b516e28695008295358d00103eeb9 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4174876 Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 9edc4686 2023-01-26T09:26:41 Vulkan: Fix SharedFence::mRefCountedFence leak This was introduced in crrev.com/c/4159871. mRefCountedFence itself is not been properly deleted. Bug: b/261106868 Change-Id: I91b620d96064cc0a8a155327336881d26a5bc33b Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4198475 Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Commit-Queue: Charlie Lao <cclao@google.com> Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com> Auto-Submit: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 00b94fda 2023-01-17T11:12:14 Vulkan: CommandProcessor::WaitForWorkComplete only if needed When async command queue enabled, there is another queue (mTask) in CommandProcessor object. When we wait for a queueSerial to finish, right now we always flush everything from CommandProcessor (i.e, wait until mTask is empty), even though the work in mTask is unrelated to this queueSerial that waiting for. With the work of previous CLs, now we can actually wait for mTask to empty only if there is still pending submission of queueSerial. This CL also renames ComandProcessor::ensureNoPendingWork to waitForQueueSerialToBeSubmitted to reflect what it does (it does not wait for GPU to finish). Bug: b/261098465 Change-Id: I0114dadd86a84f75bf8b71735f0adc0dbb9b6bf2 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4174873 Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao 1d9984bd 2023-01-12T16:56:02 Vulkan: Make CommandProcessor use ThreadSafeCommandQueue This CL switches CommandProcessor's mCommandQueue to ThreadSafeCommandQueue. This allows us to utilize ThreadSafeCommandQueue implementation of wait for GPU to finish while CommandProcessor's async submission thread continue to submit. By doing this, CommandQueue is only used by ThreadSafeCommandQueue, thus some public APIs can now removed. This CL also implements wait APIs of ThreadSafeCommandProcessor directly and remove these APIs from CommandProcessor class. Bug: b/261106868 Change-Id: I8c2e1de95a37fab21b7018db484976c447f1dcad Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4163743 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Charlie Lao 6a5e61cd 2023-01-11T16:49:52 Vulkan: Make ThreadSafeCommandQueue's wait without lock This CL makes all wait functions in ThreadSafeCommandQueue class to wait without holding the lock, so that other contexts can still submitting commands or make calls into CommandQueue. To make this work, Shared<Fence> has been refactored into SharedFence class which is RAII and manages refcounted VkFence object. It's copy constructor simply adds a reference to the underline fence object, so that the local copy of a SharedFence object guarantees underline vkfence will remain valid. RAII makes sure that local copy of SharedFence will not leak refcount. The ThreadSafeCommandQueue wait functions makes a local copy of SharedFence so that it can unlock and wait and then relock. This CL also adds a new test for this: EGLMultiContextTest.ThreadBCanSubmitWhileThreadAWaiting Bug: b/261106868 Change-Id: I96ecfa1d9f7a3dc646ff2287d789313a9f8fb75d Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4159871 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Shahbaz Youssefi ffbb65bc 2022-11-28T13:31:48 Vulkan: Use VK_EXT_swapchain_maintenance1 for present fences Bug: angleproject:7878 Change-Id: Ic3a43c663789a6489cff261848d9ad4a408ca53a Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4088905 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Ian Elliott <ianelliott@google.com>
Charlie Lao d6dea33b 2022-12-19T13:39:34 Vulkan: Remove CommandQueue::mGarbageQueue With recent work of per active context queue serial, mGarbageQueue behaves almost identical to normal mSharedGarbage now. This CL removed mGarbageQueue and added garbage into Remove mSharedGarbage instead. Bug: b/263166501 Change-Id: I6bce47b4535283e7bd0f0c8823b9629cc25f9d94 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4117712 Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao a703eea4 2022-12-09T15:55:03 Vulkan: Remove Serial::valid() check QueueSerial right now checks if serial is valid or not in various comparison. This CL removes valid() method from class Serial and rely on the fact that default constructor always constructs kZeroSerial and kZeroSerial is always smaller than any serial, i.e, always appears as flushed, submitted and completed. This removes one branch from critical code path where we try to detect if a buffer/image is used by a renderpass or not etc. Bug: b/262047600 Change-Id: Ic76fe1409d9911dc7eb86107c9a930d8bb5eaa05 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4089848 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Commit-Queue: Charlie Lao <cclao@google.com>
Amirali Abdolrashidi 684ff60b 2022-06-21T10:52:31 Vulkan: Add shared ring buffer cmd alloc feature * Added RingBufferAllocator.cpp with implementation. * Main classes: * RingBufferAllocator (fast allocation with bulk deallocation) * SharedRingBufferAllocator (wrapper to help with shared use and multiple threads) * Implemented "angle_enable_vulkan_shared_ring_buffer_cmd_alloc" feature. (Disabled by default) * Details (from the original CL) * The angle::PoolAllocator replaced with angle::RingBufferAllocator. * Before, there was separate angle::PoolAllocator per each CommandBufferHelper. Now, a single angle::RingBufferAllocator is shared between multiple CommandBufferHelper objects. * Commands data from multiple CommandBufferHelpers is tightly packed without fragmentation. * Significantly less memory overhead, observed with enabled async queue. * Moved the parts of the code related to the allocators into the classes in the new AllocatorHelperPool and AllocatorHelperRing files for better management. The allocator can be switched by changing the following BUILD flag: `angle_enable_vulkan_shared_ring_buffer_cmd_alloc` * It is connected to the following macro: ANGLE_ENABLE_VULKAN_SHARED_RING_BUFFER_CMD_ALLOC * The two main allocator classes in each file are aliased as: * SecondaryCommandBlockAllocator (in CommandBufferHelper objects) * SecondaryCommandBlockPool (in SecondaryCommandBuffer) * Also added placeholder functions for VulkanSecondaryCommandBuffer. * Added descriptions regarding the two allocators. * renderer/vulkan/doc/Allocators.md Credit: Original CL authored by Igor Nazarov <i.nazarov@samsung.com> Bug: angleproject:6401 Bug: b/256666069 Change-Id: I0f24793eef6334bf4ff8e327b9665338807dad37 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3715968 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Charlie Lao f4e64938 2022-12-07T13:01:15 Vulkan: Remove CommandQueue::mQueueSerialMutex This mutex lock is no longer used and needed, thus removed in this CL. Also removed unused BufferAccess enum class. Bug: b/261737134 Change-Id: I7391e84c5b2abcd87de6ce9e66ba85f81ff7dce3 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4086934 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 7e378da9 2022-12-01T16:36:08 Vulkan: Remove synchronous commands from CommandProcessor Some command tokens in CommandProcessor are doing synchronous calls. For example, finishResourceUse() and waitIdle(). They are inserting a token and then wait for CommandProcessor to drain. This CL removes these commands from CommandProcessor and it just ask CommandProcessor to drain and then call into mCommandQueue to finishResourceUse or waitIdle. This is a minor clean up for now, but in future CL we will also avoid waitForWorkComplete if the mUse has already been drained from CommandProcessor. Bug: b/261098465 Change-Id: I7672a9c0b1e477ea3537652cd83350aa97f7caa7 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4072223 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Charlie Lao ca263d4a 2022-11-23T12:11:49 Vulkan: Remove UsedInRunningCommands The only difference of UsedInRunningCommands() and hasUnfinishedUse() is the latter excludes the case where it has not submitted yet. But all usages are already checked if it has been submitted or not. This CL removes UsedInRunningCommands and uses hasUnfinishedUse instead. Bug: b/255414841 Change-Id: I94ef0b63a0c888219cffcdfcecfa0a095fee616b Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4053262 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao 2d87551d 2022-12-05T10:47:40 Vulkan: Make mLargestAllocatedIndex atomic TSAN is complaining mLargestAllocatedIndex not thread safe. This CL makes it atomic and make it mean " the largest queue index we have ever allocated/seen" so that it will be thread safe. It is impossible to use a queueIndex before it been allocated. But it is still possible that some mUse still referencing a queueIndex after it is been released. The only downside is that we may get into slightly less optimal code path for GetBatchCountUpToSerials if we ever get into more than 64 queueIndex and then get bellow 64 again, but that should not a real concern. Bug: angleproject:7860 Change-Id: I4c99bae24e9d72298253e43f8d108444a8f46ebc Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4080590 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 2e5ca217 2022-11-18T10:44:49 Vulkan: Let each current context has its own QueueSerial. This CL makes every current context has its own queueSerial. At context creation time or when context becomes current, it allocates a QueueIndex from renderer. When it becomes non-current, it releases QueueIndex for others to reuse. This way we significantly reduces the max number of QueueIndexs for reasonable usage. Each CommandBuffer has its own unique QueueSerial and we use that to determine if a resource is being used by the given CommandBuffer. The QueueSerial for RenderPassCommands is deferred until renderPass starts, and when we generate queueSerial for renderPassCommands, we also reserve a range of serials for outsideRenderPassCommands so that we can do incremental submission of outsideRenderPassCommands without need to close renderPassCommands. In rare situation, if that reserved serials runs out, we also close renderPassCommands to ensure the ordering of serials matches ordering of command buffers. With per current context queue serial, this CL is able to set resource queue serial as it is being used. This CL completely removes usage of ResourceUseList class since it was introduced due to deferred setSerial. This CL also get rid of refCount from ResourceUse since there we no longer add it to a ResourceUseList. With that, we also able to remove SharedResourceUse class since access to ResourceUse itself is now thread safe since we are able to make a copy of it when we add it to GarbageList. Because RenderPassCommands now has its own unique QueueSerial as it encodes command, we can use it to detect if a resource is being used by it or not, thus this CL also removes usage of CommandBufferID. Bug: b/255414841 Change-Id: I36dcbeaa7bc996f04e6c04bf9ad44cd0d630f61a Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4038096 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Shahbaz Youssefi 90b4541c 2022-11-28T11:39:24 Vulkan: Pass signal semaphore by value to async thread Otherwise the signal semaphore is pointing to whatever was passed in from the main thread. Currently, this is ok because: - For external semaphores, ensureNoPendingWork is called - For surfaces, there's a fixed buffer of semaphores However, an upcoming change passes a semaphore specified on the stack, and the thread should not be referencing it. Bug: angleproject:7847 Change-Id: I9a823214bde59b9d7ff23313694c1749a76e6b8e Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4060453 Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Charlie Lao 000b3bfa 2022-11-28T15:06:06 Vulkan: Init mLast***Serials from CommandQueue::initialize Exposed by a recent test from Jason crrev.com/cl/4035646, If RendererVk gets re-initialized, we can't rely on CommandQueue's constructor to do initalization. We have to manually initialize mLastSubmittedSerials to 0 since destroy will set it to Infinite. Bug: b/249457381 Change-Id: I90e654981fb821324cbfb177712f604b67ccc70c Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4063046 Reviewed-by: Jason Macnak <natsu@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 6458178e 2022-11-18T11:39:16 Vulkan: Clean up flushCommandsAndEndRenderPass APIs ContextVk::flushCommandsAndEndRenderPassWithoutQueueSubmit is calling flushCommandsAndEndRenderPassImpl(QueueSubmitType::SkipQueueSubmit). This is a bit odd and creates confusion and trouble with future CLs. This CL removes QueueSubmitType and straight up the submission code and removes some function that was doing little but to call another function. Bug: b/255414841 Change-Id: I0ed2122a98b0fc5b819fd331173bf6945d23ff8a Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4038095 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 7dd8478e 2022-11-17T10:11:02 Vulkan: Make ResourceUse::serial an FastVector of Serials In preparation for per context queue serial, this CL makes ResourceUse::serial a FastVector of Serial. Right now we still limited to one serial index so that it still work the same way as before. This CL adds necessary data type and change the function names to reflect that tracking GPU progress needs a ResourceUse object instead of a single Serial number. Bug: b/255414841 Change-Id: Ic60cdf5ec8da45d1821f65a55947f5c553f65737 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4034548 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao 8378032e 2022-11-15T11:47:55 Vulkan: Remove get API for mLastCompletedQueueSerial In preparation for per context queue serial, this CL makes mLastSubmittedQueueSerial and mLastCompletedQueueSerial private to CommandQueue. Before this CL, we have a get function to return the last submitted serial and last completed serial and passing these serials around. This works because the serial is a single uint64_t number. With per context queue serial, this will be an array of serials and there is potential risk associated with access it from different threads. This CL makes these serials private to CommandQueue and when you want to know if GPU is completed with resource, you ask RendererVk/CommandQueue directly. This way we can ensure they have thread safe access in the CommandQueue (no lock is necessary, but all access will be restricted to one class). Bug: b/255414841 Change-Id: Ica565decce4a80588e0b447e179a2b634b55d7c3 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4021676 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao 8028bffc 2022-11-14T16:45:07 Vulkan: Flatten GarbageAndSerial class ObjectAndSerial templated class is only used by GarbageAndSerial. The serial number here means queue serial. This CL simply flattens the template class to GarbageAndQueueSerial to clarify the serial here is the queue serial that tracks GPU completion. Bug: b/259148812 Change-Id: I81e88a03ccffcf8fb632e3ac7dce886375dc51a5 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4023098 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 9483002d 2022-11-14T16:01:15 Vulkan: Clean up submitFrame/submitCommands ContextVK has two functions, submitFrame, and submitCommands. ContextVk::SubmitFrame means to be frame boundary or FBO boundary, usually refers to submission triggered by API, for example, glFlush/glFinish or FBO switches. ContextVk::submitCommands was added later to mean any kind of submission. It could be triggered by internal logic, for example, when we think we have accumulated too much staged updates. The odd thing is that ContextVk::submitFrame calls ContextVk::submitCommands, which calls RendererVk::submitFrame. I believe this is because when we introduced ContextVk::submitCommands, we did not bother rename RendererVk's API. This CL renames RendererVk::submitFrame and CommandQueue::submitFrame and CommandProcessor::submitFrame to submitCommands to be consistent with ContextVk's function names. This CL also removes unused function ContextVk::isSerialInUse() This CL also removes unnecessary vk:: namespace in CommandProcessor Bug: b/259148812 Change-Id: If074e381168950143ad56a728f23caa298e5f355 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4027284 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Shahbaz Youssefi fbd7d5fa 2022-10-17T17:20:09 Move thread pool classes to common/ In preparation for access by image_util files. Bug: b/250688943 Change-Id: I24777269a5071eae9a60f939635d01ed7246461f Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3961454 Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi d4e54b81 2022-07-17T22:56:51 Vulkan: Clean up garbage of last completed submission too Due to an off-by-one error, the garbage of the very last completed submission was not actually cleaned up. Bug: b/172704839 Change-Id: I4fb6a77af4379568990853e4bf3fd945fcde657c Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3769547 Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Eddie Hatfield 91976352 2022-06-21T15:41:02 Use C++17 attributes instead of custom macros Bug: angleproject:6747 Change-Id: Iad6c7cd8a18d028e01da49b647c5d01af11e0522 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3718999 Reviewed-by: Cody Northrop <cnorthrop@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Peng Huang bedb3075 2022-05-16T09:46:11 Do not call RendererVK::handleDeviceLost() for device lost RendererVK::handleDeviceLost() need to hold the mCommandQueueMutex for releasing some resources. For some cases, Locking mCommandQueueMutex may cause deadlock, because the same lock has been acquired by the same thread. Fix the problem by not calling RendererVK::handleDeviceLost() for device lost. It is OK, because RendererVK::onDestroy() will call handleDeviceLost() if the device is lost already. Bug: chromium:1273643 Change-Id: Iaaa77bdf429b703363d4155323b91baf5947d95e Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3644641 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 333da2cf 2022-05-03T16:21:41 Vulkan: Limit the total bytes of suballocation garbages in flight This CL tracks the total number of bytes of suballocation garbage. It checks against the limit so that when there are excessive garbages in flight, we will wait for GPU to finish and free up some of these memory before continue. That way we will ensure we do not end up accumulating too much memory and end up with low memory kill on mobile devices. Bug: b/230538246 Change-Id: Ic8292db5617bcee4ec3abe8632f54edfd249cfaa Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3617226 Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 51dc3c3e 2022-05-02T18:11:26 Vulkan: Force prune when there are lots of suballocations destroyed If there are a lot of suballocations destroyed, there is bigger chance that some buffers become empty and we might able to trim down excessive empty buffers. This CL tracks the suballocations destroyed at each cleanupGarbage call and use that information to force immediate pruneEmptyBuffers call. Bug: b/230538246 Change-Id: Icca2ea731639545c635c09d58a8606d67405e1a6 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3620981 Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao 4d26c66d 2022-04-29T17:39:22 Vulkan: Call cleanupGarbage only if mLastCompletedQueueSerial changed RendererVk::cleanupGarbage() walks through all garbage objects and check its serial with mLastCompletedQueueSerial. If it is completed then garbage gets destroyed. Right now it gets called from CommandQueue::queueSubmit(). But queueSubmit only submit new work, it does not mean anything have completed. Garbage clean up does not depend on submission, but depends on anything have finished. This CL moves the cleanupGarbage call to CommandQueue::retireFinishedCommands() where we update mLastCompletedQueueSerial. Bug: b/230921364 Change-Id: Ib07c4cc75a1d2bd243377fa1215588d8ea4e3f36 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3617227 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Charlie Lao 394fb0d3 2022-04-26T17:17:58 Vulkan: Don't take lock for getLastCompletedQueueSerial getLastCompletedQueueSerial() is simply returning a uint64_t serial number. There is no need to take a mutex lock. This CL uses atomic for mLastCompletedQueueSerial and removed the lock as well as removed the virtual function call. This also avoid the annoyance with mutex lock, that if you call getLastCompletedQueueSerial in places that has other lock held, you may end up with deadlock. This CL avoids that trouble all together other than improves performance. Bug: b/230759914 Change-Id: I9dc688d410e4c6bca7fc70ae4f9fe0c3acc2e005 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3607500 Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Shahbaz Youssefi 266111a5 2022-04-22T21:52:19 Vulkan: Fix SemaphoreCount best practice warning Bug: angleproject:7231 Change-Id: Ifd02084887aca44aade96474a45f3060b276226e Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3603701 Reviewed-by: Ian Elliott <ianelliott@google.com> Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 4aae5815 2022-04-22T13:21:03 Vulkan: Overlay widgets for submission statistics Bug: angleproject:7084 Change-Id: I68e69bda43862f9f2711c25a28dbe4745c19a45c Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3602832 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 2db718ed 2022-04-21T23:13:02 Vulkan: Skip empty submissions A number of places in ANGLE perform an implicit flush; eglSwapBuffers(), glFenceSync() etc. Sometimes these flushes are unnecessary because there is nothing to submit. Additionally, an application may unnecessarily issue glFlush() with nothing recorded. In this change, empty command buffers are automatically not submitted, optimizing these unnecessary flushes away. Bug: angleproject:7084 Change-Id: Iecb865b6b9ef8045dfecda7b5221874f7031b42e Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3600837 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 36e142c1 2022-03-25T12:10:17 Vulkan: Fix deadlock in device loss When the device is lost, the commands queue is cleaned up. This shouldn't be done immediately if the device loss is generated from the command queue itself (due to mutual exclusion requirements). For example, CommandQueue::checkCompletedCommands() loops over mInFlightCommands, whose body contains ANGLE_VK_TRY. On device loss, that macro invokes CommandQueue::handleDeviceLost which clears mInFlightCommands. In this change, handleDeviceLost() defers device loss handling if the mutex is already taken. A new class is added, ScopedCommandQueueLock, that handles device loss at the end of the scope (i.e. when the command queue operation is finished) by calling handleDeviceLostNoLock() before releasing the lock. Bug: chromium:1304907 Bug: angleproject:7129 Change-Id: Ifb67cfdad9595cec51a6a58b69f629aede489725 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3552088 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Peng Huang <penghuang@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao df19e35a 2022-01-24T17:47:58 Vulkan: Use queue for mGarbageQueue This variable is also acting exactly like queue as the name implies. This CL changes from vector to queue so that the very last erase() call will not actually move anything. Bug: b/215768827 Change-Id: Ieb39c3a1b3acb25f93bcda2a46737a6d009d71f0 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3414355 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Shahbaz Youssefi acd8fc76 2021-12-16T01:05:02 Vulkan: Distinguish RP and outside-RP command buffer types What goes inside and outside a render pass command buffer is largely mutually exclusive. Moreover, the size and frequency of allocations is different between the two. This change distinguishes the C++ types used for inside and outside render pass command buffers: - The type now documents which command buffer a function is able to receive. - `isRenderPass` flag passing, checking and asserting is largely removed. - A follow up change experiments with using different (Vulkan vs ANGLE) secondary command buffers for inside and outside RP command buffers. - A future change could specialize the pool behaviors per command buffer type. Bug: angleproject:6811 Change-Id: Ia4bc669d26ac7e94e8a0dfb9b361666c82f42cc3 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3344373 Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Jamie Madill f40e83cb 2021-09-10T19:15:17 Reduced "rx::vk::kInFlightCommandsLimit" from "100" to "50". The "100" value is too high and causes "S21 Adreno" block in "vkQueueSubmit()". This is a temp solution. Patch authored by Igor Nazarov <i.nazarov@samsung.com> Bug: angleproject:6401 Change-Id: Ie7f9c8ef5311b17325640cae0f613ece768c0fa3 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3165666 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Shahbaz Youssefi 3128c055 2021-11-12T14:59:46 Vulkan: Add wait semaphores to queueSubmitOneOff For use in follow up change. Bug: angleproject:3966 Change-Id: I5bfac51ef9d47a6df5d52268d3ce4863b848b1d1 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3279226 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Lingfeng Yang <lfy@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Jamie Madill 191c236a 2021-10-14T17:01:45 Vulkan: Remove "current queue serial". Queries, semaphores, and pipelines instead use the normal vk::Resource design to track their lifetimes. Removes the current serial APIs from all classes. Current serials are still tracked internally in the command queue classes. Bug: b/169788986 Change-Id: Idcd2c2a93bc8225c6f3f7c247eb8fcfb76be1030 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3223644 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Shahbaz Youssefi 48b605d8 2021-10-25T09:46:16 Vulkan: Fix UBSAN error in CommandBatch CommandBatch doesn't initialize all fields, causing UBSAN errors in the move constructor. Bug: chromium:1261861 Change-Id: I46b963a415ccc08d3d9db40de98d1968eea311e8 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3241544 Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 4bb0a7af 2021-10-18T12:14:04 Vulkan: Async Queue: Fix signal of external semaphores Per the Vulkan spec: > ... when a semaphore wait operation is submitted to a queue: > > - A binary semaphore must be signaled, or have an associated semaphore > signal operation that is pending execution. It is incorrect for ANGLE to defer the submission that signals an external semaphore, because then it's impossible for the application to know when it can wait on the semaphore. Bug: angleproject:6574 Bug: b/172704839 Change-Id: I5469b500b2f7d402acec31d9848585a9947843c6 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3226308 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Jamie Madill 123ba58d 2021-10-14T11:56:35 Vulkan: Remove "last submitted serial". This fixes race conditions with the async command processor. Instead of querying specific serial numbers, we ask the command queue to either wait for idle, or return the answer to "are you busy" directly. Bug: b/172704839 Change-Id: I06a8268d9b58d8c33b783af00ca74979ee158316 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3223641 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 2f1d503b 2021-09-16T21:49:14 Vulkan: Fix Vulkan secondary command buffers This change abstracts initialization, begin/end, reset and recycle of command buffers such that both Vulkan and ANGLE secondary command buffers are supported. Bug: angleproject:6100 Change-Id: I8c79764ac98b599fda08fe45cf8c4f0a6573f0f9 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2987873 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 4cb34637 2021-09-29T16:40:11 Vulkan: Fix crash in async queue The change also fixes a regression introduced by 2d79918fdb0276cdb57488d72abd803250f962a3 which caused a segfault when async queue is used. Unfortunately, due to anglebug.com/6437, async queue tests are not run on the bots at the moment. This will be fixed in a follow up change. Bug: angleproject:6436 Change-Id: I3c2f63549149fbd9c9ab61107e98e8015cdb1c77 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3193419 Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
kmx.io     mail     discord kmxgit v0.4.0