src/libANGLE/renderer/vulkan/CommandProcessor.cpp


Log

Author Commit Date CI Message
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>