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

src/libANGLE/renderer/vulkan/CommandProcessor.h

Log

Author Commit Date CI Message
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>
Shahbaz Youssefi 144f2d2c 2023-04-24T12:52:27 Vulkan: Use thread-local space for EGL errors The assumption in anglebug.com/3041 that ANGLE is "single-threaded anyway" no longer holds. Bug: angleproject:3041 Change-Id: I613395c8003cad60764362d2776aaf7b6804b788 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4468107 Reviewed-by: Igor Nazarov <i.nazarov@samsung.com> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
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>
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 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 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 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>
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 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>
Charlie Lao 77d19e39 2023-01-11T14:03:18 Vulkan: Add ThreadSafeCommandQueue class This is preparation CL for the next few CLs. Instead of having RendererVk owns mCommandQueueMutex and takes lock before calling CommandQueue APIs, this CL creates a ThreadSafeCommandQueue wrapper class that wraps CommandQueue class' public APIs with a mMutex. Right now this is purely a mechanical change, expecting no real functional or behavior differences. But in the future CLs, we are going to implement some APIs without holding lock while doing the wait. This also conceptually cleaner that a mutex lock should protect data not methods. Because of this, this CL also adds OneOffCommandPool class to wrap around all oneoff command buffers with its own lock. The same change also applied to CommandProcessor class by adding a ThreadSafeCommandProcessor class (this will be removed in later CLs). This CL also removes CommandQueueInterface base class and made all these virtual functions no longer virtual, thus reduces the overhead associate with calling virtual functions. Bug: b/261106868 Change-Id: Ifdc0085cef7f00d840b4ef3fa602172fed3c0fb1 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4156637 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Commit-Queue: Charlie Lao <cclao@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 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 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 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 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>
Sungyong Choi c6390143 2022-10-12T09:57:55 Vulkan: Make compatible with GCC Resolves below warnings occurred with GCC build. 1) deperecated-copy Overriding an assignment operator without a copy constructor caused the deprecated-copy warnings. 2) unused-function 3) parenthesis Warnings occurred due to missing parenthesis around some logical expressions, add them to quiet the warnings. 4) unused variable 5) 'maybe-unused' attribute ignored Introduces 'ANGLE_MAYBE_UNUSED_PRIVATE_FIELD' macro to avoid 'attribute ignored' warning which is only occurred with GCC because GCC doesn't warn about 'unused non static data member' whereas Clang has Wno-unused-private-field. Signed-off-by: Sungyong Choi <sywow.choi@samsung.com> Bug: angleproject:7764 Change-Id: I8e7410a5ed8cb9b8f8b3202073d779fea63d6b75 Reviewed-by: Jeff Vigil <j.vigil@samsung.com> Reviewed-by: Mohan Maiya <m.maiya@samsung.com> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3963830 Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Jamie Madill <jmadill@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 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 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>
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>
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>
Peng Huang 81d964a1 2021-10-28T10:50:51 vulkan: implement EGLDevice for vulkan backend It allows ANGLE clients to get and use VkDevice and VkQueue used by vulkan backend. Bug: chromium:1264439 Change-Id: I338ac08152cfec50bb34c5025730e5e6368efba9 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3250964 Reviewed-by: Peng Huang <penghuang@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Geoff Lang <geofflang@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Peng Huang <penghuang@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 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>
Shahbaz Youssefi 2d79918f 2021-09-16T16:43:53 Vulkan: Pass command pool around Preparatory work for re-enabling support for Vulkan secondary command buffers. The command pool being passed around is not yet used. Additionally, the work to allocate, initialize, reset and recycle command buffers has been refactored to a helper class for better abstraction. The CommandBufferHelper class now holds a pointer to the pool it was allocated from for clean up. Each ContextVk has its own command pool, where Vulkan secondary command buffers are allocated from. The command pool that CommandProcessor had was unused and is removed by this change. Bug: angleproject:6100 Change-Id: I0d4fa6a76ef06e88779145ffe9c613518a8eb390 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3167213 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com>
Shahbaz Youssefi bf7fac12 2021-09-16T21:18:04 Vulkan: Fix getting driver priority with async command queue Bug: angleproject:6245 Change-Id: Id6b6f83177dde85867685f814c5bdef4a5c97367 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3167212 Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Jeff Vigil d2b659f9 2021-03-25T15:40:58 EGL: implement EGL_EXT_protected_content Context Add Validation check to Contexts and Surfaces Add Vulkan protected memory features and properties Add protected member to Surfaces and Contexts Implement hasProtectedContent in Vulkan Add QueueFamily helper, extent DeviceQueueMap Protected Swapchains always on for Android Add EGLProtectedContentTest Test: angle_end2end_test --gtest_filter=EGLProtectedContentTest Bug: angleproject:3965 Change-Id: I9352b1e594f71bb4e89cee7137a468940d186b1b Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2800413 Commit-Queue: Mohan Maiya <m.maiya@samsung.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Geoff Lang <geofflang@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Courtney Goeltzenleuchter aafcb504 2020-12-08T09:32:10 Vulkan: Add ensureSubmission to queueSubmitOneOff Some callers of queueSubmitOneOff require that the command being queued to have been sent to the GPU. The new ensureSubmission parameter indicates that behavior and when running with threaded worker will wait for the worker queue to empty before returning. Bug: b/170312581 Change-Id: Ib620fb37f4b9b4431451ccbd10807c0dff1842af Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2579041 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Cody Northrop <cnorthrop@google.com> Commit-Queue: Courtney Goeltzenleuchter <courtneygo@google.com>
Courtney Goeltzenleuchter 040de921 2020-11-20T09:26:35 Vulkan: Move FenceRecyler to CommandQueue. SharedFences are now only used by CommandQueue so move fence recycler to live there instead of RendererVk. Bug: b/170312581 Change-Id: Ib055ec50fbebe675a0064e1059089720e63b96b3 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2551792 Commit-Queue: Courtney Goeltzenleuchter <courtneygo@google.com> Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Jamie Madill 84fce18c 2020-11-13T10:14:58 Vulkan: Give CommandQueue an abstract interface. This gives CommandQueue and CommandProcessor the exact same interface. This also moves the worker thread to be owned by CommandProcessor. Bug: b/172704839 Change-Id: Ife439bcf52d923e01a6a2166e0caaffce14fd086 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2537235 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com> Reviewed-by: Tim Van Patten <timvp@google.com>
Jamie Madill 1885942d 2020-11-08T11:19:07 Vulkan: Move device queue management to CommandQueue. This closes a few more places where the asynchronous abstraction was leaking through. We can no longer access VkQueues directly from RendererVk. Bug: b/172704839 Change-Id: Idc06ee73816147cf602f21723e75bc5ee842d3e0 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2525145 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com> Reviewed-by: Tim Van Patten <timvp@google.com>
Jamie Madill f19a4a20 2020-11-08T10:37:33 Vulkan: Move CommandBuffer management to RendererVk. This consolidates all relevant logic in a single place. We no longer need to interact with ContextVk in the worker thread. This switches the fixed pointer array size to a dynamically sized vector. Some of the EGL and ANGLE tests would use a large number of Contexts and we were consistently running out of available command buffers which would cause a deadlock situation. We can trust other parts of the code to throttle the application if it starts to get too far ahead of the device and dispense with the hard coded limit in the command buffer allocator itself. The resulting code is also quite a bit simpler and doesn't need a condition variable. Also fixes missing initialization in SecondaryCommandBuffer. Bug: b/172704839 Change-Id: Icc3a3daf5d6b272db556c0e4c93fb793583966a5 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2525143 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com>
Jamie Madill ce7bdd0b 2020-11-08T09:45:30 Vulkan: Merge CommandQueue and TaskProcessor. Bug: b/172704839 Change-Id: I43a40e6a3e1eb00a7ddebfba6e915437aa69aeb6 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2525141 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com>
Jamie Madill 6a1fb047 2020-11-07T19:04:43 Vulkan: Align CommandQueue and TaskProcessor. The intent is to merge these two classes and remove redundant code. Bug: b/172704839 Change-Id: I6eb66d7b4ddea3633b08df99464975cd59773b4e Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2524550 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com> Reviewed-by: Tim Van Patten <timvp@google.com>
Jamie Madill 65ee5168 2020-11-08T09:30:39 Vulkan: Align submit and serial management code. This progresses the goal of merging TaskProcessor and CommandQueue. Moving the serial management out of RendererVk allows these classes to have finer control over when thread synchronization locks happen. Note: device lost handling seems untested currently. Bug: b/172704839 Change-Id: I0cc61e1ffe41aad0b898d4146c8dbd08a2cebd3c Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2525140 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com>
Jamie Madill 6df1ffdc 2020-11-07T17:17:53 Vulkan: Remove in-flight commands lock in TaskProcessor. This is no longer necessary with the removal of the submit fence. Bug: b/172704839 Change-Id: If8c2795d7e3c73453a235498ed6caac727bdaca5 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2524549 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com> Reviewed-by: Tim Van Patten <timvp@google.com>
Jamie Madill e6a302a0 2020-11-07T10:49:15 Vulkan: Move vk::CommandQueue to RendererVk. This consolidates most of the command processor vs queue logic in one place. It also has a number of incidental changes related to fences: - syncs now do not store a shared fence. instead they call command apis to wait for a particular serial with a timeout. this is not yet fully implemented in CommandProcessor. - surface swap history stores a serial instead of a fence. because the RendererVk class stores the command batches, we no longer have to do messy things with ContextVk. - it is no longer possible to ask for a wait on a serial that isn't in the command queue. Also adds mutex synchronization around the RendererVk methods. Bug: angleproject:5217 Bug: b/172704839 Change-Id: I5faf0e24bb6ede79a927ab149b80bfa8baca4620 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2524548 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com> Reviewed-by: Tim Van Patten <timvp@google.com>
Jamie Madill 8a90378c 2020-11-07T10:40:28 Vulkan: Remove hasPrimaryCommands(). We now create empty primary command buffers when there are no existing commands to submit. The main reason to remove this is so that we don't have to make a synchronous call to CommandQueue or the async command processor to determine if there are queued primary commands. Bug: b/172704839 Change-Id: I53f65eaa187b618e4ed82a5d2805a76e6a9e036c Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2524547 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com> Reviewed-by: Tim Van Patten <timvp@google.com>
Jamie Madill 9d65420c 2020-11-07T10:22:34 Vulkan: Move CommandQueue to CommandProcessor.h. This will facilitate moving this class from the ContextVk to RendererVk. Also cleans up some redundant vk:: prefixes. Bug: b/172704839 Change-Id: I789c9984c0df7fc376e2373530e48afde354d30b Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2524546 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com> Reviewed-by: Tim Van Patten <timvp@google.com>
Courtney Goeltzenleuchter 6bc362c4 2020-10-18T19:09:47 Allow single threaded CommandProcessor In replacing the legacy CommandQueue code with the threading capable CommandProcessor it would be good to be able to run the CommandProcessor in a single-thread environment. This CL changes the meaning of the feature flags for the commandProcessor and asynchronousCommandProcessing so that enabling commandProcess only changes the code paths to use the command processor but work it still done as part of the submitting thread (e.g. ContextVk). Enabling asynchronousCommandProcessing will cause a separate worker thread to be spawned which will asynchronously process the commands. This allows us to switch to the CommandProcessor without threading and then enable threading once performance issues are resolved. Bug: b/161912801 Bug: b/170329600 Change-Id: I534862b109a7e7708108190b7c3e894071d4c2ed Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2483580 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Commit-Queue: Courtney Goeltzenleuchter <courtneygo@google.com>
Jamie Madill 97843bda 2020-10-30T17:03:36 Vulkan: Fix EGL Surface robust init. The error here was related to using a single cache variable for the robust init setting for all the surfaces in a DisplayVk. Fix this by passing down the robust init setting from the SurfaceVk to image init. Bug: angleproject:5274 Change-Id: I9bc9c20990268d1d5166411fb53f8f2593fd1971 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2510694 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Courtney Goeltzenleuchter ed876984 2020-10-03T11:00:36 Vulkan: functionally complete worker thread Working on enhancing worker thread to completely own primary command buffers. This will include not only processing SCBs from main thread into a primary, but also submitting those command buffers to the queue. The CommandProcessor is a vk::Context so it can handle errors in the worker thread. When the main thread submits tasks to the worker thread it also syncs any outstanding errors from the worker. Include asynchronousCommandProcessing feature that will control whether the worker thread task does it's work in parallel or not. If false, we wait for the thread to complete it's work before letting the main thread continue. If true, the thread can execute in parallel with the main thread. Bug: b/154030730 Bug: b/161912801 Change-Id: I00f8f013d6cbb2af12a172c4f7927855db2f0ebf Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2328992 Commit-Queue: Courtney Goeltzenleuchter <courtneygo@google.com> Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Courtney Goeltzenleuchter 9413c402 2020-10-03T10:58:12 Vulkan: Move CommandBatch for threading support Will need access to CommandBatch class in threading worker. Bug: b/154030730 Change-Id: Ia79eab77a81b135c22bdeecbaf65bf3c301dc987 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2447442 Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Courtney Goeltzenleuchter <courtneygo@google.com>
Jamie Madill 23211585 2020-07-21T10:08:03 Roll chromium_revision b0410bba02..fb6cbaf6e5 (763000:790363) Also updates a Vulkan back-end file to not return error. Change log: https://chromium.googlesource.com/chromium/src/+log/b0410bba02..fb6cbaf6e5 Full diff: https://chromium.googlesource.com/chromium/src/+/b0410bba02..fb6cbaf6e5 Changed dependencies * build: https://chromium.googlesource.com/chromium/src/build.git/+log/45ab3c89af..1ee11394cf * buildtools: https://chromium.googlesource.com/chromium/src/buildtools.git/+log/204a35a2a6..9e121212d4 * testing: https://chromium.googlesource.com/chromium/src/testing/+log/3993ef1f52..f126fc6578 * third_party/Python-Markdown: https://chromium.googlesource.com/chromium/src/third_party/Python-Markdown/+log/36657c103c..9c8566e047 * third_party/googletest: https://chromium.googlesource.com/chromium/src/third_party/googletest/+log/217407c478..defbf92951 * third_party/jsoncpp: https://chromium.googlesource.com/chromium/src/third_party/jsoncpp/+log/{chromium_..ec647b85b6 * third_party/nasm: https://chromium.googlesource.com/chromium/deps/nasm.git/+log/4fa54ca5f7..19f3fad68d * third_party/zlib: https://chromium.googlesource.com/chromium/src/third_party/zlib/+log/ae385786ed..89bddfee9c * tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang.git/+log/04b99e7bf9..6412135b39 * tools/md_browser: https://chromium.googlesource.com/chromium/src/tools/md_browser/+log/aae45d8d82..be8cf5a17d DEPS diff: https://chromium.googlesource.com/chromium/src/+/b0410bba02..fb6cbaf6e5/DEPS Clang version changed 4e0d9925d6a3561449bdd8def27fd3f3f1b3fb9f:04b9a46c842f793a2baedcad64de35fcbd3e93b7 Details: https://chromium.googlesource.com/chromium/src/+/b0410bba02..fb6cbaf6e5/tools/clang/scripts/update.py Bug: angleproject:4867 Change-Id: I184945ad4d1fc39f4ad9b37cbf411b2c2b74a3ab Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2309223 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Antonio Maiorano 13816d2d 2020-06-16T14:27:04 Move vulkan_headers/entry_points to common/vulkan This will allow us to move common headers, such as extension headers, to common/vulkan. Bug: b/159027603 Bug: b/154620295 Change-Id: I1ff73dc5b7ee8f7dfb3ac0c5f30bd4b3a8183aeb Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2248205 Commit-Queue: Jamie Madill <jmadill@chromium.org> Commit-Queue: Antonio Maiorano <amaiorano@google.com> Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Tobin Ehlis 02fa7313 2020-05-05T17:01:18 Vulkan:Initial worker thread disabled by default Created new CommandProcessor class that can be run as a worker thread. Running CommandProcessor within RendererVk as a worker thread that takes a CommmandBufferHelper (CBH) ptr as the interface and processes that CBH into a primary command buffer. Main thread has a queue of CBH to draw from. After submitting a CBH to the worker, it pulls next CBH from the queue. Worker thread releases CBH back to the main thread queue when done. Synchronization goes two ways: 1. Work submitted to worker thread is managaed with a mutex and condition variable based around the work queue. 2. Available CBH ptrs for the main thread have a mutex and condition variable that manages the CBH queue. The worker thread is disabled by default, and, when enabled, it will currently behave and perform as the non-threaded code. This is because the kNumCommandBuffers const in ContextVk.h is set to 2. With only 2 command buffers, they will be assigned to the inside and outside RenderPass command buffers respectively. Then, as soon as one is submitted, the main thread will stall waiting for it to be completed and put back into the queue mentioned in #2 above. The next step is to move command submission to the worker thread and update the number of command buffers so that processing/submission will occur in parallel with the main thread. Right now there is a race condition issue when attempting to run in parallel because the main thread updates and submits the same primary command buffers that are used in the worker thread, which is in violation of the Vulkan spec. The follow-on CL will fix this issue as the main thread will only touch SecondaryCommandBuffers and the worker thread will be the only thread touching the primary command buffers. Bug: b/154030730 Change-Id: Ib0c518bbd7ca9a3a7e789f4e1f2f7131ddc0509e Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2174719 Commit-Queue: Tobin Ehlis <tobine@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org>
kmx.io     mail     discord kmxgit v0.4.0