|
7adbb3e8
|
2024-11-26T17:06:07
|
|
Vulkan: Remove explicit destroy calls
Since now SharedPtr will automatically call destroy(device) when last
reference goes away, there is no need for explicitly calling
destroy(device) any more.
Bug: angleproject:372268711
Change-Id: I208b17cf7e090babd51d6f337c20fdfd74c75b6b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6052886
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
d81834b6
|
2024-11-26T15:25:35
|
|
Vulkan: Store VkDevice in vk::SharedPtr
So that we don't need to have two versions of destroy() APIs. In
previous CLs I had to add another version of destroy() that does not
take device argument due to SharedPtr may calls destroy when last
reference count goes away. Because we do not have device information at
that time, destroy() API was added but mostly just doing assertion that
Vulkan object has been explicitly destroyed. With this CL, we now stores
device in the SharedPtr so that we no longer need two destroy() APIs.
The explicit destroy(device) call will be removed in the next CL.
Bug: angleproject:372268711
Change-Id: Idcacbc3a922e17ac3d0f6056466b8f3aa084b02e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6052096
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
f51170b3
|
2024-11-21T16:30:40
|
|
Enable GL_KHR_texture_compression_astc_hdr
Vulkan supports GL_KHR_texture_compression_astc_hdr,
so this extension can be enabled in Angle.
Bug: angleproject:379186304
Change-Id: I438a120c3f884a7eefcd883ad71abf68f81cb473
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6038457
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
01dee1cb
|
2024-10-14T15:04:28
|
|
Add implementation for GL_EXT_texture_storage_compression
Bug: angleproject:352364583
Change-Id: I3dab4c68d5d0206d681e165e991217bd3de8eeb6
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6011055
Auto-Submit: Neil Zhang <Neil.Zhang@arm.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
6c1021ec
|
2024-11-22T16:48:45
|
|
Vulkan: Switch DescriptorSetLayout to use AtomicSharedPtr
SharedPtr has better semantics and safer to use. This CL removes direct
exposure of RefCounted object and also allows me to delete
BindingPointer class in later CL.
Bug: angleproject:372268711
Change-Id: I08a0dff3efcf794be843a4a548b9f2609bb9a5e1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6044328
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
87d61997
|
2024-11-21T14:20:55
|
|
Vulkan: Switch ShaderModule to use SharedPtr
This CL gets rid of many vk::RefCounted<vk::ShaderModule> usage which is
risky due to it allows you to direct manipulate reference count. Switch
to vk::SharedPtr manages the reference counting automatically.
Bug: angleproject:372268711
Change-Id: I14f5c509bcbd9ea7d17101637e033652a68710a0
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6039117
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
2e25ea1e
|
2024-11-13T13:59:51
|
|
Add a new mutex in CommandQueue to protect Vulkan Command Pool
Before this change, the CommandQueue::mMutex protects both:
1. Members of CommandQueue class, e.g. mInFlightCommands.
2. Operations on the same command pool and command buffers allocated
from the same command pool.
If one thread accesses resources 1, the other thread is doing operations
in 2, they could be blocked by each other. For example, if thread 1
calls eglClientWaitSync() to check if certain commands finish execution
(accessed resources in 1.), while thread 2 calls
eglMakeCurrent() to flush commands (issue operations in 2.), thread 1
could be blocked by thread 2. This is against the egl spec where
eglClientWaitSync() should return immediately when timeout passed to
the call is 0.
To fix the problem, this change creates a new class CommandPoolAccess
that wraps operations in 2, and protects command pool and command buffer
operations with a new mutex mCmdPoolMutex. With this new mutex, thread 1
and thread 2 would take different locks and not blocked by each other.
Bug: b/362604439
Change-Id: Iccf0ae65809ccb0f593c5e318fde03e89e0c0fa3
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6020895
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Yuxin Hu <yuxinhu@google.com>
|
|
|
21d747de
|
2024-11-20T11:54:15
|
|
Vulkan: Use vk::SharedPtr for SharedDescriptorSetCacheKey
This CL switches SharedDescriptorSetCacheKey from using c++
std::shared_ptr to our internal version of vk::SharedPtr. Also get rid
of an extra pointer indirection that SharedDescriptorSetCacheKey is a
reference counted of actual cache key instead of std::unique_ptr of
cache key.
Bug: angleproject:372268711
Change-Id: Id9af5070d24f67711d6decc3a30a260b8d4062d9
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6036302
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
ce53aff0
|
2024-11-05T16:57:57
|
|
Vulkan: Add per descriptorSet LRU cache eviction
Before this CL, the descriptor set cache eviction is at the pool level.
Either the entire pool is deleted or not. It is also not LRU based.
This CL adds a per descriptor set cache eviction and reuse evicted
descriptorSet before allocating a new pool. This eviction is LRU based
so that it is more precise. The mCurrentFrameCount is passed into
various API so that it can make eviction decision based on the frame
number. In this CL, anything not been used in last 10 frames will be
evicted and recycled before allocate a new pool.
Since eviction is based on individual descriptor set, not by pool,
ProgramExecutableVk no longer needs to track the DescriptorSetPool
object. mDescriptorPools has been removed from ProgramExecutableVk
class.
As measured by crrev.com/c/5425496/133 This LRU linked list maintenance
does not add any measurable time difference, but reduces total
descriptorSet pool count by one third (from 75 down to 48).
running test name: "TracePerf", backend: "_vulkan", story:
"batman_telltale"
Before this CL:
cacheMissCount: 200, averageTime:23998 ns
cacheHitCount: 1075445, averageTime:626 ns
descriptorSetEvicted: 0, descriptorSetPoolCount:75
Average frame time 3.9262 ms
After this CL:
cacheMissCount: 200, averageTime:23207 ns
cacheHitCount: 1025415, averageTime:602 ns
descriptorSetEvicted: 102708, descriptorSetPoolCount:48
Average frame time 3.9074 ms
BYPASS_LARGE_CHANGE_WARNING
Bug: angleproject:372268711
Change-Id: I84daaf46f4557cbbfdb94c10c5386001105f5046
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5985112
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
987cc0de
|
2024-08-06T12:16:37
|
|
Vulkan: Add release utility for BufferViewHelper
Add a release helper that doesn't require ContextVk for
BufferViewHelper.
Bug: angleproject:378103913
Change-Id: Ib468d152501ecaec1dd71c9c6ed5527b73a1afa5
Signed-off-by: Gowtham Tammana <g.tammana@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6004686
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
f44427b5
|
2024-11-05T15:18:59
|
|
Vulkan: Fix MSAA glReadPixels into PBOs
The temporary image used to resolve the MSAA framebuffer during
glReadPixels did not have the SAMPLED usage bit. Additionally, the
image was supposed to be garbage collected afterwards but ImageHelper's
release() function was accidentally immediately destroy()ing it.
This was not an issue with blocking glReadPixels paths, because the
command buffer was immediately flushed and the GPU work was waited on
before the image was destroyed in RendererScoped's destructor.
Bug: b/377437834
Change-Id: I1dca47172d6f363277059a848fe9446ac2a872d4
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5995530
Commit-Queue: Charlie Lao <cclao@google.com>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
e2cd9082
|
2024-11-05T04:07:17
|
|
Vulkan: Bugfix in setCurrentImageLayout
Make sure to update mLastNonShaderReadOnlyLayout and
mCurrentShaderReadStageMask when updating the current layout.
Bug: angleproject:40644776
Change-Id: Ie8652099a0d4caca9f9aea5bac38256a513b08e7
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5992020
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
|
|
|
79b6c7ab
|
2023-10-09T13:29:07
|
|
CL/Vulkan: Add fillWithPattern interface
In CL, the buffer can be requested to filled with a pattern. Adding a
pattern fill helper routine that fills up the buffer from CPU side.
Bug: angleproject:42267074
Change-Id: I144e9b7c6f4d1263f21cabc2491c46e8951e604f
Signed-off-by: Gowtham Tammana <g.tammana@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5916157
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
6b9d3762
|
2024-08-22T15:29:00
|
|
Vulkan: Optimize full texture clears
Currently, a full texture clear (glClearTexImageEXT()) is treated as
a special case of a partial clear (glClearTexSubImageEXT() with image
dims as the input). However, it can be further optimized by treating
it as a clear update.
* For full clears from EXT_clear_texture, the clear update path is
taken.
* It leads to a more optimized path, including the usage of the
following APIs:
* vkCmdClearColorImage()
* vkCmdClearDepthStencilImage()
* It uses the following enum: ClearTextureMode
* If a partial clear uses the extents for the entire image, it is
treated as a full clear.
* Updated the method to determine if a texture is renderable in
clearSubImageImpl().
* Added perf counter: fullImageClears
* Added new unit tests
* Single 3D texture full clear (Clear3DSingleFull)
* 2D RGB SNORM clear (Clear2DRGB8Snorm)
* Added Vulkan perf counter test for 2D and 3D color image clear.
* Updated the related skipped tests on Pineapple.
Bug: angleproject:42266869
Bug: angleproject:375425839
Change-Id: I12ef3002dee190d7f8f43204f7d3f76e05d0b54f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5806207
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
d0a0fd1a
|
2024-10-17T14:50:51
|
|
Vulkan: Skip pool eviction when cache is disabled
When cache is disabled, every time a new descriptorSet is allocated and
bind to program, the previous descriptorSet will be added to the tail of
garbage list, and the new descriptorSet is retrieved from the head of
the garbage list, if its GPU usage has been completed. This means there
will never have a situation that significant amount of descriptorSets
are needed, therefore no need for pool eviction. One possible situation
is that at one point you need a lot of descriptorSets and then after a
while you only need small amount of descriptorSets. In that case we
could delete the excessive unused descriptorSets. But since they are all
allocated from a pool, as long as there is still one descriptorSet in
the pool is used, you still can't destroy the pool. This means eviction
is really not much useful when cache is disabled.
Bug: angleproject:372268711
Change-Id: Id77b181b64e122f576ee43d11c39dc75bd681dcf
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5941126
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
af73a7eb
|
2024-10-18T17:19:29
|
|
Vulkan: Add WeakPtr to mirror std::weak_ptr
This is a follow up from previous CL crrev.com/c/5938947. Because of
pool eviction is based on reference count, there is need to have a weak
pointer to the reference counted pool that does not add an extra
reference count. This CL adds WeakPtr that works similarly to
std::weak_ptr, and replaced direct RefCountedDescriptorPool pointer with
WeakPtr wrapper. This is safer than RefCountedDescriptorPool in a way
that it does not allow modification of underline reference count. Also
the use of WeakPtr has been reduced to minimum in this CL.
Bug: angleproject:372268711
Change-Id: Idd6fa77432a9351269c968c961785a7cf5fab50c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5944061
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
08c1724f
|
2024-10-11T14:29:00
|
|
Vulkan: Support GL_ARM_shader_framebuffer_fetch_depth_stencil
Bug: angleproject:352364582
Change-Id: I63fd78314fa7ebccbf366c252e309a9c0f09c8c1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5938150
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
65fcf9c4
|
2024-10-26T10:53:18
|
|
Vulkan: Remove redundant dependent feature checks
Since [1], when a feature is overriden, the dependent features
automatically take the override into account. Tests no longer need to
account for dependent features, neither does the logic in the code.
[1]:https://chromium-review.googlesource.com/c/angle/angle/+/4749524
Bug: angleproject:42266725
Change-Id: I5440aba4a89cffbe710e26ad7de4cfee783e9bdf
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5967414
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
2dcc80dd
|
2024-10-17T13:59:23
|
|
Vulkan: allocateDescriptorSet to avoid repeated try on same pool
DynamicDescriptorPool::allocateDescriptorSet has a few steps. It first
tries to allocate from the same pool. Then tries to allocate from
mCurrentPoolIndex and then loops all existing pools. This CL keeps the
same basic logic, but avoids repeated tries on the same pool.
Bug: angleproject:372268711
Change-Id: Ic3099ac8c68688fe9afe452f808be29ac9063d51
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5926182
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
9a4c7495
|
2024-10-15T13:05:28
|
|
Vulkan: Add feature flag to enable descriptorSet cache
So that we can disable it to compare the performance difference.
Bug: angleproject:372268711
Change-Id: I02da254e5d58815741080634a2dd005617aa7432
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5936135
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
dd54eeec
|
2024-10-11T13:26:46
|
|
Reland "Vulkan: Track GPU progress for individual DescriptorSet"
This is a reland of commit 292102944add2ab30f4aa12a971cac456cc7726b
with the fix of garbage being added back to garbage list.
Original change's description:
> Vulkan: Track GPU progress for individual DescriptorSet
>
> Right now ProgramExecutableVk keeps VkDescriptorSet object, and
> DescriptorSetHelper is created when a cache entry becomes invalid.
> Further, DescriptorSetCache keeps the cache of {VkDescriptorSet,
> RefCountedDescriptorPoolHelper} pair. So we are having three different
> type of objects at different stages of life: VkDescriptorSet,
> DescriptorSetHelper, and {VkDescriptorSet,
> RefCountedDescriptorPoolHelper. This CL makes DescriptorSetHelper at
> creation and at cache and at garbage. With this change, you have a
> reference counted DescriptorSetHelper object (i.e, DescriptorSetPointer)
> during entire life cycle and is passed around between cache and program
> as is. This CL is preparation for the future CL where we may disable
> cache for descriptorSet. The descriptorSet will be added to garbage list
> and reused constantly without go through the cache code. We need to
> track the individual descriptorSet with ResourceUse so that it won't
> reuse until GPU is finished. This CL is making DescriptorSetHelper a GPU
> tracking object so that it will still just work when cache is disabled.
>
> Bug: angleproject:372268711
> Change-Id: I1cfb77cc5069b202d870388fd8809e265cdca90b
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5918586
> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
> Commit-Queue: Charlie Lao <cclao@google.com>
> Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Bug: angleproject:372268711
Change-Id: Ic920f99cc78cde1e94690bdbee3b885844fa155b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5954701
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
45cc47af
|
2024-10-22T21:41:22
|
|
Revert "Vulkan: Track GPU progress for individual DescriptorSet"
This reverts commit 292102944add2ab30f4aa12a971cac456cc7726b.
Reason for revert: Causing bot failure in later CLs
Original change's description:
> Vulkan: Track GPU progress for individual DescriptorSet
>
> Right now ProgramExecutableVk keeps VkDescriptorSet object, and
> DescriptorSetHelper is created when a cache entry becomes invalid.
> Further, DescriptorSetCache keeps the cache of {VkDescriptorSet,
> RefCountedDescriptorPoolHelper} pair. So we are having three different
> type of objects at different stages of life: VkDescriptorSet,
> DescriptorSetHelper, and {VkDescriptorSet,
> RefCountedDescriptorPoolHelper. This CL makes DescriptorSetHelper at
> creation and at cache and at garbage. With this change, you have a
> reference counted DescriptorSetHelper object (i.e, DescriptorSetPointer)
> during entire life cycle and is passed around between cache and program
> as is. This CL is preparation for the future CL where we may disable
> cache for descriptorSet. The descriptorSet will be added to garbage list
> and reused constantly without go through the cache code. We need to
> track the individual descriptorSet with ResourceUse so that it won't
> reuse until GPU is finished. This CL is making DescriptorSetHelper a GPU
> tracking object so that it will still just work when cache is disabled.
>
> Bug: angleproject:372268711
> Change-Id: I1cfb77cc5069b202d870388fd8809e265cdca90b
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5918586
> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
> Commit-Queue: Charlie Lao <cclao@google.com>
> Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Bug: angleproject:372268711
Change-Id: I4d3c34058d100112a098144276b52c0faf8d593a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5955529
Auto-Submit: Charlie Lao <cclao@google.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
|
|
99ba07d3
|
2024-03-26T00:58:57
|
|
CL/Vulkan: Implement createImage
Enabling functionality of:
- clCreateImage
Tests-Passing: OCLCTS.test_api get_image<1d|2d|3d>_info
Bug: angleproject:42266936
Signed-off-by: Rafay Khurram <r.khurram@samsung.com>
Change-Id: I0281f092bff13cdd81b87d596fdd15b33dda7e46
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5796527
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
29210294
|
2024-10-11T13:26:46
|
|
Vulkan: Track GPU progress for individual DescriptorSet
Right now ProgramExecutableVk keeps VkDescriptorSet object, and
DescriptorSetHelper is created when a cache entry becomes invalid.
Further, DescriptorSetCache keeps the cache of {VkDescriptorSet,
RefCountedDescriptorPoolHelper} pair. So we are having three different
type of objects at different stages of life: VkDescriptorSet,
DescriptorSetHelper, and {VkDescriptorSet,
RefCountedDescriptorPoolHelper. This CL makes DescriptorSetHelper at
creation and at cache and at garbage. With this change, you have a
reference counted DescriptorSetHelper object (i.e, DescriptorSetPointer)
during entire life cycle and is passed around between cache and program
as is. This CL is preparation for the future CL where we may disable
cache for descriptorSet. The descriptorSet will be added to garbage list
and reused constantly without go through the cache code. We need to
track the individual descriptorSet with ResourceUse so that it won't
reuse until GPU is finished. This CL is making DescriptorSetHelper a GPU
tracking object so that it will still just work when cache is disabled.
Bug: angleproject:372268711
Change-Id: I1cfb77cc5069b202d870388fd8809e265cdca90b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5918586
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
4bdcdf0d
|
2024-10-16T11:44:49
|
|
Vulkan: Switch RefCountedDescriptorPoolBinding to use SharedPtr
This mostly a clean up. RefCountedDescriptorPoolBinding is replaced with
DescriptorPoolPointer, which is defined as
SharedPtr<DescriptorPoolHelper>. It has more intuitive semantics to use.
Bug: angleproject:372268711
Change-Id: I0397111b5228e896c1d226e00930851319d955a0
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5938947
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
c52e8493
|
2024-10-11T14:21:19
|
|
Vulkan: Switch DescriptorPoolPointer to use SharedPtr
To make the reference counting easier to maintain, SharedPtr class is
added to automatically tracking the reference counting and object
creation/destruction. Right now we have BindingPointer class doing
similar things except it does not automatically manage the object
create/destroy, which makes it less robust as well as redundant code to
manage object life cycle. The other problem with BindingPointer is that
it does not work with normal assign/copy operator which made it hard to
read and use. SharedPtr uses exact same API semantics as
std::shared_ptr, which makes the reference counting very easy to use.
The main difference of SharedPtr and std::shared_ptr is that it does not
use any atomic or lock since it assumes user only uses it under thread
safe environment, which ANGLE's backend is.
This CL also changes mDescriptorPools to mDynamicDescriptorPools to make
it clear that it is dynamic descriptor pool not the descriptor pool.
This is also preparation CL for the next CL where we will use SharedPtr
to manage DescriptorSetHelper life cycle, which otherwise a bit
complicated to manually manage.
Bug: angleproject:372268711
Change-Id: I1033d9bf259bbc075a9b374d8a28e1f67d889873
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5926183
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
a19f0947
|
2024-10-17T22:42:30
|
|
Vulkan: Cache depth- and stencil-only views
Existing depth/stencil blit and resolve paths created temporary depth-
and stencil-only views. For
GL_ARM_shader_framebuffer_fetch_depth_stencil, such views are needed as
well.
In preparation for that extension, this change adds depth- and
stencil-only views to ImageViewHelper and allows them to be retrieved
through RenderTargetVk. The blit and resolve paths are consequently
simplfied as a side-effect.
Bug: angleproject:352364582
Change-Id: Ia822efb44ca7c82f63afce904eb19dd1bed02ff5
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5938149
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Yuxin Hu <yuxinhu@google.com>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
a1584f49
|
2024-10-11T21:17:32
|
|
Vulkan: Qualify framebuffer fetch with "Color"
In preparation for depth/stencil framebuffer fetch, many framebuffer
fetch symbols are affixed with Color to indicate that they pertain to
color framebuffer fetch logic.
Bug: angleproject:352364582
Change-Id: I86000ada5e6ef47387dec0b6a3fca589d816cdc2
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5926593
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
62f33a5c
|
2024-10-09T16:06:54
|
|
Vulkan: Make retainResource for descriptorSetPool consistent
Right now the cache hit and cache miss case are handled differently.
This CL makes it consistent. Now Caller of
DynamicDescriptorPool::getOrAllocateDescriptorSet will handle this
retainResource call regardless of cache hit or miss.
Bug: b/372268711
Change-Id: I11e47ab9e56a24eb68a0231c5e553ab6b8833c82
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5921640
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
b3d85cce
|
2024-09-30T14:28:35
|
|
Vulkan: Consolidate write colorspace override states
ColorspaceState struct is now used to cache write colorspace related
states to determine the colorspace of Vulkan draw image views.
ImageViewHelper methods are called during initialization and when
colorspace related states are toggled dynamically which in turn process
these states and determine the final write colorspace.
We can now fully support rendering to EGLImages, with colorspace
overrides, via texture or renderbuffer EGLImage targets
Bug: angleproject:40644776
Tests: ImageTest*Colorspace*Vulkan
MultithreadingTestES3.SharedSrgbTextureMultipleContexts*Vulkan
ReadPixelsPBOTest.SrgbUnorm*Vulkan
Change-Id: I2be2cd3b5b2b4ac8ecb803c34cde2b846cbd1cbe
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5901256
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
|
|
|
b38cc7fa
|
2024-09-30T12:43:09
|
|
Vulkan: Consolidate read colorspace override states
ColorspaceState struct is now used to cache read colorspace related
states to determine the colorspace of Vulkan read image views.
ImageViewHelper methods are called during initialization and when
colorspace related states are toggled dynamically which in turn process
these states and determine the final read colorspace.
Bug: angleproject:40644776
Tests: ImageTest*Colorspace*Vulkan
SRGBTextureTest.SRGB*TextureParameter*Vulkan
SRGBTextureTestES3.SRGBDecodeTexelFetch*Vulkan
Change-Id: I16b3666cd80865936b826dc0738fc9210dabeda9
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5901255
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
|
|
|
7c811715
|
2024-09-25T11:09:44
|
|
Vulkan: fix crash when clearing stencil with ClearBuffer
Follow up to [1] which fixed a crash with glClear, but the bug remained
with glClearBufferiv. This change refactors the "is stencil write
masked out" query to always take the framebuffer's stencil bit count
into account (practically always 8), which also happens to make the rest
of the code checking this query more accurate in the presence of
nonsense masks where the bottom 8 bits are 0.
[1]: https://chromium-review.googlesource.com/c/angle/angle/+/3315158
Bug: chromium:40207259
Bug: angleproject:42266334
Change-Id: I68a6b0b75c67ed2cdc8c4d03b243efe5495efce1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5889788
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Geoff Lang <geofflang@chromium.org>
|
|
|
eaffa034
|
2024-09-24T20:56:04
|
|
Revert "Vulkan: Consolidate colorspace override states"
This reverts commit bffcd235ba6c031603d798daaa98f1cf9a3f3e46.
Reason for revert: Breaks Android test `org.skia.skqp.SkQPRunner#UnitTest_DMSAA_dst_read`. Details:
https://b.corp.google.com/issues/369388539.
Original change's description:
> Vulkan: Consolidate colorspace override states
>
> ColorspaceState struct is now used to cache colorspace related states
> and used to determine the colorspace of Vulkan image views.
> ImageViewHelper methods are called during initialization and when
> colorspace related states are toggled dynamically which in turn process
> these states and determine the final read and write colorspaces.
>
> We can now fully support rendering to EGLImages, with colorspace
> overrides, via texture or renderbuffer EGLImage targets
>
> Bug: angleproject:40644776
> Tests: ImageTest*Colorspace*Vulkan
> MultithreadingTestES3.SharedSrgbTextureMultipleContexts*Vulkan
> SRGBTextureTest.SRGB*TextureParameter*Vulkan
> SRGBTextureTestES3.SRGBDecodeTexelFetch*Vulkan
> ReadPixelsPBOTest.SrgbUnorm*Vulkan
> Change-Id: I1cc2b5bd834b519b83deab4d80a2fcaabeb271d6
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5841290
> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
> Reviewed-by: Charlie Lao <cclao@google.com>
> Commit-Queue: mohan maiya <m.maiya@samsung.com>
Bug: angleproject:40644776
Change-Id: I5bf6cf2ed0c8ec22fc02d8c3da92673ee85fe002
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5888506
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Yuxin Hu <yuxinhu@google.com>
|
|
|
bffcd235
|
2024-09-13T14:58:00
|
|
Vulkan: Consolidate colorspace override states
ColorspaceState struct is now used to cache colorspace related states
and used to determine the colorspace of Vulkan image views.
ImageViewHelper methods are called during initialization and when
colorspace related states are toggled dynamically which in turn process
these states and determine the final read and write colorspaces.
We can now fully support rendering to EGLImages, with colorspace
overrides, via texture or renderbuffer EGLImage targets
Bug: angleproject:40644776
Tests: ImageTest*Colorspace*Vulkan
MultithreadingTestES3.SharedSrgbTextureMultipleContexts*Vulkan
SRGBTextureTest.SRGB*TextureParameter*Vulkan
SRGBTextureTestES3.SRGBDecodeTexelFetch*Vulkan
ReadPixelsPBOTest.SrgbUnorm*Vulkan
Change-Id: I1cc2b5bd834b519b83deab4d80a2fcaabeb271d6
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5841290
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
|
|
|
e38d25b1
|
2024-06-21T18:22:32
|
|
Vulkan: Implement EXT_clear_texture
* Added new functions to TextureVk to clear the image.
* clearImage()
* clearSubImage()
* Both implemented via clearSubImageImpl(), with the former a
special case of the latter.
* For multisample or renderable images, stagePartialClear() from
ImageHelper is called to add the update.
* For single-sampled non-renderable images, a buffer is filled with
the pixel data and applied to the image as a buffer update.
* Added new update type: ClearPartial
* Used for renderable textures. This includes multisample textures.
* LOAD_OP_CLEAR is used in a render pass to perform the clear.
* UtilsVk::clearTexture()
* (Uses ClearTextureParameters)
* Uses the following functions to get the VkClearValue from the
input data and format:
* GetVkClearColorValueFromBytes()
* GetVkClearDepthStencilValueFromBytes()
* ClearPartial updates can also be superseded and removed similar to
Buffer updates.
* Updated UtilsVk::startRenderPass() to accept a VkClearValue* as an
input arg. If used, the render pass will use LOAD_OP_CLEAR.
* Enabled the feature "clearTextureEXT" on Vulkan.
* Added new unit tests in ClearTextureEXTTest for various formats and
pixel sizes.
* Added related multisample tests in FramebufferTest.cpp.
* FramebufferTest_ES31.ClearTextureEXT*
* Disabled some of the new tests failing using OpenGL.
* Disabled stencil-only-related tests on Pineapple.
Bug: angleproject:42266869
Change-Id: I89c631d68a4ed63d9991abe1783333255ade20dd
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5778348
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
9685cb96
|
2024-09-17T11:41:28
|
|
Vulkan: Clean up PackedClearValuesArray::store
The code was a bit confusing, raising question why there is check of
aspectFlags != VK_IMAGE_ASPECT_STENCIL_BIT. I believe this was
originally from
https://chromium-review.googlesource.com/c/angle/angle/+/2142711, and
then followed by
https://chromium-review.googlesource.com/c/angle/angle/+/2410366. The
code seems to having some special logic to handle packed depth stencil
clear value. This code may have been changed a bit. When I am looking at
current code base, I am not seeing good reason doing it this way. Caller
is handling the packed format by reading out depth value and pack them
together and then store. This CL replaces store/storeNoDepthStencil
pair to storeColor/storeDepthStencil.
Bug: b/167301719
Change-Id: I40cfca1e51654f5ddaf4b2e8460ae5a26c656f2b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5870921
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
1b4d6185
|
2024-09-12T09:18:46
|
|
Vulkan: Cleanup sRGB related code
Image and image view code is littered with sRGB related enums, even
in places that don't deal with sRGB. Remove sRGB related parameters
from initLayerImageView and getLevelLayerDrawImageView methods, which
now assume default values. Add dedicated methods that allow overriding
sRGB state values.
Also introduce ColorspaceState struct that consolidates all sRGB
related states, this will be used in follow up changes to track
and infer colorspace of image views
Bug: angleproject:40644776
Change-Id: Ifb366db48043e376f9ff6c30c852c44dd96562a1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5860808
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
|
|
|
937c5dc8
|
2024-09-09T12:18:55
|
|
Vulkan: Make image{Read,Write} helper interface api agnostic
Removing ContextVk dependency on the imageRead/imageWrite helper utility
functions.
Bug: angleproject:42266971
Change-Id: I493e1fb11e8ae192f766c822cbee278c49c23bfe
Signed-off-by: Gowtham Tammana <g.tammana@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5845197
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
7080b766
|
2024-08-16T11:31:39
|
|
Vulkan: Move LineLoopHelper from vk to rx namespace
There is no line loop support in vulkan. LineLoopHelper is a utility
function for backend, not a helper function for vulkan object. So it is
better fit in rx namespace instead of vk namespace.
This also helps my next CL where I am going to change
initBufferForVertexConversion to take a ConversionBuffer instead of
BufferHelper. LineLoopHelper uses initBufferForVertexConversion, which
means I have to change LineLoopHelper to uses ConversionBuffer. This
causes header inclusion problem that now vk namespace object end up have
to include rx namespace header. This CL fixes this inclusion problem by
moving it to the proper namespace.
Bug: b/357622380
Change-Id: I6d6cf1aa926f726bb1b1ab1017bcab092eaf5d37
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5787502
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
f8fc8ac3
|
2024-08-05T11:50:11
|
|
Vulkan: Remove dependency on ContextVk for CommandBufferHelper
Following on the changes in [1], this makes the
`CommandBufferHelperCommon` and `OutsideRenderPassCommandBufferHelper`
interfaces independent of `ContextVk` state. Any dependency is made
explicit.
In addition, interfaces that are not specific to GLES context are also
updated.
[1]: Commit (bcf814fda5 Vulkan: Constrain the dependency on ContextVk in
BufferHelper)
Bug: angleproject:8544
Change-Id: I7d90ad915e8c14187ab5584453b9e8802bd91e2b
Signed-off-by: Gowtham Tammana <g.tammana@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5319147
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
cc7d0220
|
2024-07-31T14:22:38
|
|
Vulkan: Fix serial mismatch during mid-loop flush
Currently, if the total buffer updates to the image surpasses a
certain threshold, it results in a flush. However, this can cause
discrepencies in the queue serial, which can result in incorrect
behavior on some platforms.
* Updated flushStagedUpdatesImpl() so that the image serial after
applying the updates matches that of the current outside command
buffer.
* That includes when there is a flush in the middle of the update
loop, resulting in submission and new queue serial for the CB.
* Added a unit test to check if a large texture can uploaded and
deleted after a second small texture is uploaded.
* Texture1UploadThenTexture2UploadThenTexture1Delete
* Added a unit test for flushing when uploading cubemap textures.
Bug: b/351650806
Bug: b/356192937
Change-Id: I7f9b20e4b7fd49115f22081a9733b4d44b740e4a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5744377
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
bd3a3308
|
2024-07-22T14:03:20
|
|
Vulkan: Remove implicit image barrier for shader write
When app uses compute or fragment shader to write to an image and makes
multiple dispatchCompute or draw calls, right now we are inserting an
implicit barrier to ensure WAW is hazard free. But Spec says that
"Explicit synchronization is required to ensure that the effects of
buffer and texture data stores performed by shaders will be visible to
subsequent operations using the same objects". This CL records the bits
from the last glMemoryBarrier call and will skip the barrier calls in
ContextVk::updateActiveImages if there is no layout change, unless there
is requirement from prior glMemoryBarrier.
Bug: angleproject:350994515
Change-Id: I8bdeeb658993824369824aaa0f25cb4b6e3785f7
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5719024
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
7691cea7
|
2024-07-22T13:46:14
|
|
Vulkan: Remove seamful cubemap emulation
Practically, the Vulkan backend is never expected to run on ES2
hardware. It _may_ for WebGL, but seamful cubemap emulation was
disabled for webgl anyway.
Bug: angleproject:354729454
Change-Id: Iafa20fbdbe232c4df4c777b12e7698ef7a87cf24
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5730143
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
0d458614
|
2024-07-18T00:00:00
|
|
Vulkan: Fix PBO readbacks with small row length
Use CPU path when the row length is
smaller than the source area width.
Fixed: angleproject:354005999
Change-Id: I5c4686ca5387a98c6137868afb19c333aed8ac21
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5724591
Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
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>
|
|
|
1f87cbc9
|
2024-07-15T13:07:35
|
|
Vulkan: Fix late-added resolve attachment tracking
Resolve attachments may be added after the fact to a render pass due to
glBlitFramebuffer or eglSwapBuffer. Previously, only the resolve image
views were tracked by the render pass, and otherwise the state tracking
(layout, content defined, etc) treated the resolve images as generically
written-to by the render pass.
As a result, the render pass was unable to finalize the layout of the
resolve images early. Optimizing the layout of the swapchain image when
the surface is multisampled for example was not done due to this issue.
In this change, when resolve attachments are added late, they are
tracked identically to when they are added at the beginning of the
render pass, fixing the issues described above.
Bug: angleproject:42265625
Bug: angleproject:42266019
Change-Id: I765560762bb8caf39ba1096fb028177201c082d7
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5707470
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
6578b9c0
|
2024-07-09T17:19:47
|
|
Vulkan: Exclude compute/preFrag only access images from event
This further restricts VkEvent usage for certain usage patterns. If
image is only used by compute, use VkEvent also will not benefit it
since compute itself can not overlap with compute (assume there is only
one compute engine and compute work can not overlap with each other).
Similarly this also applies to KPreFragment stages. Basically after this
CL, use of VkEvent is limited to usages that crosses different execution
units (modeled against tiler based GPUs where there are pre-fragment
stages and fragment stages and compute and all others). Before this CL,
we are seeing performance regression with antutu_refinery and
streets_of_rage_4 due to overhead of VkEvent, which is fixed with this
CL.
Bug: b/336844257
Change-Id: I5ca5d813daefe9bfcaf48f831340cdf9559f8104
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5692760
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
402c8ccd
|
2024-06-26T19:28:21
|
|
Vulkan: Limit VkEvent for images that has fragment access only
One of the problem with VkEvent is that the overhead comes with
VkCmdSetEvent causes some app traces regress performance. The goal in
this CL is to further limit VkCmdSetEvent to images that that we think
are potentially subject to the pipeline bubble. The bubble usually
occurs when accesses are alternated between different stages,
specifically a mix between vertex/transfer/compute/fragment. If all
accesses are from fragment shader or color attachment, then use VkEvent
will not be beneficial, but only adds extra overhead. This CL adds the
heuristic tracking for image access. Every time an image is used, a bit
is used to indicate the usage involves fragment only or not. A bitfield
is used to track the window of the history of the usage. When image is
used (usually at the time queueSerial is set), we shift the history bits
left and the new bit is added to the right most bit. If all accesses are
from the fragment shader or color attachment, then no need to use
VkEvent. For example, if a texture is always sample from fragment shader
only, then VkEvent will not used. Another common usage is you render to
it and then texture from it, it will also excluded from VkEvent with
this CL.
Bug: b/336844257
Change-Id: I175194f30b8f1d9b8fbf38ad594778474548016f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5664170
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
584fbcee
|
2024-07-10T12:43:34
|
|
Vulkan: Rework swap-time barrier logic
Avoids unnecessary transitions when overlay is enabled
Bug: angleproject:42267038
Change-Id: I0534911c0142c5e94cf3be112283fb98fcde0f6c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5691346
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
373ac541
|
2024-07-10T11:14:47
|
|
Vulkan: Make surface RP check independent from framebuffer object
With dynamic rendering, there is no framebuffer object, so checking
whether the currently open render pass belongs to the window surface (at
swap time) is made independent from these objects.
Bug: angleproject:42267038
Change-Id: I408e2376ba865b64fa1e8890316e8f57c08c695f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5691345
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
867697b7
|
2024-07-09T10:43:02
|
|
Vulkan: Add ImageHelper::onRenderPassAttach helper function
RenderPass attachments has one difference compared to other images. The
QueueSerial has to be set first so that we can detect an image is being
used as attachment. But the layout is delayed until the endRenderPass
time. This CL adds a onRenderPassAttach API to set the queueSerial so
that we have a central place to adding other code if needed.
Bug: b/336844257
Change-Id: I894fff83745691e8167a295c71cbc2e1d22f1343
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5689452
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
9ca3ed37
|
2024-07-08T16:48:51
|
|
Vulkan: Let ContextVk::onResourceAccess uses retainImage
Right now ContextVk::onResourceAccess calls retainResource for
everything. Mean time we also have a retainImage() function, which adds
a bit confusion to why we have two retain API. This CL moves retainImage
from CommandBufferHelperCommon to OutsideRenderPassCommandBufferHelper
and RenderPassCommandBufferHelper so that ContextVk::onResourceAccess
can use retainImage directly. The slightly behavior difference between
RenderPassCommandBufferHelper and OutsideRenderPassCommandBufferHelper's
retainImage is from compute shader's image access, which we are using
VkEvent to track images, mainly due to we tailor VkEvent to the
manhattan's usage case, which involves compute.
Bug: b/336844257
Change-Id: Id3fb694f683289a4720cc279387dbc27642745de
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5686352
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@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>
|
|
|
8c546d35
|
2024-06-25T12:49:40
|
|
Vulkan: Limit VkEvent for usage matters for Manhattan31 only
If we use VkEvent to track all image operations causes performance
regression on some app traces, including manhattan10 trace. This mainly
because of CPU overhead comes with VkCmdSetEvent, mostly inside vulkan
driver. These app traces likely not benefit from VkEvent because the
specific bubble (false dependency) does not manifest on these app
traces, but the CPU overhead takes a performance toll on it. In order to
strike a balance between benefit and overhead, this CL removes most of
VkEvent usage and only leaves the ones that matters for manhattan31. The
only we still keeps are generateMipmap, dispatchCompute, texture
sampling. We can always add more if more beneficial usage cases comes up
and no regression in other traces.
Bug: b/336844257
Change-Id: I346fe70bc33e57edf04e933a2db0f79738c4481d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5654737
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
46dd6457
|
2024-06-25T15:56:15
|
|
Vulkan: Use DONT_CARE ops for missing D/S aspects
Simplifies op tracking with dynamic rendering.
Bug: angleproject:42267038
Change-Id: I394c154d94458c470190fea66d82c408e6f33725
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5655873
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
d193d51b
|
2024-06-17T22:46:08
|
|
Replace issue ids post migration to new issue tracker
This change replaces anglebug.com/NNNN links.
Bug: None
Change-Id: I8ac3aec8d2a8a844b3d7b99fc0a6b2be8da31761
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5637912
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
5703bd61
|
2024-06-14T14:12:41
|
|
Vulkan: Further optimize ProgramExecutableVk::resetLayout
1. Handle compute pipelines similar to how we handle graphics pipelines
2. Track valid compute pipeline permutations
Bug: angleproject:8297
Change-Id: I58200517e5a44a2b3092777ea24d1529ceee00f5
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5634574
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
06f1b72f
|
2024-06-03T08:59:46
|
|
Vulkan: Bugfix in MSRTT emulation
Transient multisampled images should have no mips. Enforce this
requirement when MSRTT is being emulated
Bug: angleproject:4836
Tests: MultisampledRenderToTexture*MultipleLevelsMultisample*
Change-Id: I6df21bbb49a4c45aa3ee321f7d49b81f55352562
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5601347
Commit-Queue: mohan maiya <m.maiya@samsung.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
75625e6b
|
2024-06-11T11:10:24
|
|
Vulkan: Clean up ImageHelper::flushSingleSubresourceStagedUpdates
This CL changed some logic to use helper function to make logic more
clear.
Bug: angleproject:42263375
Change-Id: I5d0ec0f6b0a315f9e755939420a655976a2fef5b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5620736
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
b4f3824e
|
2024-05-31T11:36:32
|
|
Reland "Vulkan: Defer texture data flush until data provided for all levels"
This is a reland of commit 490c056a88a33870cb4ba2a7906b0a9688d96262
Original change's description:
> Vulkan: Defer texture data flush until data provided for all levels
>
> One of the major overhead with VkEvent is seeing with first frame where
> all textures are being specified. The immutable textures, we always
> immediately flush out the update as data provided for each level. This
> means one VkEvent is created and SetEvent is called per level. This CL
> delays the flush until data for all levels are provided, thus there is
> only one flush per texture instead of per level. With this CL asphalt_9
> is no longer timeout on bots when VkEvent is enabled.
>
> There is also another benefit comes with this CL. On all desktop GPUs,
> ASTC format texture are falling back to RGBA8. We always stage a clear
> for the emulated format. That staged clear are able to be removed if
> data is provided later. Because of we flush out staged update when first
> level data is provided, all staged clear for the subsequent levels are
> also gets flushed out, losing the chance to be removed. This CL will
> allow all staged clears being removed.
>
> Bug: b/343976993
> Bug: b/336844257
> Change-Id: Ica731ea57db771b16966f4da92ccdc551ae93d81
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5588816
> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
> Commit-Queue: Charlie Lao <cclao@google.com>
Bug: b/343976993
Bug: b/336844257
Change-Id: Iabcc1b4ebca7d6f34a0e7f109795392fc00e7eda
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5606146
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
5b8e380c
|
2024-06-10T17:54:25
|
|
Vulkan: Fix bug in ImageHelper::flushSingleSubresourceStagedUpdates
There is another bug in ImageHelper flush staged update code path that
exposed by a new test I added in crrev.com/c/5606145. When we render to
a multi-layered texture and that layer we are trying to render to has a
staged clear and followed by an buffer update, and if the buffer update
overlaps with layer we try to render to but not exact match, we will
incorrectly think that the glClear call can override the buffer update.
The bug here is that ImageHelper::flushSingleSubresourceStagedUpdates is
using ImageHelper::SubresourceUpdate::isUpdateToLayers() call to decide
if buffer update will be overriden. That isUpdateToLayers is only
looking exact layer range match. So in this case because the buffer
update's layer range is bigger than glClear, it returns false. This
causes the flushSingleSubresourceStagedUpdates think it is outside the
layer range we try to render, and causes rendering bug. This CL renames
isUpdateToLayers to isLayerRangeExactMatch to reflect the actual
behavior of the function. This CL also adds new API isWithinLayerRange
and called by flushSingleSubresourceStagedUpdates to decide if the
updates can implement using renderPass loadOp.
Bug: angleproject:345532371
Bug: angleproject:42263375
Change-Id: Ia604ed1a61b56d7bde05f12a03baef8f00af2b17
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5619730
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
81452425
|
2024-06-07T11:49:28
|
|
Vulkan: Fix keeping overlapped updates in flushStagedUpdatesImpl()
There is an existing bug in ImageHelper::flushStagedUpdatesImpl() that
caused webGPU test to fail when my CL crrev.com/c/5588816 landed. The
bug is that when we flush out an update, we walk through the vector
updates and if the update is outside the range of requested layer range,
we stash away the update to updatesToKeep list. We only flush out the
updates that are intersects with the requested layer range. The bug here
is that if one of the update has bigger layer range than the requested
layer range, and there is an update that intersects with that update's
layer range but not overlap with requested layer range, now that update
may incorrectly gets moved to updatesToKeep list. Later on when that
updatesToKeep list gets flushed out, you end up overwriting the image
content.
This CL adds a new function adjustLayerRange() that first walk the
updates and calculate the actual layer range that will be flushed and
then use that adjusted layer range to determine if an update should be
kept or flushed.
Bug: angleproject:345532371
Change-Id: I59ef4ec935354766d35e4cfbb6ce4b13d9a2e868
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5607276
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
f5d6112b
|
2024-06-05T17:20:45
|
|
Vulkan: Remove EventStage::BottomOfPipe and AllCommands
These two StageFlags never being used in VkCmdSetEvent, and should not
be used given that these are very strong synchronization. They are
removed in this CL.
Bug: b/336844257
Change-Id: I68a47a5459dadf56ad5c269ebb3af55887110cc7
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5601811
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
295ff607
|
2024-06-05T14:49:33
|
|
Vulkan: Precompute stageMask of kImageMemoryBarrierData
Right now every time we need a pipelineStage in kImageMemoryBarrierData,
we are doing a bitwise AND with
mSupportedVulkanPipelineStageMask. This get called multiple
times from barrier call. This CL adds
mImageLayoutAndMemoryBarrierDataMap that has already precomputed all
stageMask, thus avoid run time bitwise OR.
This CL also precomputes the bufferWritePipelineStageMask so that
flushImpl can be use it without construct every time.
Bug: b/345279810
Change-Id: I878bd31c967cd217477061976f07df13b043fa7f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5601073
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
87bbeaee
|
2024-06-03T15:04:25
|
|
Vulkan: Reduce VkEvent counts by using EventStage enums
Right now we are using too many VkCmdSetEvents and causes some of the
deqp tests timeout on CI bots (because of VVL is very slow along with
the number of events being used). RefCountedEvents are per ImageLayout.
But some of ImageLayous have the same VkPipelineStageFlags, for example
TransferSrc and TransferDst. This CL changes RefCountedEvent to per
unique VkPipelineStageFlags instead of per ImageLayout, thus allows
TransferSrc and TransferDst to share one VkEvent.
To do that, EventStage enum and kEventStageAndPipelineStageFlagsMap
table are added to define the predefined VkPielineStageFlags that ANGLE
uses. RefCountedEvent now keeps EventStage instead of ImageLayout. To
further reduce the CPU overhead, a customized
mPipelineStageMaskAndEventMap table is precomputed in renderer with
supported vulkan pipeline stages.
With this CL, previously timed out tests such as
KHR-GLES3.copy_tex_image_conversions.forbidden.renderbuffer_cubemap* now
passing.
Bug: b/336844257
Change-Id: I021a8f1d6112d5cf96c61652c9af5f679b1172eb
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5597732
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
92f198f6
|
2024-06-06T21:42:35
|
|
Revert "Reland "Vulkan: Defer texture data flush until data provided for all levels""
This reverts commit b93af07ac1ddb9f2e262d611d155f4b63f18999f.
Reason for revert: b/345532371
Original change's description:
> Reland "Vulkan: Defer texture data flush until data provided for all levels"
>
> This is a reland of commit 490c056a88a33870cb4ba2a7906b0a9688d96262
>
> Original change's description:
> > Vulkan: Defer texture data flush until data provided for all levels
> >
> > One of the major overhead with VkEvent is seeing with first frame where
> > all textures are being specified. The immutable textures, we always
> > immediately flush out the update as data provided for each level. This
> > means one VkEvent is created and SetEvent is called per level. This CL
> > delays the flush until data for all levels are provided, thus there is
> > only one flush per texture instead of per level. With this CL asphalt_9
> > is no longer timeout on bots when VkEvent is enabled.
> >
> > There is also another benefit comes with this CL. On all desktop GPUs,
> > ASTC format texture are falling back to RGBA8. We always stage a clear
> > for the emulated format. That staged clear are able to be removed if
> > data is provided later. Because of we flush out staged update when first
> > level data is provided, all staged clear for the subsequent levels are
> > also gets flushed out, losing the chance to be removed. This CL will
> > allow all staged clears being removed.
> >
> > Bug: b/343976993
> > Bug: b/336844257
> > Change-Id: Ica731ea57db771b16966f4da92ccdc551ae93d81
> > Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5588816
> > Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
> > Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
> > Commit-Queue: Charlie Lao <cclao@google.com>
>
> Bug: b/343976993
> Bug: b/336844257
> Change-Id: Ie987582a44e0d73abd38ce8f6813ff8995e907e2
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5597810
> Reviewed-by: Cody Northrop <cnorthrop@google.com>
> Commit-Queue: Charlie Lao <cclao@google.com>
Bug: b/343976993
Bug: b/336844257
Change-Id: I9356da6b4cdb21dba47758d6e937d1ae02f0ae34
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5606144
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
|
|
|
b93af07a
|
2024-05-31T11:36:32
|
|
Reland "Vulkan: Defer texture data flush until data provided for all levels"
This is a reland of commit 490c056a88a33870cb4ba2a7906b0a9688d96262
Original change's description:
> Vulkan: Defer texture data flush until data provided for all levels
>
> One of the major overhead with VkEvent is seeing with first frame where
> all textures are being specified. The immutable textures, we always
> immediately flush out the update as data provided for each level. This
> means one VkEvent is created and SetEvent is called per level. This CL
> delays the flush until data for all levels are provided, thus there is
> only one flush per texture instead of per level. With this CL asphalt_9
> is no longer timeout on bots when VkEvent is enabled.
>
> There is also another benefit comes with this CL. On all desktop GPUs,
> ASTC format texture are falling back to RGBA8. We always stage a clear
> for the emulated format. That staged clear are able to be removed if
> data is provided later. Because of we flush out staged update when first
> level data is provided, all staged clear for the subsequent levels are
> also gets flushed out, losing the chance to be removed. This CL will
> allow all staged clears being removed.
>
> Bug: b/343976993
> Bug: b/336844257
> Change-Id: Ica731ea57db771b16966f4da92ccdc551ae93d81
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5588816
> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
> Commit-Queue: Charlie Lao <cclao@google.com>
Bug: b/343976993
Bug: b/336844257
Change-Id: Ie987582a44e0d73abd38ce8f6813ff8995e907e2
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5597810
Reviewed-by: Cody Northrop <cnorthrop@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
170851ff
|
2024-06-04T09:01:11
|
|
Revert "Vulkan: Defer texture data flush until data provided for all levels"
This reverts commit 490c056a88a33870cb4ba2a7906b0a9688d96262.
Reason for revert: breaks win-trace
https://ci.chromium.org/ui/p/angle/builders/ci/win-trace/6014/overview
Original change's description:
> Vulkan: Defer texture data flush until data provided for all levels
>
> One of the major overhead with VkEvent is seeing with first frame where
> all textures are being specified. The immutable textures, we always
> immediately flush out the update as data provided for each level. This
> means one VkEvent is created and SetEvent is called per level. This CL
> delays the flush until data for all levels are provided, thus there is
> only one flush per texture instead of per level. With this CL asphalt_9
> is no longer timeout on bots when VkEvent is enabled.
>
> There is also another benefit comes with this CL. On all desktop GPUs,
> ASTC format texture are falling back to RGBA8. We always stage a clear
> for the emulated format. That staged clear are able to be removed if
> data is provided later. Because of we flush out staged update when first
> level data is provided, all staged clear for the subsequent levels are
> also gets flushed out, losing the chance to be removed. This CL will
> allow all staged clears being removed.
>
> Bug: b/343976993
> Bug: b/336844257
> Change-Id: Ica731ea57db771b16966f4da92ccdc551ae93d81
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5588816
> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
> Commit-Queue: Charlie Lao <cclao@google.com>
Bug: b/343976993
Bug: b/336844257
Change-Id: I25854b855334c4cac1c2b40467d8e2ecb7661b8f
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5593935
Auto-Submit: Yuly Novikov <ynovikov@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
|
|
|
490c056a
|
2024-05-31T11:36:32
|
|
Vulkan: Defer texture data flush until data provided for all levels
One of the major overhead with VkEvent is seeing with first frame where
all textures are being specified. The immutable textures, we always
immediately flush out the update as data provided for each level. This
means one VkEvent is created and SetEvent is called per level. This CL
delays the flush until data for all levels are provided, thus there is
only one flush per texture instead of per level. With this CL asphalt_9
is no longer timeout on bots when VkEvent is enabled.
There is also another benefit comes with this CL. On all desktop GPUs,
ASTC format texture are falling back to RGBA8. We always stage a clear
for the emulated format. That staged clear are able to be removed if
data is provided later. Because of we flush out staged update when first
level data is provided, all staged clear for the subsequent levels are
also gets flushed out, losing the chance to be removed. This CL will
allow all staged clears being removed.
Bug: b/343976993
Bug: b/336844257
Change-Id: Ica731ea57db771b16966f4da92ccdc551ae93d81
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5588816
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
34b832a3
|
2024-05-24T13:38:58
|
|
Vulkan: Add RefCountedEvent recycler
Previously the recycler was disabled due to race between resetEvent and
setEvent. This CL splits mFreeStack into two list: mEventsToReset and
mEventsToReuse. Events are first added to mEventsToReset list. Then at
OutsideRenderPassCommandBufferHelper::flushToPrimary time,
VkCmdResetEvents are added to reset all events in mEventsToReset list,
and that reset operation is tracked by mResettingQueue. When reset
command is completed, events moved into mEventsToReuse list. Since
access to renderer's RefCountedEventRecycler requires lock,
RefCountedEventCollector (a queue of events) is passed between
ShareGroupVk and renderer's recycler to minimize the locked access.
Bug: b/336844257
Change-Id: Iffac095729a81ba65a43df68cc9255d76e4be7c9
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5576757
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
018188c7
|
2024-05-28T14:44:14
|
|
Vulkan: Fix CachedPreferCoherent to actually require cached
VK_MEMORY_PROPERTY_HOST_CACHED_BIT should be in requiredBits instead of
preferredBits for CachedPreferCoherent buffer.
This again caused pixel6 test failures. flush() call is added right
after buffer allocation to fix the test failure. This likely is due to
the spec says " If a range of non-coherent memory is written by the host
and then invalidated without first being flushed, its contents are
undefined.".
Bug: b/339562049
Change-Id: Ie8529722bd03534598b03983ba447131573b1879
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5578276
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
0d772ebe
|
2024-05-21T16:41:41
|
|
Vulkan: Cleanup releaseToExternal/acquireFromExternal API
This CL addresses some feedback from the earlier CLs.
Bug: b/337135577
Change-Id: I90c26a9374254af69bf00eb6580ce9580b71ca5a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5561465
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
d27c0f95
|
2024-05-21T16:27:08
|
|
Vulkan: Fix UNASSIGNED-SubmitValidation-WaitEvents-WrongQueue
Before this CL, when eventBarrier is used for images, we may see
UNASSIGNED-SubmitValidation-WaitEvents-WrongQueue VVL error. What
happens is that when context is created with medium priority and image
is used, we created VkEvent that was set on medium priority VkQueue.
Later on when a new context with higher priority is added to the share
group, we upgrade all contexts to high priority and all subsequent
commands will be submitted to high priority VkQueue. Now if the image is
used and we call VkCmdWaitEvent, we end up waiting on new VkQueue for an
event that was set on the old VkQueue. This violates the vulkan spec.
With all previous prepartion CLs, now Context and ImageHelper all keeps
track of which DeviceQueueIndex it was last used. We can just check the
DeviceQueueIndex and fallback to pipelineBarrier if they has changed.
When pipelineBarrier is used, the event will be released, and subsequent
event will be created on new queue. So this fallback should only occur
once for the ImageHelper objects that was experiencing the queue switch.
ImageHelper::barrierImpl already checking DeviceQueueIndex changes, so
this will automatically works for VkEvent. This CL only needs to add the
support for ImageHelper::updateLayoutAndQueue.
Bug: b/336844257
Change-Id: Ia3f1caee4f3c8e98dc858d387e93d3b2d6eb8053
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5556443
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
1a9a703b
|
2024-05-21T11:14:40
|
|
Vulkan: Add DeviceQueueIndex to Context/BufferHelper/ImageHelper
This CL adds a utility class DeviceQueueIndex, which encapsulates
queueFamilyIndex and the queueIndex into one integer value so that we
can pass around to barrier function. vk::Context and BufferHelper and
ImageHelper class now keeps mCurrentDeviceQueueIndex instead of
mCurrentQueueFamilyIndex. For All contexts by default it gets the
default queue from renderer (which is always the one corresponding to
Medium priority). For ContextVk, when priority changes it update
mCurrentDeviceQueueIndex to match new context priority.
Bug: b/337135577
Change-Id: I62cc483cfdb3e974d38db074e671c57299300074
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5555903
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
b22cce5f
|
2024-05-21T10:55:27
|
|
Vulkan: Remove Renderer::getDeviceQueueIndex
Renderer::getDeviceQueueIndex() returns queueFamilyIndex. There is a
function that already returns mCurrentQueueFamilyIndex, so this function
is now removed.
This CL also renames ImageHelper::isQueueChangeNeccesary to
isQueueFamilyChangeNeccesary
Bug: b/337135577
Change-Id: I3cd9ded1414d1389e162aaa5399c231a987f871e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5553067
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
9ed415e5
|
2024-05-16T14:28:31
|
|
Vulkan: Clean up in ImageHelper::updateLayoutAndBarrier
There was a duplicated pipelineBarrier wait in
ImageHelper::updateLayoutAndBarrier that possibly come from bad code
merge. It is removed in this CL.
The check of hasEvent and subsequently call addAdditionalStageAccess has
moved out of addMemoryEvent and make its own function so that it only
affects the specific case where the image is used in different shader
stage in the *same* render pass.
Bug: b/336844257
Change-Id: I78b0c952be32124cb0fb6a2cf750df41f6c8259d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5544450
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
f82d812d
|
2024-05-16T15:46:05
|
|
Vulkan: Fix EventBarrier bug when asyncSubmission is enabled
Since we have moved RefCountedEvent garbage collection into
ShareGroupVk, we have changed the reference counting to use non-atomic.
There is a bug with async submission code path where the
executeSetEvents gets called from submission thread which does not have
share group lock. This CL fixes this bug by storing VkEvent in
RenderPassCommandBufferHelper so that executeSetEvents uses VkEvent
instead of RefCountedEvent when async submission is enabled.
This CL also adds assertion that RefCountedEvent::releaseImpl does not
get called from async submission thread.
Bug: b/336844257
Change-Id: Ifcbd5a09d2bc7636cc15b2c6728dbbca103d4d9c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5544449
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
0636b509
|
2024-05-06T12:36:20
|
|
Vulkan: Move RefCountedEvent GC and recycler to ShareGroupVk (2/3)
One of the problem we had with RefCountedEvents is CPU overhead comes
with it, and some part of the CPU overhead is due to atomic reference
counting. The RefCountedEvents are only used by ImageHelper and
ImageHelpers are per share group, so they are already protected by front
end context share lock. The only reason we needs atomic here is due to
garbage cleanup, which runs in separate thread and will decrement the
refCount. The idea is to move that garbage list from RendererVk to
ShareGroupVk so that access of RefCountedEvents are all protected
already, thus we can remove the use of atomic. The down side with this
approach is that a share group will hold onto its event garbage and not
available for other context to reuse. But VkEvents are expected to be
very light weighted objects, so that should be acceptable.
This is the second CL in the series. In this CL, we added
RefCountedEventsGarbageRecycler to the ShareGroupVk which is responsible
to garbage collect and recycle RefCountedEvent. Since most of
ImageHelper code have only access to Context argument, for convenience
we also stored the RefCountedEventsGarbageRecycler pointer in the
vk::Context for easy access. vk::Context argument is also passed to
RefCounteEvent::init and release function so that it has access to the
recycler. The garbage collection happens when RefCountedEvent is needed.
The per renderer recycler is still kept to hold the RefCounteEvents that
gets released from ShareGroupVk or when it is released without access to
context information.
Bug: b/336844257
Change-Id: I36fe5d1c8dacdbe35bb2d380f94a32b9b72bbaa5
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5529951
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
2e0aefe9
|
2024-05-06T11:03:19
|
|
Vulkan: Move RefCountedEvent GC and recycler to ShareGroupVk (1/3)
One of the problem we had with RefCountedEvents is CPU overhead comes
with it, and some part of the CPU overhead is due to atomic reference
counting. The RefCountedEvents are only used by ImageHelper and
ImageHelpers are per share group, so they are already protected by front
end context share lock. The only reason we needs atomic here is due to
garbage cleanup, which runs in separate thread and will decrement the
refCount. The idea is to move that garbage list from RendererVk to
ShareGroupVk so that access of RefCountedEvents are all protected
already, thus we can remove the use of atomic. The down side with this
approach is that a share group will hold onto its event garbage and not
available for other context to reuse. But VkEvents are expected to be
very light weighted objects, so that should be acceptable (If not, we
can add some limit to the number of events it can hold in the garbage
list).
This is the first CL in the series. Before this CL, the RefCounteEvents
are garbage collected at flushToPrimrary time, at which time we have
lost ContextVk information. In order for us to do garbage collect to
ShareGroupVk, we need to move the garbage collection process early,
before command buffers leaving ContextVk's visibility. For
OutsideRenderPassCommands, this is easy to do, we just call
flushSetEvents before we call mRenderer->flushRenderPassCommands. For
RenderPassCommands, that flushSetEvents call will simply make another
copy of RefCountedEvents and add to the garbage list and the actual
VkCmdSetEvents are defered at the executeSetEvents call that get called
from flushToPrimrary time.
Bug: b/336844257
Change-Id: I1948cd8240ff61d407931083b7584a54b1dc6b0d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5517891
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
5332ab8c
|
2024-05-10T19:48:34
|
|
Vulkan: Add RefCountedEventRecycler to vk::Renderer
This CL adds event recycler in vk::Renderer to avoid the constant create
and destroy of VkEvents. When RefCountedEvent is destroyed previously,
it now goes into per renderer recycler. When RefCountedEvent is created
previously, it now dips into this recycler and fetch it. Before we issue
VkCmdSetEvent, if this event was from recycler, we also issue
VkCmdResetEvent before VkCmdSetEvebt. When glFinish/EGLSwapBuffer is
called or context gets destroyed, this recycler is purged to keep the
free count under limit.
Bug: b/336844257
Change-Id: I92ec1b183f708112a96c3d06fcfa265024f5aa04
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5519174
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
df2e7bd7
|
2024-05-10T19:48:34
|
|
Vulkan: Handle the case that VkEvent failed to create.
If VkEvent failed to create, we can still fall back to pipeline barrier.
This CL changes RefCountedEvent::init to return boolean. Also when it
fail, this CL did an immediate garbage clean up in case it will free up
more event from garbage list and then retry again.
Bug: b/336844257
Change-Id: I28251849a92d1785701c55eb028a8fed63cfc372
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5532869
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
36cd4c1f
|
2024-05-08T12:27:22
|
|
Adding basic readPixels.
This change adds to methods in ImageHelper to read texture data.
It also implements FramebufferWgpu::readPixels to get the parameters
and read the texture data from an ImageHelper that's stored in
mRenderTargetCache.
Bug: angleproject:8653
Change-Id: I349ed8a0ae3d8d0e187c658f3402c4f8cac23eb8
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5441353
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Liza Burakova <liza@chromium.org>
Reviewed-by: Matthew Denton <mpdenton@chromium.org>
|
|
|
3d04180c
|
2024-05-02T17:30:02
|
|
Vulkan: Add a dedicated garbage list for RefCountedEvents
Previously each individual RefCountedEvent is wrapped into a
GarbageObject. That is the reason behind RefCountedEvent being a
subclass from WrappedObject, since vk::GetGarbage call requires garbage
object is a subclass of WrappedObject. This CL adds a new garbage list
dedicated for RefCountedEvents, named mRefCountedEventGarbageList. With
this new change, we no longer limited by the vk::GetGarbage requirements
since it no longer called for RefCountedEvents. RefCountedEventCollector
is a vector of RefCountedEvents and every time a RefCountedEvent needs
to be released, it adds into the collector. Then the event collector
entire thing is treated like a garbage object and gets ResourceUse
tracked and added into mRefCountedEventGarbageList. This list gets
walked and cleaned when GPU is completed. This CL is also a preparation
for later CLs that adds event recycle support.
Bug: b/336844257
Change-Id: I4eff69b66922dfe5521b6994f240e967ff3726bd
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5516458
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
5b9e7f20
|
2024-05-06T14:50:44
|
|
Vulkan: Release mCurrentEvent before oneOff surface image copy
In ImageHelper::copySurfaceImageToBuffer and
ImageHelper::copyBufferToSurfaceImage, which get called from
lockSurface, we are doing a one off submission to do the data copy
between image and buffer. Surface image may have a current event set
earlier, but we do not have a garbage collector to collect it. This will
crash in barrierImpl when we try to add mCurrentEvent to the garbage
collector. This CL releases mCurrentEvent so that it will fall back to
pipelineBarrier. Since this is not on performance critical code path,
the impact should be acceptable as well.
Bug: b/336844257
Change-Id: Ib85c3038657a1845e86286cdb5f52247c2b9eb73
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5519173
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
c3a1cae4
|
2024-04-15T14:58:55
|
|
Use angle::SimpleMutex everywhere in libGLESv2
Only cases left that use std::mutex are:
- Share group and the context ErrorSet mutexes as they need try_lock()
- Anywhere mutexes are used in conjunction with std::condition_variables
(as they explicitly require std::mutex)
Bug: angleproject:8667
Change-Id: Ib6d68938b0886f9e7c43e023162557990ecfb300
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5453294
Reviewed-by: Roman Lavrov <romanl@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
28d4c3eb
|
2024-05-03T13:00:03
|
|
Vulkan: Remove BarrierType argument from ImageHelper::barrierImpl
Originally I passed the barrierType argument into barrierImpl function
to force pipelineBArrier in a few edge cases. Notably when we do a
oneoff submission. In that case if we have an event that is pending
setEvent call, and we will end up inserting a waitEvent call on an event
that has not yet set, which is bad. But this really won't not happen.
This CL removed BarrierType from the API and added a few assertions in
the caller to ensure we do not have a valid event when doing a oneoff
submission (if there is a pending setEvent, mCurrentEvent will be
valid).
Bug: b/336844257
Change-Id: I7161b844fc1f36993cf7ff6c90a070d9f92930cc
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5512878
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
5eb3bca0
|
2024-05-01T11:47:34
|
|
Vulkan: Minor cleanup
Bug: b/336844257
Change-Id: I8d93c6dd814a666debf9990d151cad79c45469f1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5503645
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: 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>
|
|
|
a96e9197
|
2024-04-25T10:35:02
|
|
Vulkan: Add RefCountedEvent class and VkCmdSetEvent call
This CL defines RefCountedEvent class that adds reference counting to
VkEvent. CommandBufferHelper and ImageHelper each holds one reference
count to the event. Every time an event is added to the command buffer,
the corresponding RefCountedEvent will be added to the garbage list
which tracks the GPU completion using ResourceUse. That event garbage's
reference count will not decremented until GPU is finished, thus ensures
we never destroy a VkEvent until GPU is completed.
For images used by RenderPassCommands, As
RenderPassCommandBufferHelper::imageRead and imageWrite get called, an
event with that layout gets created and added to the image. That event
is saved in RenderPassCommandBufferHelper::mRefCountedEvents and that
VkCmdSetEvents calls are issued from
RenderPassCommandBufferHelper::flushToPrimary(). For renderPass
attachments, the events are created and added to image when attachment
image gets finalized.
For images used in OutsideRenderPassCommands, The events are inserted as
needed as we generates commands that uses image. We do not wait until
commands gets flushed to issue VkCmdSetEvent calls. A convenient
function trackImageWithEvent() is added to create and setEvent and add
event to image all in one call. You can add this call after the image
operation whenever we think it benefits, which gives us better control.
(Note: Even if forgot to insert the trackImageWithEvent call, it is
still okay since every time barrier is inserted, the event gets
released. Next time when we inserts barrier again we will fallback to
pipelineBarrier since there is no event associated with it. But that is
next CL's content).
This CL only adds the VkCmdSetEvent call when feature flag is enabled.
The feature flag is still disabled and no VkCmdWaitEvent is used in this
CL (will be added in later CL).
Bug: b/336844257
Change-Id: Iae5c4d2553a80f0f74cd6065d72a9c592c79f075
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5490203
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
caebfea1
|
2024-04-24T16:58:39
|
|
Vulkan: Make PipelineBarrierArray a class
Right now PipelineBarrierArray is just a
angle::PackedEnumMap<PipelineStage, PipelineBarrier>. To make iterate
over barrierArray faster we added mPipelineBarrierMask. They are not
encapsulated well. This CL makes PipelineBarrierArray a class which
internally tracks mPipelineBarrierMask bits. We also moved
pipelineBarrier related code into this class. This is a preparation for
the later CL that we will have a EventBarrierArray so that the
pipelineBarrier and eventBarrier are better separated.
Bug: b/336844257
Change-Id: I6002e3fdd584d5a63587f68f13a260b417b3db32
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5484711
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
298b8739
|
2024-04-15T13:58:01
|
|
Vulkan: Restrict the ContextVk dependency in CommandBufferHelper
Updating the interfaces that have no need for ContextVk state and
instead passing in the vk::Context.
Bug: angleproject:8544
Signed-off-by: Gowtham Tammana <g.tammana@samsung.com>
Change-Id: Id3b72d9eabb7d1d6ee89c46cdc24a23da9e32b5c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5492319
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
2905a6a6
|
2024-04-19T15:09:41
|
|
Vulkan: Fix read pixel to cached non-coherent memory
The bug here is that when we use cached non-coherent memory for image
read, we must wait until DMA to finish before calling invalidate().
Otherwise CPU pre-fetching might end up populate the cache line again
with old data between invalidate and DMA and causes CPU reads get the
stale data from cache. This CL moves invalidate() call after we wait for
copy to finish and removes requireCachedBitForStagingBuffer feature
flag.
Bug: b/335937565
Bug: b/315836169
Bug: b/324953979
Change-Id: Ie8a1854e17a5fe9c534c5102b2e0d51bd35c131a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5468597
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Cody Northrop <cnorthrop@google.com>
|
|
d4abe622
|
2024-04-03T17:46:38
|
|
CL/VK: Implement enqueue NDRangeKernel & Task
Adding support for:
clEnqueueNDRangeKernel
clEnqueueTask
Bug: angleproject:8631
Change-Id: If57002be3ea00a55215e89ca47ab8fe9a422c6e7
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5406614
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Austin Annestrand <a.annestrand@samsung.com>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
|
48132950
|
2024-04-17T17:05:07
|
|
Vulkan: Optimize DescriptorSetLayoutDesc layout
Separate out immutable samplers into its own array so we can remove
padding from PackedDescriptorSetBinding which reduces the size of that
struct from 16 bytes to 4 bytes.
Bug: angleproject:2462
Change-Id: I79d1ab584178202c9b7f34b0c7926edced4e21a8
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5464162
Commit-Queue: mohan maiya <m.maiya@samsung.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
80c8b6f0
|
2024-04-17T10:06:45
|
|
Revert "Vulkan: Only enable DS dynamic state if there is DS attachment."
This reverts commit 471b50407d7d1c22491d066df77060cb8b9b2f89.
The reverted change does not correctly handle UtilsVk functions, leading
to validation failures. UtilsVk could be made to not set dynamic state
when the depth/stencil attachments are missing, but instead the change
is reverted because:
- The original issue that prompted this is easily fixable (and fixed in
this change)
- Disabling depth/stencil dynamic state is not necessarily a performance
improvement; every time a pipeline in such a render pass is bound, the
driver would have to make sure to no-op the relevant state change if
static, which is also costly. Instead, dynamic state may need to be
set only once in the entire render pass.
Bug: b/223456677
Bug: b/315353258
Bug: angleproject:8242
Change-Id: I8282b87857d6b9285dbcf307c3c6ecf69df5fadb
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5462079
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
d9943e44
|
2024-04-09T23:53:48
|
|
Remove Program::syncState
The last bit of responsibility still left in Program::syncState was to
wait for post-link tasks for the sake of EGLBlobCacheTest tests. A new
extension, GL_ANGLE_program_binary_readiness_query is created so that
the wait can be done in the test itself.
This extension is ultimately useful for applications as well, so they
can avoid blocking the CPU by calling glGetProgramBinary prematurely.
Bug: angleproject:8297
Change-Id: Ied6b755cb9b060198f82c7948bfd03441435a578
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5440302
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: mohan maiya <m.maiya@samsung.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
d3aaf795
|
2024-04-05T15:57:38
|
|
Vulkan: Early out ImageHelper::updateLayoutAndBarrier when possible
If one image is attached to more than one attach points, when render
pass closes we end up calling ImageHelper::updateLayoutAndBarrier
multiple times. The first one is required since it does the layout
transition etc. But the second call is unnecessarily inserting memory
barriers. This is optimization itself, but will also fix the other
bigger problem when we start using VkEvent instead of PipelineBarrier:
we may end up waiting for an event that has not been set (since setEvent
gets called after we end render pass but waitEvent is before render
pass. Calling this sequence twice on the same image for the same render
pass means second waitEvent is called before setEvent).
Bug: b/333391804
Change-Id: Ic7b409c71806e63cb56c25e10b0bd0bfc9f6086d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5431033
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
13829f20
|
2024-03-26T23:03:12
|
|
Vulkan: Optimize depth/stencil resolve with glBlitFramebuffer
Like color resolve, depth/stencil resolve is now also possibly done by
modifying the render pass and attaching a depth/stencil resolve
attachment.
Bug: angleproject:7551
Change-Id: I045e3875e24006d2473a55b6c3856dd768fe8b84
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5398004
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
103c1b53
|
2024-03-29T14:37:23
|
|
Vulkan: Drop MSRTT emulation dependency on independentResolveNone
Usage of VK_RESOLVE_MODE_NONE was removed in [1], but dependency to this
property was accidentally added in [2].
[1]: https://chromium-review.googlesource.com/c/angle/angle/+/2743666
[2]: https://chromium-review.googlesource.com/c/angle/angle/+/3353895.
Bug: angleproject:4836
Change-Id: I25028b5d343686edd794acdac3714c4a6cb5fa17
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5407073
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|