|
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>
|
|
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>
|
|
|
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>
|
|
|
77d19e39
|
2023-01-11T14:03:18
|
|
Vulkan: Add ThreadSafeCommandQueue class
This is preparation CL for the next few CLs. Instead of having
RendererVk owns mCommandQueueMutex and takes lock before calling
CommandQueue APIs, this CL creates a ThreadSafeCommandQueue wrapper
class that wraps CommandQueue class' public APIs with a mMutex. Right
now this is purely a mechanical change, expecting no real functional or
behavior differences. But in the future CLs, we are going to implement
some APIs without holding lock while doing the wait. This also
conceptually cleaner that a mutex lock should protect data not methods.
Because of this, this CL also adds OneOffCommandPool class to wrap
around all oneoff command buffers with its own lock. The same change
also applied to CommandProcessor class by adding a
ThreadSafeCommandProcessor class (this will be removed in later CLs).
This CL also removes CommandQueueInterface base class and made all these
virtual functions no longer virtual, thus reduces the overhead associate
with calling virtual functions.
Bug: b/261106868
Change-Id: Ifdc0085cef7f00d840b4ef3fa602172fed3c0fb1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4156637
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
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>
|
|
|
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>
|
|
|
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>
|
|
|
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>
|
|
|
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>
|
|
c6390143
|
2022-10-12T09:57:55
|
|
Vulkan: Make compatible with GCC
Resolves below warnings occurred with GCC build.
1) deperecated-copy
Overriding an assignment operator without a copy constructor
caused the deprecated-copy warnings.
2) unused-function
3) parenthesis
Warnings occurred due to missing parenthesis around
some logical expressions, add them to quiet the warnings.
4) unused variable
5) 'maybe-unused' attribute ignored
Introduces 'ANGLE_MAYBE_UNUSED_PRIVATE_FIELD' macro to avoid
'attribute ignored' warning which is only occurred
with GCC because GCC doesn't warn about 'unused non
static data member' whereas Clang has Wno-unused-private-field.
Signed-off-by: Sungyong Choi <sywow.choi@samsung.com>
Bug: angleproject:7764
Change-Id: I8e7410a5ed8cb9b8f8b3202073d779fea63d6b75
Reviewed-by: Jeff Vigil <j.vigil@samsung.com>
Reviewed-by: Mohan Maiya <m.maiya@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3963830
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
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>
|
|
|
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>
|
|
|
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>
|
|
|
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>
|
|
|
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>
|
|
|
81d964a1
|
2021-10-28T10:50:51
|
|
vulkan: implement EGLDevice for vulkan backend
It allows ANGLE clients to get and use VkDevice and VkQueue
used by vulkan backend.
Bug: chromium:1264439
Change-Id: I338ac08152cfec50bb34c5025730e5e6368efba9
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3250964
Reviewed-by: Peng Huang <penghuang@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Peng Huang <penghuang@chromium.org>
|
|
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>
|
|
|
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>
|
|
|
bf7fac12
|
2021-09-16T21:18:04
|
|
Vulkan: Fix getting driver priority with async command queue
Bug: angleproject:6245
Change-Id: Id6b6f83177dde85867685f814c5bdef4a5c97367
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3167212
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
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>
|
|
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>
|
|
|
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>
|
|
|
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>
|
|
13816d2d
|
2020-06-16T14:27:04
|
|
Move vulkan_headers/entry_points to common/vulkan
This will allow us to move common headers, such as extension headers, to
common/vulkan.
Bug: b/159027603
Bug: b/154620295
Change-Id: I1ff73dc5b7ee8f7dfb3ac0c5f30bd4b3a8183aeb
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2248205
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Antonio Maiorano <amaiorano@google.com>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
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>
|