|
8ae36a93
|
2023-11-14T10:11:51
|
|
Vulkan: Bugfix in isFastUnpackPossible
Disallow fast unpack when there is a mismatch between the
actual texture format and intended buffer (PBO or client buffer)
format.
Bug: angleproject:3777
Test: Texture2DTestES3.UnpackCompatibleFormatButDifferentType*
Change-Id: I9ea9d9cdd5e1391acebb3d75d69437e27cfa90df
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5029504
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
|
|
3a6b385f
|
2023-11-09T15:48:48
|
|
Vulkan: Fix depth/stencil texture copy
Bug: angleproject:7289
Change-Id: Icde8a26e855e95a6c0a1e506d2435e981adc6f28
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5018798
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
d896fab8
|
2023-11-09T15:03:05
|
|
Vulkan: Fix texture self-copy
A new layout is introduced to support self-copy.
Bug: angleproject:7289
Change-Id: Ib914c433d55b9a79cfeb7a91f8a2b8680824d473
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5018797
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
9a5d75de
|
2023-10-30T11:59:19
|
|
Vulkan: Fix incompatible redefinition of cube faces
The TextureVk::mRedefinedLevels bitmask tracked which levels are
incompatibly redefined, greatly reducing the complexity of dealing with
GL's mutable textures.
It did not however take into account the fact that GL allows each
cubemap face to be separately redefined (unlike 2D arrays, where all
layers are defined together). This change turns the bitmask into an
array of bitmasks. Previously, a single bit represented whether the
level is incompatibly redefined. Now, elements of the array track the
same information for each cube face. For non-cube-map textures, only
element 0 is used.
Bug: chromium:1494664
Change-Id: I69568d3da2391796bf5f01505861fee42c6c8924
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4986289
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
5dd0c842
|
2023-10-24T13:48:29
|
|
Vulkan: improve memory type mismatch issue.
for dynamic buffer usage, the memoryTypeIndex
returned from findMemoryTypeIndexForBufferInfo
not used. if we add more flags like
VK_MEMORY_PROPERTY_HOST_CACHED_BIT at alloction.
the actual memory type allocated may not have such flag.
Bug: b/306763053
Change-Id: I778e51fdd5ce0bc0810a965c45b5763a155fc391
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4973574
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Hailin Zhang <hailinzhang@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
4f611a1f
|
2023-10-24T20:56:19
|
|
Vulkan: Remove RendererVk::collectAllocationGarbage
Instead of adding separate method overload `DestroyGarbage()` method.
This will avoid checking `mUse` and creating garbage list twice.
Bug: b/218891184
Change-Id: If56ffe72a639021b1fd37feb02ebb91f62ad0933
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4974318
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
ba65feb4
|
2023-10-18T17:33:38
|
|
Vulkan: Limit mutable texture flush to one update
In case there are many updates for a mutable texture, flushing
it preemptively can reduce performance, especially if it is done
repeatedly.
* Added getLevelUpdateCount() to ImageHelper.
* Previous mutable textures will now be flushed only if they have
exactly one update per mip level/cubemap face (if defined).
* This means that mutable textures with no data will also not be
flushed.
* Added unit tests for single-level texture flushing and situations
with no updates or more than one update.
Bug: b/285613719
Change-Id: I1592ecf502051a55ebfbb7fcd22577c9ce87bf43
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4953847
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
d2de7451
|
2023-10-19T14:10:44
|
|
Vulkan: Fix VK_android_external_format_resolve VVL error part 5
Fix assertion in RendererVk::getFormatFeatureBits(). When formatID is
external format, we can not use vkGetPhysicalDeviceFormatProperties to
get the formatFeature (since VkFormat is undefined). To fix this, we
keep the formatFetaure that returned from AHB in the
ExternalYuvFormatInfo and use that in getFormatFeatureBits() if it is
external format.
This also fixes the VVL error VUID-VkImageCreateInfo-pNext-02396: The
Vulkan spec states: If the pNext chain includes a
VkExternalFormatANDROID structure whose externalFormat member is not 0,
flags must not include VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT
Bug: b/223456677
Change-Id: I625c2bf4fe534fa206918b16772ac3ac7c6fa79a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4956117
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
4d7fc442
|
2023-10-18T12:49:06
|
|
Vulkan: Fix VK_android_external_format_resolve VVL error part 3
VUID-VkRenderPassAttachmentBeginInfo-pAttachments-parameter: The Vulkan
spec states: If attachmentCount is not 0, pAttachments must be a valid
pointer to an array of attachmentCount valid VkImageView handles. The
bug here is that when nullColorAttachmentWithExternalFormatResolve is
true, there is no color attachment, but the RenderPassDesc still appears
having a color attachment because we need to store the formatID in it.
This CL changes to use mFramebuffer.getImageViews().size() instead of
mRenderPassDesc.attachmentCount() which is more correct anyway.
Bug: b/223456677
Change-Id: I0f0947f0c642bac9cd18a80525b92c62ef0723ec
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4952969
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
|
|
|
58ffa778
|
2023-10-11T09:41:23
|
|
Vulkan: Implement YUV_TARGET use VK_ANDROID_external_format_resolve
This implements EXT_YUV_TARGET using VK_ANDROID_external_format_resolve
extension.
This CL is based on Chris Forbes's CL on android gerrit.
Bug: b/223456677
Change-Id: Ieb6970a0787b0c2a72a76b208695a678d2c79e80
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4857459
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
493ca47c
|
2023-10-13T23:22:34
|
|
Vulkan: remove unused image view creation
remove unused image view creation.
Bug: b/303708135
Change-Id: I5e20788a6f3e042db04d739144236c065c407209
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4940252
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Hailin Zhang <hailinzhang@google.com>
|
|
dc8c053e
|
2023-10-12T00:00:00
|
|
Split row and depth pitch computation for compressed formats
Besides doing extra operations, computeCompressedImageSize
cannot be used for computing pitch values for formats that
have minimum block layout requirements, such as PVRTC1.
Fixed: angleproject:8375
Change-Id: Id276e8cf723f0bb99b6f4a9b20d6d84e4840f6d7
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4935568
Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
76608554
|
2023-10-02T15:07:45
|
|
Vulkan: use cpu transcoding for small texture size.
Bug: b/250042517
Change-Id: I9a70fb7d4823d10b09f498bfc01b5384951e2ce4
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4908660
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Hailin Zhang <hailinzhang@google.com>
|
|
|
2608c622
|
2023-10-06T13:32:49
|
|
Vulkan: Refactor SharedGarbageList into templated class
This CL mostly involves non-functional changes to prepare for next CL.
No behavior change is expected.
This CL wraps the garbage list into its own templated class which
maintains std::queue and tracks number bytes in the queue etc.
This CL also renames SharedBufferSuballocationGarbageList to
BufferSuballocationGarbageList to reduce verbosity a bit.
This CL deleted GarbageAndQueueSerial and GarbageQueue since they are no
longer being used.
This renames vk::GarbageList to vk::GarbageObjects to reduce name
confusion with SharedGarbageList.
Bug: b/302739073
Change-Id: I7370c147847ffe69ad8aa3b48251d8b5762f97f9
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4919816
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Hailin Zhang <hailinzhang@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
7f5143c2
|
2023-10-02T15:38:15
|
|
Vulkan: Notify VAO when VBO's mBufferWithUserSize changed.
When buffer robust access is enabled, and bufferData is called with
different size and we end up reusing the underline storage, we will have
to recreate VkBuffer with user's size, and driver is relying on
VkBuffer's size to implement robust access. The bug here is that we
notify VAO when storage changes. But when storage is reused and we have
dedicated VkBufer with user size and that VkBuffer changed, we were not
notifying the VAO. This CL adds that notification so that VAO gets
notified and dirty bits processed and its cache of VkBuffer gets updated
Bug: chromium:1488055
Bug: b/303138134
Change-Id: Ie693c92c2edde9a22a41a25f5bde493397550d95
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4906568
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
d919870f
|
2023-09-14T16:00:07
|
|
Vulkan: Do host image copy without holding the share group lock
When an application uploads texture data such as with `glTexSubImage2D`,
the share group lock is being hold while the data is being copied.
Without VK_EXT_host_image_copy, this is a copy to a staging buffer,
which may itself be expensive. With VK_EXT_host_image_copy, the cost of
the copy is higher and so the lock would be held for a longer duration.
This is particularly harmful to applications that spawn a separate
thread for texture uploads (as the main thread is unable to make GL
calls). This change moves the actual copy call to the tail of the call
after the share group lock has been released. As a result:
- The upload thread may be a bit slower, but
- The copy does not interfere with the main thread, and
- The copy does not interfere with the GPU's rendering work.
As a result, games that load content seamlessly during gameplay should
experience less stutter during texture uploads.
Bug: angleproject:8341
Change-Id: I818c4389d4bf828847578da89414623e4b5e844e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4864290
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
1579eed5
|
2023-09-25T18:21:39
|
|
BufferHelperPointerVector -> BufferHelperQueue (deque)
DynamicBuffer.mBufferFreeList is a vector<unique_ptr>.
DynamicBuffer::allocate erases an element from the front, which is what
deque is exactly good for.
Changed other uses too (mBufferFreeList,
VertexArrayVk.mCachedStreamIndexBuffers) per Charlie's recommendation.
Yields a significant power improvement in words_crush trace.
Bug: b/302020992
Change-Id: I1b0242481404b8fc2cfdc27611252308b922f4d7
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4886367
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Roman Lavrov <romanl@google.com>
|
|
|
be8739f2
|
2023-09-22T14:36:45
|
|
Vulkan: Fix StatInfo in vk_mem_alloc_wrapper.h to match VMA
Right now we are defining our own StatInfo structure in
vk_mem_alloc_wrapper.h to avoid inclusion of VMA header directly in
other ANGLE code. This caused this struct no longer matches VMA's
structure since VMA 3.0 switch. For quick fix, this CL just update
StatInfo to match VMA 3.0 define.
Bug: b/301653706
Change-Id: Ic510c362f30d9296a13964e6ba9c617e80e49ceb
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4888625
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
91ef1f3c
|
2023-09-08T16:39:53
|
|
Move buffer suballocation callers to ContextVk
* Moved the following functions from BufferHelper to ContextVk.
* initBufferForBufferCopy()
* initBufferForImageCopy()
* initBufferForVertexConversion()
Bug: b/280304441
Change-Id: I890f4396b00b0c20feb44f0ad113c55924ce1014
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4854760
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
a1f52f1b
|
2023-09-07T14:44:24
|
|
Vulkan: Flush pending image garbage more often
* Added a counter to the context object to keep track of the size of
the pending image garbage: mEstimatedPendingImageGarbageSize.
* Modified hasExcessPendingGarbage() to use the sum of the size of
the image and and suballocation garbage.
* RendererVk::calculatePendingGarbageSizeLimit() provides the limit.
* Currently the limit is based on the available heap sizes. It will
use a fraction of the largest memory heap size.
* The portion is currently kGarbageSizeLimitCoefficient = 0.2f.
* Unskipped the test "TextureDataInLoopManyTimes", which was failing
on Android devices.
Bug: b/280304441
Change-Id: Ibcced1d118ea8a1f347028b62d29cfbd9e38e8c0
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4851252
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
1b450b92
|
2023-09-15T11:07:25
|
|
Vulkan: Fix buffer storage reuse bug when robustAccess is enabled
There is an optimization in vulkan backend that when the bufferData is
called and current storage size is big enough for new bufferData call,
we just reuse the storage. Mean while, when hasRobustAccess() is true,
we must use the VkBuffer with the exact user size that glBufferData call
provides so that driver can set proper access boundary. In order to
satisfy both requirement, if robust resource access is enabled, we
create a separate VkBuffer with the exact user provided size but bind to
the same memory. There is a bug here that if robustAccess is true, this
buffer of user provided size is not been recreated when storage is
reused but with different user size (both has same allocation size).
This causes we keep using the smaller VkBuffer and subsequently causes
missing triangles. This CL clears mBufferWithUserSize when size changes
and storage is reused.
The other bug here is that previously we are checking
isRobustResourceInitEnabled, which is incorrect. We should check
hasRobustAccess. This appears works for chrome possibly due to both are
enabled. This CL switches it to check hasRobustAccess.
This CL also renames mBufferForVertexArray to mBufferWithUserSize to
reflect what its true meaning.
Bug: chromium:1476475
Change-Id: I843cc3a705f8a582a97bc0307f03aa1eb9fad3ff
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4864003
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
b2e6a196
|
2023-09-11T15:27:20
|
|
Vulkan: Use VK_EXT_host_image_copy for texture uploads
Of all the scenarios where host image copy may be useful, this is likely
the most common case. There are numerous conditions for when the copy
may be done on the host:
- The image format must support it,
- It must be unused by the GPU,
- It must not have any pending updates (this can potentially be
mitigated if needed), and
- It must be in a host-copyable layout.
However, many texture uploads are done:
- To compressed formats, where support is highly likely,
- On init, where:
- the image is never previously used,
- the image has no previous uploads
- the image is in the UNDEFINED layout
which satisfies the conditions above.
As a result of this change, when the upload is done on the host,
creation of a temp buffer is avoided which greatly reduces memory
pressure (specially during app loading which is when most texture data
is uploaded) and may even improve performance (due to avoiding a double
copy).
Testing the first 3 frames of the following traces with a SwiftShader
implementation shows the amount of buffer allocated for staged uploads
changed as such:
- Black Desert: 185MB -> 65MB
- Genshin Impact: 125MB -> 12MB
- Asphalt 9: 138MB -> 0MB
Bug: angleproject:8341
Change-Id: Id71dcc4a7a0f8b67960d2d283fe9d19ce7429a03
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4856676
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
e7418836
|
2023-08-16T14:25:52
|
|
Vulkan: Add context flushing as OOM fallback
* As a new fallback for out-of-memory errors, if an allocation results
in device OOM, the context is flushed and the allocation is retried.
* Functions related to buffer/image allocations now return a VkResult
value instead of angle::Result, which will be bubbled up to a higher
level for safer handling.
* The OOM is no longer handled at the level where the allocation
happens, but is moved up to the context.
* Added two functions to ContextVk for allocating memory for images and
buffer suballocations, which also include the fallback options.
* initBufferAllocation(): Uses BufferHelper::initSuballocation()
* initImageAllocation(): Uses ImageHelper::initMemory()
* Moved initNonZeroMemory() out of the following functions:
* BufferHelper::initSuballocation()
* Moved to ContextVk::initBufferAllocation().
* ImageHelper::initMemory()
* Moved to ContextVk::initImageAllocation().
* Also moved to new function:
ImageHelper::initMemoryAndNonZeroFillIfNeeded().
This function replaced the rest of initMemory() usages outside
initImageAllocation().
* New macros for memory allocation
* VK_RESULT_TRY()
* If the output of the command inside it is not VK_SUCCESS, it will
return with the error result from the command.
* VK_RESULT_CHECK()
* If the output of the command inside it is not VK_SUCCESS, it will
return with the input error.
* Added a test in which allocation would fail due to too much pending
garbage without the fix on some platforms. The test ends once there
has been a submission.
* New suite: UniformBufferMemoryTest
* Added a similar test for flushing texture-related pending garbage.
* New suite: Texture2DMemoryTestES3
Bug: b/280304441
Change-Id: I60248ce39eae80b5a8ffe4723d8a1c5641087f23
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4787949
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
6553225d
|
2023-09-11T11:33:19
|
|
Vulkan: Refactor image usage/flags support check logic
The function that checks whether a format supports a specific usage is
moved to ImageHelper. For VK_EXT_host_image_copy, Renderbuffer, AHB etc
may also use this function.
Bug: angleproject:8341
Change-Id: I6ebc06f97fd29e66aa8d43fcf045f51717d27864
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4856144
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
6258d479
|
2023-08-30T22:11:38
|
|
Vulkan: disallow pbo copies when offset is incompatible with vulkan
Per spec of vkCmdCopyImageToBuffer:
If srcImage does not have either a depth/stencil or a multi-planar
format, then for each element of pRegions, bufferOffset must be a
multiple of the texel block size
This change disallows pbo copies if violating that spec vu.
Bug: b/297927542
Test: org.skia.skqp.SkQPRunner#UnitTest_TransferPixelsFromTextureTest
Change-Id: I7df4bee5fa574c44dd872f7225567049c5562a99
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4827694
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Auto-Submit: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
571b4cdb
|
2023-08-14T16:55:28
|
|
Vulkan: Move pipeline/desc-set layout creation to link job
The pipeline and desc-set layout caches are consequently made
thread-safe. The reference counter on the layouts are also made atomic.
With this change, practically all of the link in the Vulkan backend is
moved to the link job.
Bug: angleproject:8297
Change-Id: Iba694ece5fc5510d34cce2c34441ae08ca5bb646
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4774787
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
f11c972b
|
2023-08-04T15:06:39
|
|
Update requiredFlags use for VMA image allocations
For the OOM fallbacks, we currently remove bits from the required
bits when device memory allocation is no longer possible. In doing so,
allocating on the device has become a strong preference rather than a
requirement. Therefore, we change this method a bit in this CL.
* Removed the device-local bit from the required flags when calling
allocateAndBindMemory().
* preferredFlags is now used in lieu of requiredFlags initially within
allocateAndBindMemory() to signal to the VMA to prioritize allocating
on the device. If it fails, we use requiredFlags for the fallback.
Bug: b/280304441
Change-Id: Id47a224cd74dacd3fb12d4fbfd815d8cefc016c4
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4753758
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
16cfa28e
|
2023-08-08T22:08:24
|
|
Vulkan: Basic infra for parallel link
This change moves pipeline warm up to a parallelizable task, mostly as
an exercise to put in the infrastructure for parallel link in the Vulkan
backend. Follow up changes will move more of the link step to this
task.
The end goal is to be able to make the link task independent of
ContextVk, which would allow it to be run as an UnlockedTailCall, even
if not using a worker thread.
Bug: angleproject:8297
Change-Id: I17047162b2a41f0d681d9e3ee33f2e0239b4280d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4764231
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
7c69116f
|
2023-08-08T10:14:47
|
|
Vulkan: Fix data race with DynamicDescriptorPool
Right now DynamicDescriptorPool::destroyCachedDescriptorSet can be
called from garbage clean up thread, while simultaneously accessed from
context main thread, and data race will happen and cause bugs. This can
only happen when the buffer is not being suballocated. In this case,
suballocation owns the bufferBlock and bufferBlock gets destroyed when
suballocation is destroyed from garbage collection thread. If buffer is
suballocated, the shared group owns pool which owns bufferBlocks and
they gets destroyed from shared group with the share group lock. This CL
avoids this race problem by release the shared cacheKey when the buffer
is released, while we still had the shared group lock.
Bug: chromium:1469542
Change-Id: Ic1f99e6b6083d63e4efb9c3f408921da62c006ac
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4761365
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
e50d3876
|
2023-08-04T14:47:41
|
|
Vulkan: Retain loadOp when there is a resolve attachment
Rendertargets with resolve attachments cannot optimize away loadOp
Load or Clear even if they are marked ResourceAccess::Unused and
storeOp is RenderPassStoreOp::DontCare.
Bug: angleproject:4836
Bug: angleproject:5981
Tests: ImageTest.SourceAHBTarget2DMSRTTInteraction*
Change-Id: I39ec67a457de6876ed0bd47d66a963cc59fab064
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4753735
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
52fe3116
|
2023-07-17T16:20:54
|
|
Vulkan: Deduplicate share group's context set tracking
Bug: angleproject:8224
Change-Id: I7a59a37229682fb91ff777f31e02e05d7ab2b80f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4690345
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
6ffd0d20
|
2023-07-12T12:09:45
|
|
Vulkan: Clean up depth stencil feedback mode part 2
Right now the tracking of depth stencil buffer readOnly or feedback loop
is in FramebufferVk class. This really belongs to ContextVk, since it is
not a permanent state of framebuffer, but current state of context. This
CL moves it to ContextVk and changes to use BitSet instead of four
boolean.
Bug: b/289436017
Change-Id: I955c439259935f82eff30ddfff776a69723e5d0d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4679886
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
a33ec5dd
|
2023-07-11T18:01:12
|
|
Vulkan: Clean up depthStencil feedback loop implementation Part1
This is first clean up effort for depth stencil feedback loop
implementation. This CL moves updateRenderPassStencilReadOnlyMode and
updateRenderPassDepthReadOnlyMode methods from FramebufferVk to
RenderPassCommandBufferHelper class. The method is actually updating
renderPass's state, not FramebufferVk's state. In the next CL,
FramebufferVk will be removed from the argument as well. With this
change, I also removes updateStartedRenderPassWithDepthMode() and
updateStartedRenderPassWithStencilMode() to use
updateStartedRenderPassWithDepthStencilMode() directly.
This CL is mechanical changes only, no behavior chnage is expected.
Bug: b/289436017
Change-Id: Id3960f973a7115c05ebea199cb8ef802e995941a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4679365
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
0892420b
|
2023-06-28T23:03:51
|
|
Vulkan: Optimize PBO download between RGBA and BGRA
Google Meet hits this path in Chrome when blurring the background. The
CPU readback was particularly slow on Intel/Mesa where readback from the
temp buffer took hundreds of milliseconds.
This change adds a compute shader that directly copies from the image to
the pack buffer in simple but common cases.
Bug: b/286882707
Change-Id: I9877ea01e3d8377db96f2539362aca67cf832b4a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4657058
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Yuxin Hu <yuxinhu@google.com>
|
|
|
5f9548c3
|
2023-05-19T11:51:04
|
|
Vulkan: Free the garbage memory before realloc
Currently image allocations fall back to system memory in case of
a device OOM. However, in some cases, it is also possible to gain
some memory by freeing garbage memory from the device. This allows
us to keep the allocation on the device memory.
* Updated the image allocation fallback, so we will try cleaning the
garbage memory through the renderer before retrying the allocation.
* finishOneCommandBatchAndCleanup() in RendererVk, which will call a
similar function in its CommandQueue. It will be called until there
are no more in-flight submissions.
* The existing finishOneCommandBatchAndCleanup() in CommandQueue has
been renamed to finishOneCommandBatchAndCleanupImpl().
* Updated the flags used for VMA image allocations. If any device memory
is freed after garbage cleanup to make enough space for the new
allocation, it will take precedence over the system memory.
* Added unit tests in which a new image allocation could happen on the
device after freeing the garbage memory.
* They use a 2D texture and a 2D texture array for garbage.
Bug: b/280304441
Change-Id: Ia5e605e180833b44af8c77550ab1b0b8ba21724e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4547941
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
86e21fa2
|
2023-06-12T13:36:21
|
|
Vulkan: Refactor angle::Format depth/stencil checks
Bug: b/246008627
Change-Id: If0a2992c5bd66adf27c6866aea04e54ba465a522
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4608489
Reviewed-by: Roman Lavrov <romanl@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
ba857c47
|
2023-06-01T11:33:22
|
|
Vulkan: Move some bufferRead logic into CommandBufferHelperCommon
Some of the logic of bufferRead is common, to avoid code duplication,
it has been refactored into bufferReadImpl and moved into
CommandBufferHelperCommon.
Bug: b/282194402
Change-Id: I98cd0788db7fe9f14bd3155b28dc208f9f4a138a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4581061
Reviewed-by: Roman Lavrov <romanl@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
2501903e
|
2023-05-31T11:59:36
|
|
Vulkan: Merge UpdateShader***Buffers into updateShaderBuffers
Both UpdateShaderUniformBuffers() and
DescriptorSetDescBuilder::updateShaderBuffers() walks the list of
uniform blocks (or storage blocks). Some of the logic are the same and
we are paying that overhead twice. In this CL,
UpdateShaderStorageBuffers, UpdateShaderUniformBuffers and
UpdateShaderAtomicCounterBuffers functions are merged into
DescriptorSetDescBuilder::updateShaderBuffers and
DescriptorSetDescBuilder::updateAtomicCounters. In order to handle the
usage that same buffer used by multiple shader stages, a new variant of
bufferRead() function is added that takes "const gl::ShaderBitSet"
instead of single PipelineStage. This also paves way for next CL so
that we can call updateOneShaderBuffer individually.
Bug: b/282194402
Change-Id: I09d045d6295827b60bdb4c05df9333fe593fa40e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4574288
Reviewed-by: Roman Lavrov <romanl@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
b76166d0
|
2023-05-18T09:57:25
|
|
Vulkan: Separate image and sampler 2D view of 3D features
The sampler feature is used to determine if EGL_KHR_gl_texture_3D_image
can be exposed. The image feature is used to support base GLES 3.1
storage images.
Bug: b/274478146
Change-Id: Ifb283633078ace7ee65f8aafe756d0a02b727bd7
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4545005
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
80dd54f9
|
2023-05-17T22:16:59
|
|
Vulkan: Enable VK_EXT_image_2d_view_of_3d and set flag
Based on a change by Yiwei Zhang <zzyiwei@chromium.org>
Enabling the extension was missed from
https://chromium-review.googlesource.com/c/angle/angle/+/3648586, and
some implementations do rely on the feature enablement (e.g. RADV). This
also fixes the VVL violations on satisfied implementations.
Additionally, the VK_IMAGE_CREATE_2D_VIEW_COMPATIBLE_BIT_EXT flag is
always set on 3D images when this extension is supported; it is
needed for both sampled and storage images, not just storage images.
Bug: b/274478146
Change-Id: Ibc210275e2d39ac0c54d1ae4c2451a5402360972
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4544762
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
ec308b35
|
2023-05-15T15:03:10
|
|
Vulkan: Add feature to limit sample count to 2
This CL adds a feature called `limitSampleCountTo2`. Using it will
have the Vulkan backend limit max samples to 2.
Why 2? That's the minimum required in Vulkan to multisample without
error. Here's an example validation error:
vkCmdResolveImage: srcImage sample count is VK_SAMPLE_COUNT_1_BIT.
The Vulkan spec states: srcImage must have a sample count equal to
any valid sample count value other than VK_SAMPLE_COUNT_1_BIT.
https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-vkCmdResolveImage-srcImage-00257
Using a limit as opposed to forcing a value allows non-multisampling
(sample count of 1) to continue working.
To see how tests fare when the feature is set, see the following test
results that force the value on:
https://chromium-review.googlesource.com/c/angle/angle/+/4534098/4
Test: adb shell setprop debug.angle.feature_overrides_enabled limitSampleCountTo2
Bug: b/279498079
Bug: angleproject:8162
Change-Id: I1df2822709151e6084c32055b5aff444e0b10db5
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4518562
Commit-Queue: Cody Northrop <cnorthrop@google.com>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Greg Schlomoff <gregschlom@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
6f959e07
|
2023-04-28T16:00:11
|
|
Vulkan: Add non-device memory option for VMA image
* Updated the required flags for allocateAndBindMemory() to no longer
include VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT, though still preferred.
This allows VMA to allocate from another memory type if the device
is out of memory.
* Added a debug message to indicate when allocated memory for VMA image
does not have all the preferred property flags.
* Also added a warning in the case of memory allocation fallback.
* Added a perf counter to keep track of image allocation fallbacks from
the device memory.
* deviceMemoryImageAllocationFallbacks
* Added a test to make sure that VMA images can still be allocated from
other memory types even if device memory is unavailable.
* VulkanImageTest.AllocateVMAImageWhenDeviceOOM
Bug: b/280304441
Change-Id: Ic452c18ded25345cdb7e271442372b99aede045e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4493483
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
e24f4519
|
2023-01-19T02:30:39
|
|
Vulkan: Add externalFence into submitCommands()
Currently one-off fence in the `queueSubmitOneOff()` is used only in
`SyncHelperNativeFence::initializeWithFd()` to submit external fence.
Other `queueSubmitOneOff()` calls may use `QueueSerial` instead of a
fence.
Providing `fence` into `queueSubmitOneOff()` prevents tracking that
submission with `QueueSerial`. Therefore using `mUse` to collecting
`mFenceWithFd` as garbage will not work as intended.
This CL removes `fence` from `queueSubmitOneOff()` and adds
optional `externalFence` into `submitCommands()` instead.
Providing `externalFence` will cause additional `vkQueueSubmit()` call:
- first submission will submit everything as usual except using
the `externalFence`.
- second, will only submit internal `CommandQueue` fence for
`QueueSerial` tracking.
As the result of this CL, call to `initializeWithFd()` will always
produce two (2) `vkQueueSubmit()` calls. Previously it may be one (1) or
two (2) submissions. Future CL will reduce submission count to one (1).
If add additional submission into `queueSubmitOneOff()` instead of
`submitCommands()`, then maximum number of submissions will be
three (3).
Bug: angleproject:8117
Change-Id: I6f1ec12682aaab71bfc871e665fec2659df96b26
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4392877
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
|
|
|
a73e546c
|
2023-04-14T13:40:19
|
|
Vulkan: Add pending memory size for VMA images
* Added implementation for vma::FindMemoryTypeIndexForImageInfo().
* Add pending memory allocation tracking for VMA images using
the memory requirement from getMemoryRequirements() and the
memory type index from the function above.
Bug: b/218891184
Change-Id: I1c3d3a8f5f36eb57bd7a5a059aa3bf713b819831
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4428535
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
13935469
|
2023-04-25T09:58:42
|
|
Vulkan: Fix access mask of generateMipmap's blit
Bug: angleproject:8143
Bug: angleproject:7125
Change-Id: I6e5b6cd1f445c2c41d4b78aeb368e30cc4c5354b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4475444
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
2ce6d8df
|
2023-04-20T17:16:00
|
|
TextureVk calls onStateChange when releasing buffer views
TextureVk::setBuffer releases buffer views and they don't get
initialized unless a dirty bit is set. That works on the first draw call
because Texture::Texture() sets DIRTY_BIT_IMPLEMENTATION in constructor,
but when called twice mBufferViews remains unitialized causing
mBufferViews.getView() misbehavior.
Fix this by calling onStateChange when buffer views are released.
As mBufferViews is only initialized conditionally for texture buffers,
add a bool for tracking whether it is in the initialized state to avoid
marking texture as dirty unnecessarily.
Note that this isn't handled by signalDirtyStorage() inside
Texture::setBufferRange because (in this test case?) there are no
observers on Texture so onStateChange called from Texture is a no-op.
Texture however observes its TextureVk implementation so onStateChange
calls from TextureVk end up setting the dirty bit in
Texture::onSubjectStateChange.
Bug: b/278585075
Change-Id: I2b83160cdd89a086ed81e8412cd64d0aad930911
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4457147
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Roman Lavrov <romanl@google.com>
|
|
|
a7bd3f53
|
2023-03-31T16:57:35
|
|
Fix the retrace issue for VMA image suballocation
After adding the VMA image suballocation feature, VVL errors were seen
when using the retracing script for some traces, causing failure. After
analysis, it was seen that the functionality of the allocation differs
from the original method when it comes to non-zero memory allocation.
* In allocateAndBindMemory(), the memory property flags from the
allocated memory are returned to be used for non-zero memory feature
usage.
* Added mapMemoryAndInitWithNonZeroValue() to ImageMemorySuballocator,
which is used when allocateNonZeroMemory is enabled and the allocated
memory is host-visible.
* Merged the following into ImageHelper::initializeNonZeroMemory():
* mapMemoryAndInitWithNonZeroValue()
* InitMappableDeviceMemory(); used when VMA image suballocation is
disabled.
* Moved onMemoryAlloc() inside allocateAndBindMemory().
Test: retrace_restricted_traces.py
Bug: b/277618656
Bug: angleproject:8058
Change-Id: If411a073e900c1c034d40a99e3fffefe30c82548
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4391403
Reviewed-by: Cody Northrop <cnorthrop@google.com>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
d58fbf04
|
2023-04-05T12:32:09
|
|
Vulkan: Wait for surface ANI semaphore only if image is used
Right now there is a bug that surface's ANI semaphore is added to
context when WindowSurfaceVk::getAttachmentRenderTarget get called,
which gets called from FramebufferVk::syncState, which is before we end
the previous render pass, due to the endRenderpass usually is deferred
until next renderPass starts. This caused ANI semaphore gets added to
the previous render pass's submission, which does not use surface, and
thus a bubble in GPU execution pipeline where the user FBO rendering
gets unnecessarily blocked until ANI semaphore is signaled. This lowers
GPU utilization and thus GPU frequency gets dropped and frame time
increased. This CL stores ANI semaphore to ImageHelper object and when
barrier is generated, the ANI semaphore is moved to CommandBuffer. When
CommandBuffer gets flushed and submitted, it gets added to the
waitSemaphores vector and submitted to vulkan. Since all use of swap
chain image must go through barrier code first (you need at least change
layout), this ensures ANI semaphore gets waited in exact and robust way.
Only the submission that references the swap chain image will be waited.
With this CL, professional_baseball_spirits reduces frame time from 3.8
ms to 2.7 ms, achieving parity with native GLES on pixel 7 pro.
Bug: b/275624771
Change-Id: Ifa6cacf9e3bc147bfde54eb7def2fca48c50aca0
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4400011
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
65ed3050
|
2023-04-04T11:57:38
|
|
Vulkan: Let recordWriteBarrier use CommandBufferHelper
This is preparation for next CL. It changes
OutsideRenderPassCommandBuffer argument to
OutsideRenderPassCommandBufferHelper for recordWriteBarrier() and
recordReadBarrier() calls, so that it has access to the helper object
(will be used in next CL). It passes CommandsState to executeBarriers()
instead of PrimaryCommandBuffer. No actual functionality change is
expected.
Bug: b/275624771
Change-Id: Ia06a0398a127539b0b642005803a498cb2a9d7f1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4400407
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
20f3df07
|
2023-03-30T11:36:29
|
|
Vulkan: ImageHelper::initExternal missing some variable init
When ImageHelper::releaseImage is called and then re-initialized (due to
mipmap change or usage change etc), right now we have a bug that
mCurrentShaderReadStageMask and mLastNonShaderReadOnlyLayout are still
left as is. And they do not get reset when image is initialized. This
means if the image was reinitialized again, it may end up think the new
image was previously used by fragment shader and insert an unnecessary
barrier when new VkImage is used. This was discovered when I do the
experimental work try to ghost VkImage for glTexSubImage call and
realized that new VkImage was having a strong fragment->vertex
dependency which it should not (since this is a new VkImage). This CL
initialize mCurrentShaderReadStageMask and mLastNonShaderReadOnlyLayout
and mCurrentQueueFamilyIndex from initExternal call since it is a new
vkImage.
Bug: b/273808966
Change-Id: I5bbeae5f1012f10c24620cfae8fa20365a7b5ab7
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4386136
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
9524c639
|
2023-01-17T18:47:47
|
|
Vulkan: Fix Secondary Command Buffers with asyncCommandQueue.
This change fixes following errors (asyncCommandQueue = true):
1. "vkEndCommandBuffer()" called from "asyncCommandQueue" thread.
Call stack:
vkEndCommandBuffer()
VulkanSecondaryCommandBuffer::end()
OutsideRenderPassCommandBufferHelper::flushToPrimary()
CommandQueue::flushOutsideRPCommands()
CommandProcessor::processTask()
Fixed by calling "vkEndCommandBuffer()" from the Context thread
in the new "OutsideRenderPassCommandBufferHelper::detachCommandPool()"
method.
2. "vkAllocateCommandBuffers()/vkBeginCommandBuffer()" called from
"asyncCommandQueue" thread.
Call stack:
vkAllocateCommandBuffers()/vkBeginCommandBuffer()
VulkanSecondaryCommandBuffer::initialize()
<*>CommandBufferHelper::initializeCommandBuffer()
<*>CommandBufferHelper::reset()
<*>CommandBufferHelper::flushToPrimary()
CommandQueue::flush<*>Commands()
CommandProcessor::processTask()
Fixed by calling "vkAllocateCommandBuffers()/vkBeginCommandBuffer()"
from the Context thread in the new
"<*>CommandBufferHelper::attachCommandPool()" method.
3. "SecondaryCommandPool::collect()" called from "asyncCommandQueue"
thread without synchronization.
Call stack:
SecondaryCommandPool::collect()
rx::vk::RecycleCommandBufferHelper()
CommandBufferRecycler<>::recycleCommandBufferHelper)
RendererVk::recycle<*>CommandBufferHelper()
CommandProcessor::processTask()
No need for this call, because "SecondaryCommandPool" is already
detached.
Notes:
This CL not only fixes errors, but also optimizes CommandBufferHelper
recycling. Before, there was no recycling plus unnecessary
"VulkanSecondaryCommandBuffer" allocation/freeing.
Further optimization may add multiple "VkCommandPool"s to the
"SecondaryCommandPool" to allow resetting buffers in the async thread.
Bug: angleproject:6811
Bug: angleproject:6100
Change-Id: I7004c27a112e916c5c973b43b137193017d6aa3d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4342189
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
|
|
a621ea88
|
2023-03-17T10:21:56
|
|
Adding a trace point for texture metrics.
Bug: b/236121838
Change-Id: I28e7977f7b5dc6e24cb5a2be10689c223851ba0b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4348737
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Doug Horn <doughorn@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
7d1a401b
|
2023-01-17T18:45:55
|
|
Vulkan: Fix freeing not completed Secondary Command Buffers.
Problem:
- Protected Context flushes its commands to the Protected
Primary Command Buffer;
- Unprotected Context flushes its commands to the Unprotected
Primary Command Buffer;
- Context with different "egl::ContextPriority" may flush commands
into different Primary Command Buffers.
- Secondary Command Buffers from all Contexts end-up in the single
"CommandBufferRecycler::mSecondaryCommandBuffersToReset" list;
- One of the Contexts submits its Primary Command Buffer, and attaches
current "mSecondaryCommandBuffersToReset" list to the "CommandBatch";
- Secondary Command Buffers of other Contexts may be collected and
later freed by "SecondaryCommandPool" without submitting/completion
corresponding Primary Command Buffers.
Fix:
- Moving "mSecondaryCommandBuffersToReset" to the new
"SecondaryCommandBufferCollector" class.
- Separate "SecondaryCommandBufferCollector" instance is stored
in the "CommandQueue" for each current Primary Command Buffer.
Additionally fixes "asyncCommandQueue" related problem:
"releaseCommandBuffersToReset()" may get outdated results if flush is
not yet executed in the "asyncCommandQueue" thread.
Bug: angleproject:6100
Change-Id: I7df161ac1f999fb34d4eccaebb603c58ecb1ac11
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4334579
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
|
|
|
9b6368cc
|
2023-03-14T14:48:30
|
|
Vulkan: Fix freeing Secondary Command Buffers from wrong thread.
Problem:
- Secondary Command Buffers are freed in the "CommandQueue" class.
- This may happen from any Context thread that calls
"checkCompletedCommands()" or "finish<*>()" methods.
- As the result, one Command Buffer may be freed from one thread, while
other Command Buffer from the same "VkCommandPool" is
allocated/reset/recorded in the other thread.
Vulkan spec demands external "VkCommandPool" synchronization for any
modifications (begin/end/reset/free/cmd) on its "VkCommandBuffer"s.
Fix:
- Added new "rx::vk::SecondaryCommandPool" class that replaces the
"rx::vk::CommandPool" wrapper.
- This class has "collect()" method for storing "VkCommandBuffer"s.
Collected buffers are freed from the correct thread on the next
"allocate()" call.
This CL only fixes the problem, keeping Secondary Command Buffer memory
management as is (allocate/free single buffer without reuse).
In the future CLs this behavior may be changed (reuse buffers,
reset/free entire pools).
Bug: angleproject:6100
Change-Id: If938416c4df4fe55f0cfb418b6759721ac53098b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4334577
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
4c157b4b
|
2023-03-14T18:45:38
|
|
Vulkan: Switch staging buffer to Buddy algorithm
Staging buffer should be considered as dynamic and uses buddy allocator.
Bug: b/271915956
Change-Id: I7cbe3765fdae120582034b24376560043e007e67
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4327290
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
d6a25bfa
|
2023-03-07T15:06:10
|
|
Vulkan: Optimize glBufferData call to improve storage reuse
If app calls glBufferData with certain size, then calls it again with
size 0, and then call it again with same old size again, we should try
to reuse the existing storage. When size is zero, with the existing
logic, we never free the storage. When glBufferData is called third time
with the same size as the first glBufferData call, we expect to reuse
the existing storage. But because of the storage reuse logic is
comparing buffer's new size to the old size (which is 0), we missed the
opportunity to reuse the existing storage. This CL update the reuse
logic so that it checks the new size against storage's size (instead of
OpenGLES buffer's size) and if we will end up with same sized allocation
and same pool and memory type, then we reuse instead of reallocate.
This reduces efootball_pes_2021 frame time from 4.670 ms to 4.277 ms on
pixel 7 pro.
Bug: b/271915956
Change-Id: I6f91e3e85b104eca215b28e7d0bea413ecc4401c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4317488
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
67ad3ddc
|
2023-03-06T16:44:36
|
|
Vulkan: Relax size limit for dynamicBuffer to pick buddy algorithm
If glBufferData's usage is one of the dynamic usage, app may keep
calling glBufferData frequently, which means get into suballocation code
frequently. There are two suballocation algorithms today: buddy
algorithm (faster) and generic (slower). Right now the decision of which
algorithm (i.e, which pool) to use is purely based on size or memory
type. This CL also utilize usage information so that dynamic usage will
pick buddy algorithm with bigger size threshold. mSmallBufferPool is
removed and replaced with the BufferPoolPointerArray that gets picked
based on allocation algorithm.
This CL reduces average frame time of efootball_pes_2021 from 7.518 ms
to 4.670 ms on pixel 7 Pro.
Bug: b/271915956
Change-Id: I1c2f270ac49f56e6f405501d20691cfbab49e7eb
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4313685
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
233c128b
|
2023-01-17T19:21:58
|
|
Vulkan: Fix UBs when deleted attachment is used in a RenderPass.
Problem:
- "RenderbufferVk"/"TextureVk" with "mOwnsImage == false" used as
RenderPass attachment.
- "RenderbufferVk"/"TextureVk" deleted.
- Owning resource is destroyed ("EGLImage" and all siblings /
"EGLSurface").
- Crash (UB) may happen when ending RenderPass, flushing or executing
commands.
Fix adds tracking of "vk::ImageSourceID" value in
"vk::RenderPassAttachment" - IDs of objects, that originally provide
"vk::ImageHelper" images. This is necessary, because when using
EGLImage, there may be multiple "TextureVk" objects with same
"vk::ImageHelper", and need to call "finalizeImageLayout()" for the
correct attachment.
Bug: angleproject:8032
Test: angle_end2end_tests --gtest_filter=ImageTest*DeletedWhileInUse*
Test: angle_end2end_tests --gtest_filter=PbufferTest.UseAsFramebufferColorThenDestroy*
Change-Id: I50fdd9d6b6a9677adad2262373303b46de1dee4c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4296014
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
|
|
|
244e1931
|
2023-01-17T19:22:10
|
|
Vulkan: Fix use of pending Outside RenderPass CommandBuffer.
Regression from this commit:
730c127102b540ce2c4ec086b037c8b732706e26
"Vulkan: Submit queue more often for texture data"
Bug: angleproject:6354
Test: angle_end2end_tests --gtest_filter=*SubmittingOutsideCommandBufferAssertIsOpen*
Change-Id: I5f72f499cd7153c94c8e5f8a3415df2182726c8e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4296802
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
ad7949c6
|
2023-01-17T19:24:59
|
|
Vulkan: Remove "rx::vk::ImageHelper" move constructor.
Move constructor was only used in the "rx::SwapchainImage" structure.
This CL replaces "image" member with "std::unique_ptr<vk::ImageHelper>".
This will remove source of bugs.
Bug: angleproject:8052
Change-Id: Ic16f674095233baaa56fbe8a8fb7ef3e323a7331
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4294905
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
|
|
|
dbece66f
|
2023-01-17T19:25:24
|
|
Vulkan: Fix move constructor/assignment of Resource classes.
Bug in "DynamicallyGrowingPool<Pool>::PoolResource" causes real problems
with queries. "QueryPool" may be reused without waiting for the previous
use.
Bugs "QueryHelper" may affect "mInFlightGpuEventQueries" (not used in
"QueryVk").
Updated "FramebufferHelper" move assignment so it uses "Resource"
assignment instead of protected member access.
Bug: angleproject:8053
Change-Id: I441b62102fcf232456027fb42eefa97ed8958676
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4300050
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
|
|
|
7eb6869a
|
2022-08-30T16:28:08
|
|
Vulkan: Change ResourceAccess::Write to ResourceAccess::ReadWrite
AS a preparation for the next CL which will optimize for WriteOnly
access, this CL changes Write to ReadWrite and adds WriteOnly access
(but not used yet). Mechanical changes only and no function difference
is expected.
Bug: b/243711628
Change-Id: I509d6045ae87635e24076b646af42f35d88d52cf
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3866672
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
764cdbad
|
2023-01-25T18:25:57
|
|
Vulkan: Add missing mutex lock into resetCommandBuffer().
Regression after the commit:
77d19e39794cc2de28f33a714f27af5a7de128ae
Vulkan: Add ThreadSafeCommandQueue class
Bug: b/261106868
Change-Id: I083b1bdc42a1382d32ab9087c92adbb963ff7d1e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4300869
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
|
|
|
1365f5b3
|
2022-09-09T17:19:26
|
|
Vulkan: Fix Swapchain Acquire Image Semaphore wait stage flags.
There is a screen tearing on G996B with single
"glClear(GL_COLOR_BUFFER_BIT)" no scissor in the frame.
Fixed by defining "kSwapchainAcquireImageWaitStageFlags" and
adding "VK_PIPELINE_STAGE_TRANSFER_BIT" stage flag.
Also added "VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT" stage, because first
use of the Swapchain Image after Acquire may be in the
"glBlitFramebuffer()" command.
This fix may slightly affect performance. In such case, a better fix
should be implemented (include only stages based on the actual first
use). However, this may be not trivial.
Additionally, "kSwapchainAcquireImageWaitStageFlags" is used as a source
stage mask in the "ImageLayout::Present" pipeline barrier. This is
needed in order to build a dependency chain from the Acquire Image
Semaphore to the layout transition's first synchronization scope, so
that layout transition happens after acquire semaphore is signaled.
Reference:
https://github.com/KhronosGroup/Vulkan-Docs/wiki/Synchronization-Examples#combined-graphicspresent-queue
https://vulkan-tutorial.com/Drawing_a_triangle/Drawing/Rendering_and_presentation
Alternative fix of both issues is to define:
kSwapchainAcquireImageWaitStageFlags = VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT
This might potentially delay command buffer execution relative to the
Swapchain Acquire Image Semaphore signal operations, but will relax
the pipeline barrier.
Bug: angleproject:8030
Test: angle_end2end_tests --gtest_also_run_disabled_tests --gtest_filter=EGLSurfaceTest.DISABLED_RandomClearTearing*
Change-Id: I29f58862c4b369524b2555dd944e2fb67eebe956
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4271377
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
3a7904e1
|
2023-01-25T23:56:56
|
|
Vulkan: Use VMA suballocation for images
There is a maximum limit for device memory object allocation. On some
platforms, there can be an error regarding too many object allocations
when 4096 device memory handles have been allocated. Suballocation can
help mitigate this issue. In this CL, some images will be allocated
using VMA API calls, which use suballocation.
* Added a new feature (useVmaForImageSuballocation).
* Added VMA allocation for ImageHelper, which is used in initMemory().
* Suballocation is used for VMA image allocation.
* If enabled, mVmaAllocation will be initialized in the ImageHelper
object (instead of mDeviceMemory).
* It is currently used for all platforms.
* Minor change to the name of an arg in CreateBuffer() declaration.
* Added test to make sure we can allocate at least 4096 images on
supported platforms (8000 in the test).
* Skipped the test "NonZeroBaseEmulatedClear" when run on Linux/Intel
if this feature is enabled (due to output color mismatch).
* Skipped several tests for capture/replay on Windows.
Bug: b/218891184
Change-Id: Ibf80c9c8c485b301da7d23b5ba4bcbb1a8e3194f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4191202
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
9a4a9f3f
|
2023-02-16T17:33:52
|
|
Revert "Fix dEQP-EGL.functional.mutable_render_buffer#basic"
This PARTIALLY reverts commit:
629da7fc9cd4886dd87f07a069c259551e892936.
Fix dEQP-EGL.functional.mutable_render_buffer#basic
From the reverted CL:
This CL also addresses similar issue in some other
rx::vk::ImageLayout items in kImageMemoryBarrierData.
These were unnecessary changes that may harm performance:
- adding BOTTOM_OF_PIPE for source stage when transition from
LAYOUT_UNDEFINED may add unnecessary GPU bubble.
- Transition to LAYOUT_PRESENT_SRC_KHR does not require barrier.
All writes will be automatically made visible for Presentation Engine.
Execution dependency satisfied by VkSemaphore.
- Transition from LAYOUT_PRESENT_SRC_KHR is RAR/WAR. Execution
dependency satisfied by VkSemaphore.
- Some layouts may not be a destination so BOTTOM_OF_PIPE is OK.
Bug: b/264420030
Change-Id: I8b57b1636e1f5cf5b647003adf1502bd3286c5a3
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4262067
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Reviewed-by: Charlie Lao <cclao@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>
|
|
|
8cac53cd
|
2023-01-17T19:22:57
|
|
Vulkan: Fix incorrect "SharedPresent" barrier.
Previous fix swapped top/bottom barriers:
629da7fc9cd4886dd87f07a069c259551e892936
Fix dEQP-EGL.functional.mutable_render_buffer#basic
Above fix is only partial, because it only includes execution dependency
without memory barriers (top/bottom stages has no memory access).
Fixed by forcing all possible stages for "SharedPresent" images.
Better solution requires creating specific versions
of "ImageLayout::SharedPresent".
Added new test that skips "glFlush()" before "glReadPixels()".
Performing flush executes present and may "fix" the barrier problem.
New test fails on "Samsung Galaxy S22+ S906B"
Bug: b/264420030
Test: angle_end2end_tests --gtest_filter="EGLSingleBufferTest.SharedPresentBarrier*"
Change-Id: Icbb50900d99e42d2e9482cd6109981bbc460348a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4262068
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
629da7fc
|
2023-01-26T12:25:04
|
|
Fix dEQP-EGL.functional.mutable_render_buffer#basic
These are vulkan commands submitted between
glClear() and glReadPixels() when the EGL_RENDER_BUFFER
is EGL_SINGLE_BUFFER (ImageLayour is SharedPresent):
```
vkCmdClearColorImage()
vkCmdPipelineBarrier: (
VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT,//srcStageMask
VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT,//dstStageMask
VK_ACCESS_MEMORY_WRITE_BIT,//srcAccessMask
VK_ACCESS_MEMORY_WRITE_BIT|VK_ACCESS_MEMORY_READ_BIT//dstAccessMask
)
vkCmdCopyImageToBuffer()
```
This means that operations at the bottom of pipeline
in vkCmdCopyImageToBuffer() need to wait for operations
at the top of pipeline in vmCmdClearColorImage(), which
translates to vkCmdCopyImageToBuffer() does not have
to wait for vkCmdClearColorImage() to finish.
Even the dstAccessMask ensures that
vkCmdCopyImageToBuffer() will invalidate cache before
copying image, it is possible that it will retrieve the
old Framebuffer color attachment data as the
vkCmdClearColorImage() has not finished.
This CL fixes the bug by making the srcStageMask to
be VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT and the
dstStageMask to be VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT,
when the ImageLayout is SharedPresent.
This ensures that vkCmdCopyImageToBuffer() waits for
vkCmdClearColorImage() to finish.
This CL also addresses similar issue in some other
rx::vk::ImageLayout items in kImageMemoryBarrierData.
Bug: b/264420030
Change-Id: If47ab071afaf96e396357cb0f50131339fa58509
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4198476
Commit-Queue: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
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>
|
|
ac0a4a7d
|
2023-02-03T15:34:32
|
|
Add finer memory allocation type
... so that when we hit an OOM we have better understanding on why.
Bug: b/266466279
Test: trigger a Vulkan OOM, see detailed allocation logging info
Change-Id: I71c1ebd83e18ddb22e7abfd29a785bf4ad6454dc
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4219365
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Auto-Submit: Kaiyi Li <kaiyili@google.com>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
a88d9f03
|
2023-02-07T02:37:53
|
|
Vulkan: Refactoring in RenderPassCommandBufferHelper.
This is a follow-up refactoring after CL:
cae00d9bba91bd6857d71c07b853dba8485e2ab8
Vulkan: Cleanup shared ring buffer cmd alloc feature.
"mCurrentSubpass" naming is a bit confusing.
When custom Vulkan secondary command buffers are used, "mCurrentSubpass"
is always "0". This is because custom command buffers allows storing
multiple subpasses.
This CL renames this member into "mCurrentSubpassCommandBufferIndex",
to clearly state that it is refer to command buffer index of a current
subpass. Custom command buffers will always use single buffer ("0"),
while Vulkan secondary command buffers will have a buffer per subpass.
Bug: b/256666069
Change-Id: I6777e3ca4ee57513e1c36f05f8d223eb086b095a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4227072
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
ef056a06
|
2023-01-20T14:15:48
|
|
Vulkan: Use SubmitPolicy::AllowDeferred whenever possible.
Using of SubmitPolicy::EnsureSubmitted is not necessary, because there
are finishQueueSerial() call immediately after that.
Changing to AllowDeferred avoids extra waiting call (NO-OP)
and saves some CPU cycles.
Bug: angleproject:8001
Change-Id: Id618253a4b59d006975044eb437ac60468199a98
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4194187
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
fa0681d1
|
2023-01-17T17:43:48
|
|
Vulkan: Per Context Serial cleanup.
Comment in the "OutsideRenderPassCommandBufferHelper::reset()" is
misleading. New "mQueueSerial" is always generated after
"RendererVk::flushOutsideRPCommands()". This change removes comment
and invalidates "mQueueSerial" to catch possible errors.
Call "generateOutsideRenderPassCommandsQueueSerial()" in the
"ContextVk::flushImpl()" only when needed. This call is necessary only
with empty submission with only "signalSemaphore" and NO OutsideRP
commands are written inside the "flushImpl()"
(mIsAnyHostVisibleBufferWritten or mGpuEventsEnabled).
Bug: b/267806287
Change-Id: Ibc547f97a6b38f70ad3d5901eca7b659b93014c0
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4218363
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
cae00d9b
|
2023-01-17T18:44:48
|
|
Vulkan: Cleanup shared ring buffer cmd alloc feature.
Changes:
- Simplified "SharedCommandBlockPool" interface.
Removed "ptrOut" and "usesCommandHeaderSizeForOffsetOut" parameters,
because "headerOut" has exactly the same value.
- Refactoring of "SharedCommandBlockPool" classes.
Some public methods made private, inline, or moved into ".cpp".
- Replace some getters with more specific/restrictive methods:
- "RingBufferAllocatorBuffer::getStorageSize()" -> "isEmpty()"
- "CommandBufferHelperCommon::getAllocator()"
-> "hasAllocatorLinks()"
- Added extra ASSERT()s.
- fixed typo "kMinRingBufferAllocatio(r)Capacity"
- other minor modifications.
Bug: angleproject:6401
Bug: b/256666069
Change-Id: I8f5c1c928bac5f8ecdfce7d411834f7ea39d11ac
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4218364
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
17931e23
|
2023-01-27T00:00:00
|
|
Fix stencil and depth/stencil data uploads
Multiple changes were made to depth and stencil load
functions, removing redundant code and fixing issues.
Failures were caused by incorrect assumptions about
component locations in combined formats.
* D32_FLOAT_S8X24_UINT has the same layout as
GL_FLOAT_32_UNSIGNED_INT_24_8_REV
* D24_UNORM_S8_UINT has stencil data in its MSBs,
while GL_UNSIGNED_INT_24_8 puts it in LSBs.
Bugfixes
* Added LoadD24S8ToS8D24 that swaps D24 and S8 components
* Added LoadS8ToS8X24 for stencil-only uploads on D3D
* Replaced LoadD24S8ToD32F with LoadD32ToD32F
* Fixed D and S extraction in LoadD24S8ToD32FS8X24
* Fixed stencil load and store in LoadD32FS8X24ToS8D24 and
LoadD32FS8X24ToD32FS8X24
* Fixed S8_UINT subresource updates in Vulkan
* Fixed D24_UNORM_S8_UINT subresource updates from
GL_FLOAT_32_UNSIGNED_INT_24_8_REV data in Vulkan
Cleanup
* Renamed LoadUNorm16To32F to LoadD16ToD32F
* Removed LoadUNorm32To32F, replaced it with LoadD32ToD32F
* Renamed LoadR32ToR24G8 to LoadD32ToX8D24
* Renamed LoadD32FS8X24ToD24S8 to LoadD32FS8X24ToS8D24
* Removed unused LoadG8R24ToR24G8
* Removed Metal-specific LoadS8D24S8ToD32FX24S8,
made use of the fixed LoadD24S8ToD32FS8X24 instead
* Simplifed LoadD24S8ToD32F
Added Texture2DTestES3.TexImageWithStencilData.
Fixed: chromium:1408004
Fixed: angleproject:5317
Change-Id: I231345353aa4a7cebe46ded8458ac80de2c59e01
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4203427
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
|
|
|
9a72a98e
|
2023-01-19T13:17:42
|
|
Vulkan: Fix the VVL error for shaderRead to shaderRead barrier
When we use image from fragment shader read to vertex shader read, we
detect the case (same layout with only shader stage change) and just
merge the barrier into one. But that can only done if these two usages
are for the same render pass. If it is different render pass, then you
still have to issue a new barrier. Previously there is no way to detect
that the barrier was issued for which render pass. With the fix in
crrev.com/cl/4136948, we now know which render pass issued the last
barrier. With that we are able to limit the shader stage consolidation
only if they are for the same render pass, thus fixing the VVL errors.
Bug: angleproject:6663
Change-Id: I3d884336e8cf1f3cf16fc3e5a3423357ae2ed3c1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4182542
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
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>
|
|
|
48e40ef6
|
2023-01-06T13:35:21
|
|
Add per-heap memory allocation trackers
* For each member of MemoryAllocationType, we now have a per-heap
counter to keep track of the allocation size in each available heap.
* mActivePerHeapMemoryAllocationsSize
* mActivePerHeapMemoryAllocationsCount (debug mode only)
* Added the memory type index to onMemoryAlloc() and onMemoryDealloc()
as an input. It can then be used to determine the used memory heap
index for that allocation using the memory properties defined in the
renderer.
* checkForCurrentMemoryAllocations() will now log the heap index of the
current memory allocations in debug mode and during an OOM crash.
* logPendingMemoryAllocation() will now log the heap index of the
pending allocation during an OOM crash.
* Renamed constexpr values used for tracking for more consistency.
* kTrackMemoryAllocation -> kTrackMemoryAllocationSizes
* kDebugMemoryAllocationLogs -> kTrackMemoryAllocationDebug
Bug: b/262029018
Change-Id: I178a3556b3107edc0c72c6b23ea2f2d6b12da947
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4149431
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Ivan Neulander <ineula@google.com>
|
|
|
410d8ba5
|
2022-12-21T13:27:00
|
|
Vulkan: Cleanup ContextVk::hasStartedRenderPass APIs
ContextVk has a few hasStartedRenderPass APIs which interpret "start"
inconsistently. A RenderPassCommands' life should be notStarted,
started, requestEnd, and end (which is equivalent to notStarted). When
someone calls onRenderPassFinished on a started renderpass, it does not
immediate endRenderPass, but it will set DIRTY_BIT_RENDER_PASS dirty bit
so that next draw call will trigger endRenderPass and start a new
renderPass. We do not have a name for this state, which adds some
confusion. This CL renames the stage between start and
onRenderPassFinished to be "active" renderpass, when you have
mRenderPassCommandBuffer pointer being valid and you can actively adding
draw commands into the renderPass. For this purpose, I haves renamed
hasStartedRenderPass to hasActiveRenderPass. This CL also simplifies
hasStartedRenderPass implementation to only check
mRenderPassCommandBuffer and turned mRenderPassCommands.started as
assertion. This CL also changes hasStartedRenderPassWithQueueSerial to
actually check mRenderPassCommands.started instead of being "active", so
that name reflects what it is actually checking. This CL also changed
hasStartedRenderPassWithCommands to hasActiveRenderPassWithCommands to
make name and implementation consistent. One added benefit of this is
that after this CL we now allow load/store optimization on a started but
inactive renderPass as well (for example glInvalidateFramebuffer call
after glFenceSync call, or invalidate after FBO blit as demonstrated by
MultisampleResolveTest.ResolveD32FSamples tests).
Bug: angleproject:7903
Bug: angleproject:7551
Change-Id: I8c8ec4c0d54b9ad0a9e373108dfce6b151c8fe0e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4119693
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
f1872822
|
2022-12-22T17:17:37
|
|
Vulkan: Fix imageless framebuffer VVL issue
In some tests, including some blink tests, there were cases of VVL
messages spamming the output log, even though they did not always
cause a failure. Investigation showed that in some cases, the call
to EGL_CreateImageKHR() was not setting all the attributes in the
ImageHelper object that is used later for an imageless framebuffer,
specifically the one created in VkImageImageSiblingVk::initImpl().
* Added the usage flags and view formats in the new image created in
VkImageImageSiblingVk.
* Added a Vulkan image test to make sure the error is fixed.
Bug: b/261473248
Bug: angleproject:7845
Change-Id: I1874b2930e9ce62e5b603cf7acff6fd78b957d5b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4117584
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
26e28089
|
2023-01-04T15:15:46
|
|
Vulkan: Improve RPCommandHelper::isImageWithLayoutTransition()
RenderPassCommandBufferHelper::isImageWithLayoutTransition() was added
in crrev.com/c/3366014 to detect if there is a barrier inserted for the
renderPass. If yes, we have to endRenderPass before compute shader,
since compute dispatch goes into outsideRenderPassCommands, which writes
into primary command buffer before renderPassCommands. Otherwise the
compute dispatch will be using the image before the actual layout
transition occurs, which is wrong. But to detect if the image has a
layout/barrier transition in the renderPass, it maintains an
angle::FlatUnorderedSet. With recent change for per active context queue
serial, we can use the queue serial to detect this. This CL adds a
queueSerial for image layout/barrier change and compares it with
RenderPassCommands' queueSerial to decide if the renderPass has a
layout/barrier for the image.
This CL also did some minor clean ups: Removed unused API
ContextVk::getActiveImages(). Removed writtenByCommandBuffer() check in
CommandBufferHelperCommon::bufferWrite() before calling
setWriteQueueSerial, since the check is more expensive than set. Added
setQueueSerial call in OutsideRenderPassCommandBufferHelper::imageWrite
to be consistent with imageRead. (This might be fixing a bug here).
Replaces a few retainResource(image) to image->setQueueSerial for
consistency.
Bug: b/264472911
Change-Id: I74badd6b8a35f86640e42d330a1a709ccfb961c3
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4136948
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
2662f28f
|
2022-12-30T17:26:22
|
|
Vulkan: Fix imageRead from RP and outsideRP simultaneously
When a texture is been sampled from both fragment shader and compute
shader, you will have the same VkImageLayout. We will not try to end
renderPass, which means you end up running into similar situations with
OutsideRenderPassCommandBufferHelper::bufferRead where an image is
already read accessed by a started renderPass and now read accessed by
an outsideRenderPassCommands. Since renderPass has greater queueSerial,
we should not tag it with outsideRenderPassCommands' queueSerial.
This CL also adds two tests, one for color texture and another for
depth texture (which is car_chase uses). Both exposes the same bug.
Bug: angleproject:7916
Change-Id: I840ca8947caeb7a96c4c9ccb7c9eca2476837c9c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4133548
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
6c41793f
|
2022-12-20T15:20:50
|
|
Vulkan: Use read/write depth/stencil layouts
This allows an application to have depth in read-only feedback loop
while stencil is being written to for example.
Bug: angleproject:7899
Bug: b/192477489
Change-Id: Ic2e11d32da7c7e3a7f3cd86dbafc5c56a0dbbfd7
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4116730
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
295f6830
|
2022-12-21T10:56:03
|
|
Vulkan: bufferRead should accommodate deferred endRenderPass
ContextVk::onSyncObjectInit() will request end of current renderPass but
deferred (in this case, mRenderPassCommandBuffer is nullptr but
mRenderPassCommands->started() still returns true). The next draw call
will actually end current renderPass and starts a new renderPass. But if
next call is glCopyBufferSubData, it will not actually trigger
endRenderPass. This CL modifies
OutsideRenderPassCommandBufferHelper::bufferRead logic to accommodate
this deferred endRenderPass scenario by checking
mRenderPassCommands->started() instead of hasStartedRenderPass so that
the answer to "if this buffer been used by current renderPass or not"
will return correct result.
Bug: angleproject:7903
Change-Id: Ie5c9977ccf083e7d355a2cd8fd08e9077049ee9a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4119692
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
626b10c1
|
2022-12-20T20:22:19
|
|
Vulkan: Add read/write depth/stencil layouts
This CL only adds the layouts in the list, but does not use them. The
layouts are renamed for consistency in this change.
Bug: angleproject:7899
Bug: b/192477489
Change-Id: I47986c7252d32626e9f26c6670c0a4e3496fe0c8
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4116736
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
301ed545
|
2022-12-20T20:16:22
|
|
Vulkan: Pass context to layout getters
In preparation for a change that optionally uses read/write
depth/stencil layouts. Context is used to test for the
supportsMixedReadWriteDepthStencilLayouts feature to know whether those
layouts are supported or that a fallback must be chosen.
Bug: angleproject:7899
Bug: b/192477489
Change-Id: I1453dc9d060453a3806ad0f261b94368fe01fb29
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4116735
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
5c8c0347
|
2022-12-15T15:46:38
|
|
Vulkan: Remove ContextVk::retainResource and retainImage()
Clean up some retain* APIs. retainImge and retainReadOnlyResource and
retainResource are doing exact same thing, they are consolidated into
just retainResource. ContextVk::retainResource is removed since mUse
can now safely copied from DescriptorSetHelperPool object which tracks
mUse.
Bug: b/262047600
Change-Id: I56ea08696e870826bd94ccb79dd621f35923bc6a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4114500
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
376d309c
|
2022-12-15T09:43:00
|
|
Vulkan: Remove unnecessary usesBuffer() check
There are places that we call setQueueSerial after usesBuffer() check.
This was useful when we had the ResourceList where it is more expensive
to set serial. But now setQueueSerial is cheap (actually is cheaper than
usesBuffer check), so there is no need to do this check any more. This
CL removes the check to further reduce the CPU overhead. Because of
this, mUsedBufferCount will not be accurate, so this CL also removes the
tracking of mUsedBufferCount (was only for informational purpose
anyway).
This CL also removes commandBufferQueueSerial.valid() check in
Resource::usedByCommandBuffer() and turns it into assertion. Some places
in contextVk will ensure we only call it on started renderpass so that
other places that calls usedByCommandBuffer will not need to eat the if
check.
Bug: b/262047600
Change-Id: I6b8004b6aa5b567fa94c0eb56801054f818838b1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4112145
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
cd367796
|
2022-12-12T15:10:09
|
|
Vulkan: Add assert to ensure never setQueueSerial backwards
This CL add an assertion in ResourceUse::SetQueueSerial to ensure that
we never set a serial smaller than what it already has. If that happens,
we could potentially destroy it while GPU still accessing it. With this
assertion, it exposed a bug that when a buffer is read accessed by a
renderpassCommands and then read accessed by outsideRenderPassCommands,
we were incorrectly setting the queueSerial with outsideRP's serial,
overwriting the queueSerial already set by renderPassCommands. To fix
this, this CL detects this case and keeps the queueSerial set by
renderPassCommands.
Bug: b/262047600
Change-Id: I51b17ab4a93bccd0d0b079784af96cef9d79f16f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4099804
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
77c95de4
|
2022-11-16T21:12:28
|
|
Vulkan: Threaded monolithic pipeline creation
With this change, once a pipeline is created out of libraries, a task is
scheduled (if necessary) to asynchronously create a corresponding
monolithic pipeline. Once the task is complete, the linked pipeline
handle is replaced by the monolithic one, gaining back any performance
that might have been lost due to the use of libraries.
Bug: angleproject:7369
Change-Id: I525fb1e09f8bedc61b9dbef19f9cce7026ff9c53
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4031151
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
89cd8583
|
2022-12-12T11:23:59
|
|
Vulkan: Clean up Resource class
Resource::retainCommands() API name no longer make sense. This CL
removes retainCommands and retainReadOnly and retainReadWrite APIs and
replaced with setQueueSerial and setWriteQueueSerial call directly.
This CL also merges some of single inline functions to minimize the
file, sine the class is small anyway.
Bug: b/262048658
Change-Id: I9d16b82c79b27f3285311393601705a4ee7f6d8a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4098005
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
f3ebb2ca
|
2022-12-08T17:02:12
|
|
Vulkan: Better mUse tracking for DynamicallyGrowingPool<Pool>
This is used only from DynamicallyGrowingPool<Pool>::onEntryFreed to set
the its tracking QueueSerial. There is better way to do this now with
per context serial. We can simply merge the QueryHelper's mUse into the
pool instead of setting pool's use to the current queueSerial. The
benefit of doing that is to possibly allow pool gets reuse/freed earlier
(i.e., more accurate tracking). This CL switches it to more accurate
tracking and removes mCurrentSerial from Context.
This CL also removes unused DynamicSemaphorePool class.
Bug: b/262054987
Change-Id: Iac3e2495cc0e3623ba63e9da7f32ad6e9c223467
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4089847
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
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>
|
|
|
f8980c98
|
2022-12-08T11:51:42
|
|
Vulkan: Make ReadWriteResource subclass from Resource
To simplify the code slightly. The main reason for this is that the two
class variables of ReadWriteResource totally does not make sense:
mReadOnlyUse actually manes any usage, read or write. mReadWriteUse
actually means write usage.
Since Resource class's mUse means any access, subclass ReadWriteResource
from Resource class makes more sense since mUse means exact same thing
in both classes.
This CL also changes ReadQriteResource::mReadWriteUse to mWriteUse.
Bug: b/262048658
Change-Id: I0e3172a70b8cb6a6481045c46690b69fbfe9523c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4089983
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
6830b7d3
|
2022-11-23T11:51:28
|
|
Vulkan: Use finishQueueSerial for queueSubmitOneOff
Right now for oneoff submission we are creating a fence and pass in the
fence and then wait for fence outside the normal wait code path. This
creates a problem that the command buffer and garbage clean up code does
not gets run and may end up hitting assertion. This might be necessary
before because complication with ResourceList. With recent work that
removes ResourceList, this can be much simpler now. This CL removes the
fence creation and wait in the oneoff submission code path (except the
external fence) and switch to finishQueueSerial call.
Bug: b/255414841
Change-Id: I2b16c187becbda9c2397685c7212abac994e8dc2
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4053261
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
1219f55a
|
2022-12-07T16:19:37
|
|
Vulkan: Remove Resource::isCurrentlyInUse
Due to header file include order, this function can not directly
made inline. This CL removes the function and replace it with
renderer->getUnfinishedUse() to reduce one extra function call of one
line function.
Bug: b/262048658
Change-Id: Ied33b63d0ec88336a5ce42cf7726f16b2b883b86
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4089623
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
02cc4cd5
|
2022-12-07T12:03:26
|
|
Vulkan: Remove ImageHelper::mImageAndViewGarbage
This was introduced in crrev.com/c/3449450. At that time this is
necessary, because we can not copy mUse for immediate view garbage
collection. Now with recent work, mUse is copyable, we no longer need to
accumulate the view garbage. They can be released immediately with a
copy of image's mUse.
Bug: b/261737134
Change-Id: Ic4393f8c4ee7c0e3be4669a0a557507c909a77ab
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4087323
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
1193b664
|
2022-10-11T01:00:40
|
|
Vulkan: Use VK_EXT_pipeline_protected_access
This extension allows pipelines to be restricted to protected or
unprotected command buffers only.
Bug: angleproject:7714
Change-Id: Id07be4c2ffd7ca19b8b4a2a869828bc11e89e467
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3943535
Reviewed-by: Charlie Lao <cclao@google.com>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
8181c056
|
2022-11-22T15:34:48
|
|
Vulkan: Remove RenderPassSerial
RenderPassSerial was introduced to uniquely identify a
RenderPassCommands. With the work of per current context queue serial,
now every started RenderPassCommands already have a unique QueueSerial.
This CL removes RenderPassSerial and use renderPass's queueSerial
instead.
Bug: b/255414841
Change-Id: Id0a87319a9132cdb74aba195f1f05aa31454592b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4049966
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|