|
49d0a332
|
2025-04-08T16:07:17
|
|
Vulkan: Remove ring buffer allocators
* Removed the ring buffer allocator functionality from ANGLE:
angle::RingBufferAllocator
* Also removed the related common files.
* (Pool allocators will be used at all times.)
* Removed the placeholder functions from the pool allocator.
* Removed the following BUILD flag:
angle_enable_vulkan_shared_ring_buffer_cmd_alloc
* Removed redundant line from ContextVk.
Bug: b/410036490
Change-Id: I368fb93a66ddfd192018b09f65004a32339abd5a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6442640
Reviewed-by: Igor Nazarov <i.nazarov@samsung.com>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
c1214ec2
|
2025-01-22T14:22:56
|
|
Vulkan: Rename Context to ErrorContext
In preparation for adding another Context (derived by GL and CL
contexts), which includes logic that pertains to command recording (such
as barrier tracking).
Bug: angleproject:390443243
Change-Id: Idf495b62e63fb9aa901a2f16447fdaf3c2acd90b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6191248
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
44b6203c
|
2024-09-02T16:23:44
|
|
Add new functions defined in VK_KHR_Synchronization2 extension
Add vkCmdPipelineBarrier2 and vkCmdWriteTimeStamp2.
The other functions introduced in VK_KHR_Synchronization2
are not being used at the moment.
Bug: b/356985874
Change-Id: I4f8b432aee9b11debcb8abe8b3089f88ad7a069b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5832709
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Yuxin Hu <yuxinhu@google.com>
|
|
|
1db80b88
|
2024-07-10T12:47:42
|
|
Reland "Vulkan: Use VK_KHR_dynamic_rendering[_local_read]"
This is a reland of commit c379ff48043a47e444c388c45270db40d3172d50
Original change's description:
> Vulkan: Use VK_KHR_dynamic_rendering[_local_read]
>
> Bug: angleproject:42267038
> Change-Id: I1f4eb0f309992a9c1c287a69520dadf5eff23b26
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5637155
> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
> Reviewed-by: Charlie Lao <cclao@google.com>
Bug: angleproject:42267038
Change-Id: I083e6963b5421386695e49a9872edbb2016c9763
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5691342
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
7d461b21
|
2024-07-10T14:11:53
|
|
Revert "Vulkan: Use VK_KHR_dynamic_rendering[_local_read]"
This reverts commit c379ff48043a47e444c388c45270db40d3172d50.
Reason for revert: Regresses CPU perf and memory when _not_ using DR
Original change's description:
> Vulkan: Use VK_KHR_dynamic_rendering[_local_read]
>
> Bug: angleproject:42267038
> Change-Id: I1f4eb0f309992a9c1c287a69520dadf5eff23b26
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5637155
> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
> Reviewed-by: Charlie Lao <cclao@google.com>
Bug: angleproject:42267038
Change-Id: I3865f0d86813f0eeb9085a92875a33bd449b907f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5691337
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
c379ff48
|
2024-06-10T22:01:57
|
|
Vulkan: Use VK_KHR_dynamic_rendering[_local_read]
Bug: angleproject:42267038
Change-Id: I1f4eb0f309992a9c1c287a69520dadf5eff23b26
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5637155
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
d30e4772
|
2024-02-02T14:13:33
|
|
Vulkan: Add VkCmdWaitEvents for image barriers
This CL add EventBarrierArray (sister class of PipelineBarrierArray)
that accumulates the event barriers instead of pipeline barriers.
ImageHelper::barrierImpl and ImageHelper::updateLayoutAndBarrier has
been updated to have a code path that inserts waiting event to
EventBarrierArray. PipelineBarrier code path is still kept and is also
used when event is invalid or under certain situation as a fallback
method from waitEvent. After we generate barrier (regardless it is
pipelineBarrier or eventBarrier, we always release
ImageHelper::mCurrentEvent. When next barrier/layout call is made, if we
see mCurrentEvent is invalid, we always fallback to pipelineBarrier.
This way it is safe that if somehow we did not (intentionally or
accidentally) insert a new event between two barrier calls, we will not
end up with second barrier call wait for old event which creates
synchronization hazard. With this approach, second barrier will use
pipelineBarrier which is still safe.
In this CL the useVkEventForImageBarrier feature flag is still disabled,
so no events are created and thus pipelineBarrier is still used.
Bug: b/336844257
Change-Id: Idaf5a7200b85f901eae5d376543f189d21522022
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5263701
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
6607a2b9
|
2024-01-17T15:58:20
|
|
Vulkan: Add support for VK_EXT_vertex_input_dynamic_state
Hook into VK_EXT_vertex_input_dynamic_state so pipeline states
that differ only in vertex input state can reuse existing
pipelines.
Bug: angleproject:7162
Tests: StateChangeTestES3.Vertex*
Change-Id: Icd3134dee93fc5fc2e9d284fcfa8c674b62faec8
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5207462
Commit-Queue: mohan maiya <m.maiya@samsung.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
dbc6bd9d
|
2024-02-12T14:07:49
|
|
Reland "Vulkan: Fix alignment issues with SecondaryCommandBuffer"
This is a reland of commit e53270c9ca1afe393d6d7d0359e81cf6755b6ca5
Original change's description:
> Vulkan: Fix alignment issues with SecondaryCommandBuffer
>
> This solves undefined behaviour on 64-bit systems. This inflates the
> size of a few commands, but most commands either already did align to 8
> bytes or could be aligned to 8 bytes with a few tweaks.
>
> Bug: angleproject:7852
> Change-Id: Ie61976d5bf8df7790acd95c0e15d4c79402622a1
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5288636
> Reviewed-by: Charlie Lao <cclao@google.com>
> Reviewed-by: Yuxin Hu <yuxinhu@google.com>
> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Bug: angleproject:7852
Change-Id: Ie206e66fc21c5db7c9e67eb478d9cddada5db8e0
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5296376
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuly Novikov <ynovikov@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>
|
|
|
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>
|
|
|
fee173f9
|
2023-01-17T18:45:41
|
|
Vulkan: Fix freeing Command Buffers with wrong Pool.
Problem:
- Multiple Contexts flushes it's commands to the Primary Command buffer;
- Secondary Command Buffers from all Contexts end-up in the single
"CommandBufferRecycler::mSecondaryCommandBuffersToReset" list;
- One of the Contexts submits all these commands, and attaches
it's "VkCommandPool" to the "CommandBatch".
- This "VkCommandPool" will be used to free "VkCommandBuffer"s
from all Contexts and pools.
Fix:
- Attaching "VkCommandPool" to each "VulkanSecondaryCommandBuffer"
instance.
- "vkFreeCommandBuffers()" is called from the new
"VulkanSecondaryCommandBuffer::free()" method.
Bug: angleproject:6100
Change-Id: Ic4d66d8b0f71e5ff06047004ed21428d6dce385b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4300870
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
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>
|
|
|
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>
|
|
8b60855b
|
2021-09-15T15:16:10
|
|
EGL: implement EGL_KHR_mutable_render_buffer
Pass render buffer mode change to WindowSurfaceVk.
On mode change trigger OUT_OF_DATE. Then in CreateSwapchain,
if new mode, set the Presentation mode and the Image count.
OffscreenSurfaceVk ignores mode change.
Add MUTABLE_RENDER_BUFFER_BIT to GenerateDefaultConfig.
Test: dEQP-EGL.functional.mutable_render_buffer.*
Bug: angleproject:3966
Change-Id: I7b59708514bcda10f8d45ce5f9528aa840fcccfa
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3171822
Commit-Queue: Brandon Schade <b.schade@samsung.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
558981c1
|
2021-11-10T23:13:03
|
|
Vulkan: Make write-after-invalidate checks more precise
Previously, the size of the command buffer was used as indication for
whether the render pass attachments might have been modified after
glInvalidateFramebuffer. In that case, the invalidate was undone. This
is made more precise by making sure only vkCmdClearAttachments and
vkCmdDraw* calls are counted for this purpose.
For example, inserting event markers after glInvalidateFramebuffer now
retains the invalidation.
Note that this can be even further optimized by tracking real writes to
attachments. For example, currently a draw call with depth test
disabled still undoes the invalidation of the depth buffer, but it
shouldn't.
Bug: angleproject:5079
Change-Id: I6257b4116a73213884b919bc7f3c86ff39b6aeed
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3274176
Reviewed-by: Ian Elliott <ianelliott@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
d134581b
|
2021-10-07T16:09:25
|
|
Vulkan: Remove SyncHelper::mEvent
Now that inserting a sync object incurs a flush, we can use the serial
to perform synchronization.
Bug: angleproject:6464
Bug: angleproject:6481
Change-Id: I8c82a12855b6497861ce34854d165af82956b384
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3212573
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
|
|
|
2f1d503b
|
2021-09-16T21:49:14
|
|
Vulkan: Fix Vulkan secondary command buffers
This change abstracts initialization, begin/end, reset and recycle of
command buffers such that both Vulkan and ANGLE secondary command
buffers are supported.
Bug: angleproject:6100
Change-Id: I8c79764ac98b599fda08fe45cf8c4f0a6573f0f9
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2987873
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|