|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|