src/libANGLE/renderer/vulkan/CommandProcessor.cpp


Log

Author Commit Date CI Message
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>
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>
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>
Jamie Madill cb87d78c 2021-07-08T08:28:04 Enable -Wshadow with Clang. Also fixes a few instances of variable shadowing in the code. Bug: angleproject:6148 Change-Id: Ic51d722a3f953f246f51af6d74abb302f832cf44 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3014875 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Shahbaz Youssefi c750129e 2021-04-16T16:59:25 Vulkan: Remove inappropriate use of VK_NULL_HANDLE A change in Vulkan-Headers changes the value of VK_NULL_HANDLE, exposing an invalid usage in ANGLE, which is fixed in this change. Bug: angleproject:5879 Change-Id: I136fdc9e707650a060eaee062c7cf8cf24d9e8b2 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2831998 Reviewed-by: Tim Van Patten <timvp@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@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 49c13282 2020-11-08T10:51:54 Vulkan: Merge async command queue features. This merges the 'commandProcessor' and 'asyncCommandProcessing' features into one new 'asyncCommandQueue' features. Conceptually the command processor is asynchronous use of the CommandQueue. This renaming updates the code to reflect the usage. Bug: b/172704839 Change-Id: I1d7ca1187f802eed48823a01b57fb520527f2540 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2525144 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>
Tobin Ehlis a9504808 2020-07-29T16:33:45 Vulkan: ATrace marker fix-ups Fix a couple of mislabled atrace markers and add explicit markers for inside/outside renderpass flushes. Bug: b/156403378 Change-Id: I4045846e54ff54bc8fc3dd6ef47339f6f5eb8e87 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2327828 Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com> Reviewed-by: Tobin Ehlis <tobine@google.com> Commit-Queue: Tobin Ehlis <tobine@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>
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>