|
8f8f0439
|
2025-10-02T15:44:46
|
|
Group the class methods together
In previous many CLs, I intentionally not move around the code for ease
of code review. Now everything has settled down, it is the time to
regroup class methods together.
Also renamed some various in VertexArrayVk to be consistent with each
other.
No functional change is expected in this CL.
Bug: b/439073246
Bug: b/433331119
Change-Id: I84f9a2ff9ea20f359e2f546ecb4e3e503b805748
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/7007472
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
7b4ff0b2
|
2025-10-01T16:30:47
|
|
Vulkan: Updates to onFramebufferBoundary
1. Rename to the more appropriate onFrameBoundary
2. Add method to renderer for better encapsulation
3. When being moved to the background some apps unMakeCurrent
the contexts and exit without calling other frame boundary
APIs. Handle such usecases by treating
ContextVk::onUnMakeCurrent(...) as a frame boundary
Bug: angleproject:386749841
Change-Id: Ic2a8ecb631d132d99f8508f45f3b454c49f6624e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/7004936
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
7994bf76
|
2025-09-29T11:55:00
|
|
Vulkan: Avoid double-setting the fragment shading rate
Because there were two handlers for fragment shading rate, one for the
QCOM extension and one for EXT, every time the render pass started, it
would set the fragment shading rate to 1x1 twice.
Bug: angleproject:420310117
Change-Id: I905c504c7a7b80b5e7173e5d6a7cabe6f271e7a1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6995362
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: mohan maiya <m.maiya@samsung.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
6218bbd4
|
2025-09-26T12:20:39
|
|
Vulkan: Make min submit command count dynamic
* Turned the constant submit count threshold to a variable that can
be set for different devices independently.
* Added feature flag to enable forcing submission for certain GL
commands, such as Clear and Invalidate.
* If disabled, it would treat all commands the same and submit at
the count threshold without exception.
Bug: b/422507974
Change-Id: Ib13d36adfdcf75aa865dafadc279287f4a4bd1c7
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6990531
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
94777428
|
2025-08-08T10:36:22
|
|
Shading rate should be {1,1} when enabled PER_SAMPLE
According to spec, if FETCH_PER_SAMPLE_ARM is enabled, the fragment
shading rate is set to {1,1}.
Bug: angleproject:437957110
Change-Id: I3ea6958f1aaec5f13923f62001906c7c6c71e09e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6839957
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Auto-Submit: Tingwei Guo <tingwei.guo@arm.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
1f40285c
|
2025-09-24T11:54:44
|
|
Vulkan: Bypass buffer for VA if Bind*Buffers2
Due to added support for BindVertexBuffers2 and BindIndexBuffer2,
there would be no need to allocate a buffer for vertex arrays via
getBufferForVertexArray() if the related features are supported. It
should be possible to directly reference the original buffer and the
proper offset instead without errors.
* The buffer handles and offsets in VertexArrayVk now get the original
buffer handle and offset instead of using getBufferForVertexArray().
* getBufferForVertexArray() will now be used only when the following
feature is disabled:
* useVertexInputBindingStrideDynamicState
* (which is used as condition for vkCmdBindVertexBuffers2())
* Renamed the function for index buffer: getIndexBufferForVertexArray()
This will be used when the following feature is disabled:
* supportsMaintenance5
* (which is used as condition for vkCmdBindIndexBuffer2()))
* Moved the rest of the code in getBufferForVertexArray() to ~Impl(),
which is used by both the functions above.
* Removed redundant condition from the vertex input binding stride
dynamic state feature.
Bug: chromium:40059200
Bug: angleproject:394337110
Change-Id: I665611f92058048a9778aa4b823fabfad7c96c84
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6980316
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
dd51c3e5
|
2025-09-16T00:03:20
|
|
Vulkan: Expand usage of BindVertexBuffers2
* bindVertexBuffers2() can now be used when vertex input dynamic
state is enabled.
* Since dynamic vertex input already sets the strides, there
is no need to add the strides to bindVertexBuffers2() anymore
and passing in nullptr should work.
* Added the following token: BindVertexBuffers2NoStride
* This is used to avoid the condition check overhead for the
draw calls taking this code path.
* Removed the condition of vertex input dynamic state from using
vertex input binding stride.
* The following pipeline flags can now be added to a pipeline
object at the same time:
* VK_DYNAMIC_STATE_VERTEX_INPUT_BINDING_STRIDE
* VK_DYNAMIC_STATE_VERTEX_INPUT_EXT
* Changed the condition of positive vertex attribute count to any
vertex attributes to add input binding stride flag to the pipeline.
Bug: chromium:40059200
Change-Id: Id3be458580da0ca46db554bf292f240dae4d5097
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6944912
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
91263bbb
|
2025-09-18T14:55:02
|
|
Vulkan:Improve ContextVk::handleDirtyGraphicsDefaultAttribs
ContextVk::handleDirtyGraphicsDefaultAttribs() calls
updateDefaultAttrib(), which basically does the work
ContextVk::onVertexArrayChange() is doing. This CL simplify the code by
calling onVertexArrayChange directly from
handleDirtyGraphicsDefaultAttribs. onVertexAttributeChange is removed.
This also has the advantage that onVertexArrayChange put the for loop
inside if check, versus current implementation does all the if check
inside the for loop.
Bug: b/439073246
Change-Id: Ic7b7f531f2f831d16f34794e23fefc9569a3e142
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6967318
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
75f6faf1
|
2025-09-05T17:01:43
|
|
Vulkan: Use size in BindVertexBuffers2
* Added the following attribute array to VertexArrayVk:
mCurrentArrayBufferSizes
* Updated during syncing/updating the vertex array attributes.
* Added the pointer for buffer sizes to the following call:
vkCmdBindVertexBuffers2EXT()
Bug: chromium:40059200
Change-Id: I754741d12a729d42dab7e0f0b166a174c8d86181
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6917838
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
17c0d100
|
2025-09-16T13:59:36
|
|
Vulkan: Remove VertexArrayVk::updateActiveAttribInfo
This function get called from DIRTY_BIT_VERTEX_ARRAY_BINDING context
dirty bit processing. It is doing exact same work as
ContextVk::onVertexArrayChange(), which was already been optimized in
earlier CL. In this CL VertexArrayVk::updateActiveAttribInfo() is
deleted and onVertexArrayChange() is being used, which does minimum
things when supportsVertexInputDynamicState is enabled.
Bug: b/439073246
Change-Id: I6b388a8f89a63e654d290c6f8d2212052b8c0d1f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6945076
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
cba665f3
|
2025-09-11T17:59:41
|
|
Vulkan: Add fast path for supportsVertexInputDynamicState
In earlier CLs, we have stored stride/offset/format/divisor in Vulkan
structs directly in VertexArray, this CL try to send these structs to
vulkan driver directly without making another copy. divisor code has
been modified to update inputRate as well as divisor in VertexArrayVk.
WHen program and VertexArray's attribute types matches we use
VertexArray's mVertexInputBindingDesc and mVertexInputAttribDesc without
any data copy. If attribType mismatch then we make a copy and patch up
the stride/format.
Bug: b/439073246
Change-Id: I905b1e6d0609ffc4eb63b47e11a84f8617e06c29
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6898416
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
7201e17d
|
2025-09-16T11:04:05
|
|
Vulkan: Move divisor>MaxVertexAttribDivisor to VA::syncState
Another preparation for use mVertexInputBindingDesc directly. Instead of
checking divisor > renderer->getMaxVertexAttribDivisor() in ContextVk
code, this CL take care of them in VertexArrayVk::syncState, so that all
other code do not need to take care of it.
Bug: b/439073246
Change-Id: Id938c168a1490e072e6f4bb08b85b60b55968ddf
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6955256
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
e542cb6c
|
2025-09-15T16:35:34
|
|
Vulkan: Split handleDirtyGraphicsVertexBuffers into two funcs
ContextVk::handleDirtyGraphicsVertexBuffers() has two code paths that
are quite different, depends on if supportsVertexInputDynamicState is
enabled or not. This CL splits this function into two so that 1) code is
much easier to read that what is done in each case and 2) get rid of if
check at draw time.
Bug: b/439073246
Change-Id: Iaf9f84fb20d82e784f9dfe8ece321cff94b7b58d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6956208
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Auto-Submit: Charlie Lao <cclao@google.com>
|
|
130bdaa9
|
2025-09-10T12:51:37
|
|
Vulkan: Store VkFormat in VkVertexInputBindingDescription2EXT
In preparation for next CL that uses VkVertexInputBindingDescription2EXT
directly, this CL also stores the VkFormat in
VkVertexInputBindingDescription2EXT directly. mDefaultAttribFormatIDs is
added to store the angle::FormatID for the default attribute (used when
attrib is disabled in VertexArray)
Bug: b/439073246
Change-Id: Ia36758b258be23676b9b12c0c7cec7adefe1036a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6935270
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
46444b3d
|
2025-09-09T16:13:58
|
|
Vulkan: Use VkVertexInputBindingDescription2EXT to store stride
This is preparation for next CL. Since most driver supports
VK_EXT_vertex_input_dynamic_state, which uses
VkVertexInputBindingDescription2EXT and
VkVertexInputAttributeDescription2EXT to send stride/divisor/offset to
the vulkan driver, why not store these directly in these structs instead
of store gl::AttribArray<> and copy then into
VkVertexInputBindingDescription2EXT/VkVertexInputBindingDescription2EXT
later. This CL only replaced mCurrentArrayBufferRelativeOffsets,
mCurrentArrayBufferStrides, mCurrentArrayBufferDivisors with
mVertexInputBindingDesc and mVertexInputAttribDesc. It still does the
data copy, which means this CL is mostly a mechanical change. But it
makes the next CL diff smaller.
Bug: b/439073246
Change-Id: Ie3c2034df07ea5e973b07a15f715fdb7c73ec04d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6933260
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
c292f292
|
2025-09-10T14:34:14
|
|
Vulkan: Remove compressVertexData feature
This feature was added for performance reason. It was used years ago to
improve performance of lego legacy. That entire game dashboard feature
was disabled a few years ago. So this code path is no longer been used
now, and not been tested on bots as well. This CL deletes this feature
and related code path so that we don't just leave it bit rotten.
Bug: b/167404532
Bug: b/439073246
Change-Id: I384fc97021592da57d38e8c1771892071ae68a89
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6935271
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
dcbe926e
|
2025-09-10T17:17:58
|
|
Vulkan: Avoid redundant updateVertexInput on disabled attribs
When supportsVertexInputDynamicState feature is disabled, we are calling
updateVertexInput right from VertexArray::syncState for both enabled and
disabled attributes. But disabled attributes we are also calling
contextVk->invalidateDefaultAttribute(attribIndex), which end up with
VertexArrayVk::updateDefaultAttrib(), which calls updateVertexInput().
This means updateVertexInput() are called twice for disabled attributes.
This CL skips onVertexArrayChange for disabled attributes.
Bug: b/439073246
Change-Id: Icf9c08d1a920d9112ef4080b95d0451f6230c6dd
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6937213
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
b71c7fd7
|
2025-09-10T16:17:10
|
|
Vulkan: Avoid recompute vertexArray attribute's ComponentType
ContextVk::handleDirtyGraphicsVertexBuffers() is calculating vertex
array attribute's component type. We actually already calculated and
stored in VertexArrayState. This CL get the component type from
VertexArrayState instead. The other benefit is that it removes the usage
of formatId, which helps the next CL.
Bug: b/439073246
Change-Id: I4ed32b5714fe48437af6f3a2f5da130ea71019a6
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6935272
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
428afbc2
|
2025-09-09T12:38:30
|
|
Vulkan: Remove hardcoded image layouts
In some places, ANGLE assumed and hardcoded the image layout. This was
often unnecessary, as the layout (or ImageAccess) was readily available
already.
In preparation for setting the image layout to GENERAL due to
VK_KHR_unified_image_layouts, this change makes sure the image layout is
not assumed to be anything specifically not GENERAL.
Bug: angleproject:422982681
Change-Id: I831bed0ca20197bd7424295ab0858d6bce83fe81
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6932268
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
166c9e23
|
2025-09-05T12:52:38
|
|
Vulkan: Separate barrier data into its file
vk::Renderer includes a modified copy of kImageMemoryBarrierData. When
using VK_KHR_unified_image_layouts, even more of this data is modified
based on device features. Leaving kImageMemoryBarrierData in
vk_helpers.cpp runs the risk that it's accessed directly instead of
using the copy in vk::Renderer.
Bug: angleproject:422982681
Change-Id: I7e288ef0ac519c53842214fe934ba7b2474e1f9c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6927350
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
ebf29178
|
2025-09-05T12:15:23
|
|
Vulkan: Rename ImageLayout to ImageAccess
This enum really describes how the image is accessed, including what
VkImageLayout it should be in for that access.
With VK_KHR_unified_image_layouts, it makes little sense to call this
enum ImageLayout anymore, given how almost all of them will have
VK_IMAGE_LAYOUT_GENERAL.
Bug: angleproject:422982681
Change-Id: Id0ea107d339457e90b7a167292b75211eb42f803
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6918518
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
26926a8b
|
2025-09-08T13:07:49
|
|
Vulkan: Rename CommandBufferAccess to CommandResources
CommandBufferAccess was named as such to indicate "what the command
buffer is going to access". The new name indicates "what resources are
the following command going to use".
The rename is happening to reduce usages of "access", in preparation for
introducing another "access" which can be confused with this.
Bug: angleproject:422982681
Change-Id: Ib072cde8533515ba76734b6426b4d673cb07cc45
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6923331
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
fecb02db
|
2025-08-28T12:08:34
|
|
Vulkan: Reduce onVertexBufferChange/onVertexAttributeChange
When we loop each attribute we end up calling onVertexBufferChange or
onVertexAttributeChange. For most drivers
supportsVertexInputDynamicState is enabled. This means we are repeatedly
check feature bit and set DIRTY_BIT_VERTEX_BUFFERS repeatedly for each
dirty attributes. This CL moves these calls out of attribIndex for loop.
ContextVk::onVertexArrayChange() now get called directly from
VertexArrayVk::syncState() so that we only go through most logic only
once if supportsVertexInputDynamicState is enabled.
Bug: b/439073246
Change-Id: Ib1316560ef686222e72b4d7ad32c63b043dfbaa5
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6896934
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
25390156
|
2025-08-21T00:13:19
|
|
Suppress unsafe buffers on a file-by-file basis in src/ [1 of N]
In this CL, we suppress many files but stop short of actually
enabling the warning by not removing the line from the
unsafe_buffers_paths.txt file. That will happen in a follow-on
CL, along with resolving any stragglers missed here.
This is mostly a manual change so as to familiarize myself with
the kinds of issues faced by the Angle codebase when applying buffer
safety warnings.
-- Re-generate affected hashes.
-- Clang-format applied to all changed files.
-- Add a few missing .reserve() calls to vectors as noticed.
-- Fix some mismatches between file names and header comments.
-- Be more consistent with header comment format (blank lines and
trailing //-only lines when a filename comment adjoins license
boilerplate).
Bug: b/436880895
Change-Id: I3bde5cc2059acbe8345057289214f1a26f1c34aa
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6869022
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
d65058be
|
2025-08-18T11:01:11
|
|
Vulkan: Add support for GL_EXT_fragment_shading_rate_primitive
Add support for built-in GL_EXT_fragment_shading_rate_primitive and
tests.
Bug: angleproject:397255625
Change-Id: I0f37a87a73e869a91e39402f01e53166b359ec3c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6850353
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Auto-Submit: Panfeng Hou <panfeng.hou@arm.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
bafe39e2
|
2025-07-14T16:07:51
|
|
Vulkan: Use BindIndexBuffer2 when available
This Vulkan API becomes available with VK_KHR_maintenance5. In
addition to the original args, it also takes the index buffer size.
* Added the necessary functions to use the following API:
vkCmdBindIndexBuffer2KHR()
* handleDirtyGraphicsIndexBuffer() now uses this API if maintenance5
is available.
Bug: angleproject:394337110
Change-Id: I9a650ac5a033b449da05e0c226e2cfb6df74a75c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6735725
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
fa29f604
|
2025-07-02T13:23:31
|
|
Remove sharedContextLock from {Enable|Disable}VertexAttribArray
VertexArray objects are per context objects. In theory they do not need
to protected by shared context lock. The reason we are taking locks
because all these functions end up accessing Buffer object which are
shared. In prior CLs we have removed subject observer usage from
VertexArray which means VertexArray no longer accessed from other
thread. In prior CLs we also split VertexArray into two classes:
VertexArrayPrivate which has no buffer, and VertexArray which is
subclass from VertexArrayPrivate and owns buffer. In this CL,
glEnableVertexAttribArray and glDisableVertexAttribArray calls no longer
take shared context lock. ContextPrivateEnableVertexAttribArray and
ContextPrivateDisableVertexAttribArray are called from these two APIs
and they only have access to StatePrivate. State Private holds a
VertexArrayPrivate pointer, which means they do not have anyway to
access buffer objects. The main challenge I run into here is
mCachedActiveClientAttribsMask, mCachedActiveBufferedAttribsMask,
mCachedActiveDefaultAttribsMask, mCachedHasAnyEnabledClientAttrib,
mCachedNonInstancedVertexElementLimit,
mCachedInstancedVertexElementLimit. These StateCache variable needs to
be updated when these two APIs are called, and calculating these
variable needs access to buffer object. The solution here is adding a
bool mIsCachedActiveAttribMasksValid in the PrivateStateCache so that
instead of immediately update these mCached* variable, we just set
mIsCachedActiveAttribMasksValid to false. Then whenever any of these
mCached* variable is needed, we will check
mIsCachedActiveAttribMasksValid and calculate these cached variables. It
adds one if check when accessing these caches, but the other benefit is
that we may have avoided duplicated calculation when multiple states
changed.
Bug: b/433331119
Change-Id: I3227c72bc40501712db93fb3d540b835f07150b5
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4514436
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
2ef85c24
|
2025-07-09T17:13:52
|
|
Vulkan: Add support for GL_EXT_fragment_shading_rate
Add support for GL_EXT_fragment_shading_rate.
Bug: angleproject:420310117
Change-Id: I7b368afc45baf8551c222b2569991269117d385b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6726817
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Auto-Submit: Panfeng Hou <panfeng.hou@arm.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
279652e3
|
2025-07-21T16:21:28
|
|
Vulkan: Flush more often due to render pass count
Accumulating too much workload before submission can lead to
stuttering and reduced quality in rendering. In this change,
a threshold is set for the number of render passes in order to
submit the command buffer.
* Added the following to ContextVk: mRenderPassCountSinceSubmit
* It is incremented every time a render pass begins in the command
buffer.
* When the count reaches the following threshold at the RP closure,
there is a submission: kMaxRenderPassCountPerCommandBuffer
* (Currently set to 128)
Bug: b/426439980
Change-Id: I4cde223fb81e6a27a61f78c924d3c9f2a082e995
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6775626
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
b4d84458
|
2025-05-23T18:08:19
|
|
Move Buffer from VertexBinding to VertexArray
In later CL we will not taking shared context lock for certain
VertexArray API calls. VertexArray itself is per context, so this sounds
reasonable to do. The main challenge here is a lot of VertexArray
function end up accessing gl::Buffer object, which could be modified by
other shared contexts. In order to safely not taking the shared context
lock, we need to separate out Buffer object out of VertexArray itself so
that these lockless APIs will take VertexArray that does not have access
to buffer.
In this CL, VertexArray is split into two classes: VertexArrayPrivate is
everything in VertexArray except buffers. VertexArray is a subclass of
VertexArrayPrivate and owns all the buffers. Buffer is removed from
gl::VertexBinding class. In order to let back end access to buffers,
VertexArrayImpl holds a weak reference to
VertexArray::mVertexArrayBuffers (which is a vector of buffers).
Further, VertexArrayBufferBindingMask mBufferBindingMask is moved from
VertexArrayState into VertexArray class well, since it tracks which
index has a non-null buffer. The bulk of change are due to the
VertexARrayImpl constructor change, since it now takes
vertexArrayBuffers argument. Other bulk of changes are due to
VertexBinding no long has the buffer, but you need to get it directly
from VertexArray or VertexArrayImpl.
This CL also reverts some of the change in crrev.com/c/6758215 that
mVertexBindings no longer contains kElementArrayBufferIndex.
BYPASS_LARGE_CHANGE_WARNING
Bug: b/433331119
Change-Id: I15f4576f7c5c8d8f4d9c9c07d38a60ce539bfeea
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6774702
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
4f4eab29
|
2025-06-30T14:58:28
|
|
Reset index buffer offset between indirect GL_LINE_LOOP draws
In two consecutive glDrawArraysIndirect with GL_LINE_LOOP mode, and
bound to a different Indirect Buffer, the variable value captured
through TransformFeedback is the same as the first result when the
second DrawArraysIndirect.
When calling DrawArraysIndirect the second time, DIRTY_BIT_INDEX_BUFFER
should be set to dirty so that it re-gets INDEX BUFFER to get the
correct result.
Bug: angleproject:428561247
Change-Id: I7f4ebb53e20cf8e362e67679b45185b8b68c56ef
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6687309
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Auto-Submit: Tingwei Guo <tingwei.guo@arm.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
890b5d8f
|
2025-07-07T13:06:54
|
|
Vulkan: Encapsulate more descriptor set logic in ProgramExecutableVk
- ProgramExecutableVk handles SharedDescriptorSetCacheKey updates
- Inline most update*DescInfo methods
- Add dedicated methods to handle uniform and storage buffers to remove
some branches from frequently used code paths
Bug: angleproject:426412564
Tests: UniformBufferTest31.UniformBufferBindingRangeChangeWith*FBF
Change-Id: I54b8ae2bd8778231e4d187b2cfd30f4d71de7f3b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6733546
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
|
|
065b80a6
|
2025-07-10T15:50:43
|
|
Vulkan: Remove the enum to indicate submitted CB
Currently, the function ContextVk::submitCommands() takes the
following enum to indicate whether all command buffers or only
the outside command buffer is submitted: "Submit"
However, ContextVk::submitCommands() is only called twice. Also,
this enum is only used to manage a few things, such as garbage
collection, and finalizing foreign image layouts.
It is possible to move these operations to the respective callers
and remove this enum completely.
* Moved the operations relying on the enum "Submit" to the locations
before submitCommands() as required.
* Removed the enum "Submit".
(Credit for the idea to move the ops up to the callers: cclao)
Bug: b/425987310
Change-Id: Ic0e1c15ee3d2e7cf22a4f7a57b6ac31acc38c861
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6724899
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
3b90872b
|
2025-07-06T09:02:27
|
|
Vulkan: Selectively invalidate uniform buffers
Call invalidateCurrentShaderUniformBuffers iff current program
has active uniform buffers. Also add DIRTY_BIT_UNIFORM_BUFFERS bit
to mNew*CommandBufferDirtyBits
Bug: angleproject:426412564
Bug: angleproject:429585235
Tests: UniformBufferTest31.UniformBufferBinding*WithMultiplePrograms*
Change-Id: I88c37c8317205aecad638553846ffe3beff87f11
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6706537
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
30a1cbc9
|
2025-07-03T13:00:05
|
|
Vulkan: Separate out descriptor set for uniform buffers
Bug: angleproject:426412564
Change-Id: Icdbb1e634fc543714d1e3b9cdba0530d400cb153
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6705153
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
ce289330
|
2025-07-01T19:41:46
|
|
Vulkan: Simplify descriptor set management
- Descriptor logic is contained in ProgramExecutableVk and
doesn't leak into ContextVk
- Reduces CPU overhead by not having to constantly copy and
resize the DescriptorSetDescBuilder
- Simplifies decoupling of descriptor set of uniform buffers
from that of other shader resources
Bug: angleproject:426412564
Change-Id: Ic0926d0d466ea21f611c2b2c7b844e0bb9027c1b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6702410
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
bb3f79dc
|
2025-06-26T16:59:48
|
|
Reorder shader resource dirty bits
Process storage and atomic buffer dirty bits before uniform dirty bits.
This helps the vulkan backend avoid duplicate work when multiple shader
resources are dirty
Bug: angleproject:426412564
Change-Id: Ibab3da44ee32d22078df851bfed4967d1c2a605e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6680035
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
b3ec3a5f
|
2025-06-23T14:51:13
|
|
Track active uniform and storage buffer blocks
Track active uniform and storage buffer block indices
so we can process updates to only active buffer blocks
Bug: angleproject:426412564
Change-Id: I54fa6fbe795073887646d672303d231ed4317b65
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6663825
Commit-Queue: mohan maiya <m.maiya@samsung.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
2fd033d0
|
2025-05-22T04:21:11
|
|
Vulkan: Optimize updates to uniform buffers
... when only the offset is modified. Most of the work done when
handling dirty uniforms can be skipped since the buffer bindings
haven't changed
Bug: angleproject:386749841
Tests: UniformBufferTest31.UniformBufferBindingRangeChange*Vulkan
Change-Id: Ic811bd71f0f2993f88ce9bcf93f9e8e46dfc6d99
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6581359
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
|
|
6bb47e67
|
2025-06-17T13:42:47
|
|
Vulkan: Limit finalizing foreign image layouts
Currently, any submission results in finalizing all foreign images.
However, if the submission is only limited to the outside render pass
command buffer, this would result in oldLayout VVL errors (01197), as
it would be too early to finalize the layout of such images at those
times. At this time, this type of submission can occur if the size of
buffer-to-image updates exceeds the following threshold:
kMaxBufferToImageCopySize
In this change, finalizing the foreign image layouts would only occur
when all commands are being submitted.
* In ContextVk::submitCommands(), finalizeAllForeignImages() is now
called only when the submission type is Submit::AllCommands.
* Added new submit tests for foreign images to ImageTest:
* UploadForeignUntilSubmitDoesNotBreakRenderPass
* CopyToForeignUntilSubmitDoesNotBreakRenderPass
Bug: b/425987310
Change-Id: Ia345e176be79017ba18ef52a57256eeeb298e39a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6653602
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
c45e7c83
|
2025-05-22T04:14:52
|
|
Vulkan: Optimize uniform and storage buffer updates
Maintain a map between buffer block index and its DescriptorDesc index
in WriteDescriptorDescs and look up the map instead of repeatedly
calculating it when updating DescriptorDesc
Bug: angleproject:386749841
Change-Id: I74d14f6205f07992fae1e338697998d04de1c563
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6603986
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
|
|
db962407
|
2025-06-03T08:00:43
|
|
Vulkan: Optimize FramebufferVk::getSamples()
Cache value of samples during syncState(...) and return this value
on subsequent queries
Bug: angleproject:386749841
Change-Id: I21fb2221187c7b2159fed1b271da642ba2552348
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6619019
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
|
|
ef31b3ed
|
2025-06-04T12:00:04
|
|
Vulkan: Selectively dirty DIRTY_BIT_SAMPLE_SHADING
When program executable changes dirty DIRTY_BIT_SAMPLE_SHADING bit
if either the current or previous program enabled per sample shading
Bug: angleproject:386749841
Change-Id: I82aa7df29473e455aa68dfba9fefdb1bc712a78d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6622156
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
90668ecf
|
2025-05-25T10:51:52
|
|
Vulkan: Reset uniform buffer dirty bit on program change
When a program changes all of its non-texture shader resources are
invalidated, there is no need to re-invalidate uniform buffers.
Bug: angleproject:386749841
Change-Id: I7e941784c40046cef3a2ce297e6941a963b3a8dc
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6583476
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
|
|
2a18fdbf
|
2025-05-21T16:14:51
|
|
Fix sync issue between XFB output and UBO input
For the following scenario, where the first draw writes to the
transform feedback buffer and the second draw reads from the
same buffer as UBO, it is necessary to end the render pass
between the two draws and add a barrier.
// xfb write
glBindBufferBase(GL_TRANSFORM_FEEDBACK_BUFFER, 0, xfb);
glBeginTransformFeedback();
glDrawArrays();
glEndTransformFeedback();
// Draw with same buffer as UBO
glBindBuffer(GL_UNIFORM_BUFFER, xfb);
glDraw();
Bug: angleproject:418568423
Change-Id: Ia294d174111c6104b55762590ec26056ee759b53
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6572198
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
ad05f93b
|
2025-05-08T00:00:00
|
|
Vulkan: Fix debug marker handling
Used passed length in InsertEventMarker and
PushGroupMarker commands because markers do
not have to be null-terminated.
Bug: angleproject:408709155
Change-Id: I6221223dabc1b01dbc175bfb7f5aeb41b9e67c6f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6552401
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
|
|
3bbdee0f
|
2025-03-28T11:55:24
|
|
Vulkan: Remove Subject/Observer from BufferImpl
Right now the gl::Buffer back end send message to the front end and then
gl::Buffer propagate the message to the observers (vertex array,
textures, transform feedback). We are seeing many of these kind of
message passing (mainly to vertexArray), and each message is a virtual
function call. The message call also lacks of context information that
we can not do certain optimizations. This CL adopts the new API feedback
argument approach for buffer APIs from the back end to the front end.
The only difficulty I ran into is D3D backend where the message could be
delivered from draw calls. For now the subject/observer code path is
still kept in the gl::Buffer, but no back end will use it except D3D11.
That will be removed in the later CL when D3D11 switch to use feedback
mechanism.
BYPASS_LARGE_CHANGE_WARNING
Bug: angleproject:400711938
Change-Id: I5fb3b660fd4260b9ba691239ad777b575b31e2ab
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6408892
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
c884460a
|
2025-04-24T16:43:04
|
|
Vulkan: Fix deferred clears vs noop multidraw
Bug: chromium:407828338
Change-Id: I5da22aeb72605bb7943fa5ae079ae297d00888f7
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6488794
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Cody Northrop <cnorthrop@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
f355e2b3
|
2025-04-15T18:58:25
|
|
Vulkan: Remove preferDriverUniformOverSpecConst
This was practically true for every vendor on Android (where rotation
matters). For Qualcomm, it was also true due to a bug in version
checking and didn't seem to be causing any concerns. Where pre-rotation
is supported, it is better to enable this feature to avoid excessive
pipeline creation.
This change removes the feature and makes sure ANGLE always uses
uniforms for rotation instead of spec consts. While technically this
may have an adverse effect on platforms that never need pre-rotation,
the ability is retained for all vendors since pre-rotation is finding
its way into more platforms and would likely eventually be needed
everywhere anyway.
Bug: angleproject:42265878
Bug: angleproject:42262166
Change-Id: I4b64c04da46db08cfdd44b60789b66d93d8e8b17
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6459025
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: mohan maiya <m.maiya@samsung.com>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Cody Northrop <cnorthrop@google.com>
Reviewed-by: Cody Northrop <cnorthrop@google.com>
|
|
a6a7de5a
|
2025-04-16T14:28:13
|
|
Vulkan: Sync perf counters in finishImpl(...)
.. instead of finish(...) so other code paths like onDestroy(...)
have a chance to update perf counters before decoupling from the
sharegroup
Bug: angleproject:386749841
Change-Id: Ib0f847dda2274686ed9e5d3c8211ee5a364e4b65
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6463366
Commit-Queue: mohan maiya <m.maiya@samsung.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
49d0a332
|
2025-04-08T16:07:17
|
|
Vulkan: Remove ring buffer allocators
* Removed the ring buffer allocator functionality from ANGLE:
angle::RingBufferAllocator
* Also removed the related common files.
* (Pool allocators will be used at all times.)
* Removed the placeholder functions from the pool allocator.
* Removed the following BUILD flag:
angle_enable_vulkan_shared_ring_buffer_cmd_alloc
* Removed redundant line from ContextVk.
Bug: b/410036490
Change-Id: I368fb93a66ddfd192018b09f65004a32339abd5a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6442640
Reviewed-by: Igor Nazarov <i.nazarov@samsung.com>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
e44357c6
|
2025-03-25T15:50:15
|
|
Vulkan: Do not defer ANI in shared present mode
Calling ANI in shared present mode is not necessary after the initial
acquire. Skip calling `deferAcquireNextImage()` in that mode.
For code simplicity and as a preparation for (anglebug.com/400711938),
the `invalidateSwapchain()` method is now also defers ANI and notifies
`SubjectMessage::SurfaceChanged` to the parent class. `Framebuffer`
message handling was updated to also reset color buffer dirty bit and
to notify `SubjectMessage::DirtyBitsFlagged` if needed, as in the
`SubjectMessage::SwapchainImageChanged` message case (which will be
removed in future CL). This way, single `SubjectMessage::SurfaceChanged`
message is enough to handle swapchain recreate.
The `VK_SUBOPTIMAL_KHR` is no longer treaded as OUT_OF_DATE when in
shared present mode. Added for consistency (since we are already
skipping "perFrameWindowSizeQuery" checks), to preserve content, and to
match the Android native GLES driver behavior.
Call `invalidateSwapchain()` when swapchain operations fail to avoid
repeated swapchain use and to be able to recover from the error.
The `checkForOutOfDateSwapchain()` was split into two methods:
- checkForOutOfDateSwapchain():
- Called only after present.
- Checks present out of date result and present mode compatibility.
- Invalidates the swapchain and updates the present mode if the above
checks fails.
- prepareSwapchainForAcquireNextImage():
- Calls `queryAndAdjustSurfaceCaps()` and `recreateSwapchain()`
if swapchain is invalid.
- Calls `queryAndAdjustSurfaceCaps()` and checks surface properties
when "perFrameWindowSizeQuery" is enabled. Then calls
`recreateSwapchain()` if something changed.
Other changes:
- The `prepareForAcquireNextSwapchainImage()` method was replaced with
`prepareSwapchainForAcquireNextImage()`.
- Removed `doDeferredAcquireNextImageWithUsableSwapchain()` and
`postProcessUnlockedAcquire()` methods because of redundancy.
- Move image invalidation code into `acquireNextSwapchainImage()` to
make `doDeferredAcquireNextImage()` simpler.
- Convert `resizeSwapchainImages()` into `createSwapchainImages()` for
simplicity.
Updated old and added new tests.
Test: angle_end2end_tests --gtest_filter=EGLSurfaceTest.ReadFramebufferBindingSyncState/*
Test: angle_end2end_tests --gtest_filter=EGLSingleBufferTest.OnCreateWindowSurface/*
Test: angle_end2end_tests --gtest_filter=EGLSingleBufferTest.OnSetSurfaceAttrib/*
Test: angle_end2end_tests --gtest_filter=EGLSingleBufferTest.WindowResize/*
Test: angle_end2end_tests --gtest_filter=EGLSingleBufferTest.WindowRotation/*
Bug: angleproject:400711938
Bug: angleproject:397848903
Bug: angleproject:42262606
Change-Id: I2247417aa8b7b5afc10a8420083aeb845895aec9
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6387920
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
|
|
e339f91c
|
2025-03-21T10:22:59
|
|
Vulkan: Split asyncCommandBufferResetAndGarbageCleanup into two
Right now this one feature flag controls garbage clean up and command
buffer reset. If this is enabled, we are seeing command buffer reset
some times runs on small core and some times gets blocked by mutex lock
inside vulkan driver. This could take quite long while main rendering
thread is blocked by ANGLE's CommandPoolAccess lock. This CL splits this
feature flag into two separate feature flag: asyncGarbageCleanup
controls garbage clean up in the async thread or not.
asyncCommandBufferReset controls commandBuffer.reset in the async thread
or not.
This CL also disables commandBuffer.reset in async thread only on ARM
given there is no data shows other GPUs suffer form the same problem.
Bug: angleproject:378718508
Change-Id: Ice87b5b91568a0a95e0064da2b70243516ff6753
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6381893
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Roman Lavrov <romanl@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
05c491e1
|
2025-03-15T11:56:07
|
|
Vulkan: Optimize GraphicsDriverUniforms update
Unless RP is closed there is no need to dirty GraphicsDriverUniforms
when the program executable changes.
Bug: angleproject:386749841
Test: VulkanPerformanceCounterTest.NoUpdatesToGraphicsDriverUniformsOnProgramChange*
Change-Id: Id02e8a17de93e2b73103666fc6cc62ce3cdd8f43
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6358315
Commit-Queue: mohan maiya <m.maiya@samsung.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
d668a13c
|
2025-03-14T17:18:18
|
|
Fix sync issue between XFB output and texture buffer input
For the following scenario, where the first draw writes to the
transform feedback buffer and the second draw reads from the
same buffer as a texture buffer, it is necessary to end the
render pass between the two draws and add a pipeline barrier.
// xfb write to tex_buffer
glBindBufferBase(GL_TRANSFORM_FEEDBACK_BUFFER, 0, tex_buffer);
glBeginTransformFeedback();
glDrawArrays();
glEndTransformFeedback();
// Draw with texture buffer tex_buffer
glBindBuffer(GL_TEXTURE_BUFFER_EXT, tex_buffer);
glTexBufferEXT(GL_TEXTURE_BUFFER_EXT, ..., tex_buffer);
glDraw();
Bug: angleproject:403319685
Change-Id: I9381a336ce61dea696c93158bb617a41afcfc583
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6356070
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Auto-Submit: Mavis Deng <mavis.deng@arm.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
dae3c851
|
2025-03-14T11:44:53
|
|
Vulkan: Bake non-shader state into linked pipeline
When using VK_EXT_graphics_pipeline_library, previously ANGLE would
create three pipelines libraries:
* The Shaders library was created based on the GL program's shaders + a
few static states. This typically hit the program's own pipeline's
cache that was warmed up during link.
* The VertexInput and FragmentOutput libraries were created at draw
time, which used the global pipeline cache
At draw time, immediately after creating the non-Shaders libraries, the
three libraries were linked into the final pipeline to be used by the
draw call.
This caused an inefficiency; because the non-Shaders libraries were
created independently from the Shaders library, they had to be compiled
pessimistically, for example because they could not be optimized to take
into account the precision of the fragment shader's outputs or whether
any value is const (typically alpha being set to one).
Given the creation of VertexInput and FragmentOutput libraries is
typically quite fast (the former being no-op and dynamic state anyway),
this change removes the need for creating those libraries, and directly
specifies the vertex input and fragment output state when creating the
final pipeline out of the Shaders library.
In this way, the same fragment output state can be tailored to the exact
shaders it is being used with and incur a smaller overhead. In this
change, the linked pipeline is cached in the GL program's pipeline
cache, which is never synced to the blob cache as producing it is
assumed to be fast already.
Bug: angleproject:42265839
Change-Id: I8496ea37771555522bdc9de94043a1b56fa5967e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6354205
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: mohan maiya <m.maiya@samsung.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
2f5a91ba
|
2025-02-24T17:25:10
|
|
Vulkan: Remove checkForOutOfDateSwapchain ContextVk dependency
This is the continuation of the previous CL. After this CL it is now
possible to call `prepareForAcquireNextSwapchainImage()` from
`lockSurface()` that will also do necessary swapchain recreation in
case of window resize.
These methods required `ContextVk` pointer before this change:
- RenderTargetVk::releaseImageAndViews()
- replaced with `releaseSwapchainImage()` that does not release
framebuffer because Window Surface framebuffers are not managed by
the cache.
- added `release()` method that does release the framebuffer.
- WindowSurfaceVk::releaseSwapchainImages()
- use `Renderer::collectGarbage()` instead of
`ContextVk::addGarbage()`.
- use `ImageHelper::releaseImage()` instead of
`ImageHelper::releaseImageFromShareContexts()`. The
`finalizeImageLayoutInShareContexts()` was not required since
renderpass must be already ended, because swapchain recreate is only
possible after present. Removal of `addToPendingImageGarbage()` is
not going to cause OOM problems, because repeated swapchain
recreate calls are not possible without swap (submissions).
Bug: angleproject:397848903
Bug: angleproject:42264593
Change-Id: Iacfa3a144aa980659569b7100be25a44ebb9f0a0
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6298734
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
318d4038
|
2025-02-18T13:19:28
|
|
Vulkan: Fix present optimization w.r.t shared present mode
Since the implementation of "EGL_KHR_mutable_render_buffer" mode
(angleproject:42262606), the renderpass optimization for present
(b/153885625) was not working correctly. It sill tries to transition
into `ImageLayout::Present`, but instead of entirely skipping the
transition, it inserts the barrier even when renderpass is still opened.
When both "supportsSharedPresentableImageExtension" and
"preferDynamicRendering" are enabled, code will hit ASSERT in
`flushToPrimary()` when attempting to record `ImageLayout::Present`
barrier into the primary command buffer.
Above issue is fixed by skipping the transitioning into
`ImageLayout::Present` when in shared present mode.
Other changes and fixes:
- removed renderpass flush when resolving with renderpass, since it is
not necessary (angleproject:42265256).
- above change reveled a bug in `finalizeImageLayout(&mColorImageMS)`
call. This call reverts the layout in the previous finalize call
from Present to ColorWrite. So it must have been inserted before
finalizing the swapchain image. Issue fixed by removing both finalize
calls.
- updated condition to skip invalidate w.r.t shared present mode
(b/229689340), that was missed during implementation of
"EGL_ANDROID_front_buffer_auto_refresh" (angleproject:42265697).
Test: angle_end2end_tests --gtest_filter=EGLSurfaceTest.PresentLayoutTransitionWithMSAA/*
Bug: b/153885625
Bug: angleproject:42262606
Bug: angleproject:42265256
Bug: b/229689340
Bug: angleproject:42265697
Change-Id: Ifad8aea8548fa7bfac27941812c435b2af655309
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6277445
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
|
|
ae567733
|
2025-02-26T19:09:14
|
|
Vulkan: Make use of VK_EXT_device_fault if exists
This Vulkan extension, if available, can provide further details
about the device in case of VK_ERROR_DEVICE_LOST.
* Added the following ANGLE feature: supportsDeviceFault
* It shows whether the extension VK_EXT_device_fault is supported
and that the deviceFault bit is enabled on the physical device.
* Added the Vulkan entry point for the following function:
* vkGetDeviceFaultInfoEXT
* Added the following to the renderer:
* mFaultFeatures (device feature)
* retrieveDeviceLostDetails(); to log information regarding the
following if the appropriate support is available:
* Address faults
* Vendor-specific faults
* Vendor binary dump (logged in hex format)
* Added RetrieveDeviceLostInfoFromDevice() to vk_renderer.cpp
to be used in Renderer::retrieveDeviceLostDetails().
* Updated ContextVk::handleError() to try to retrieve more info in
case of DEVICE_LOST.
Bug: b/399478440
Change-Id: If8d8e04001dabbe775c023f9922c44ef2205317e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6305888
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
2e65d3d4
|
2025-02-03T16:26:46
|
|
Vulkan: Fine-tune submission for multiple RPs
This CL aims to fine-tune submission based on a certain command
buffer size. This allows us to perform one submission for multiple
smaller render passes.
* Added mCommandsPendingSubmissionCount to ContextVk.
* In ContextVk::syncState(), preferSubmitAtFBOBoundary is only used
if the render pass pending command count exceeds the threshold:
kMinCommandCountToSubmit
* Currently set to 32.
* For now, we still submit if the command is a clear (for example
glClearBufferfv()).
* For now, we also still submit if the command is an invalidate
(for example, glInvalidateFramebuffer()).
* In ContextVk::flushImpl(), if the pending command count exceeds the
threshold (kMinCommandCountToSubmit) and the device is found to be
idle, the work is submitted to keep the device busy.
* Modified the following unit test from VulkanPerformanceCounterTest:
VerifySubmitCounterForSwitchUserFBOToDirtyUserFBO
* Since there is now a minimum command count for submission, the
number of draw calls has been changed so that the submission is
still issued at the new FBO boundary.
* After this CL, life_is_strange shows the following improvements:
(From the latest measurements)
* +19% wall_time
* +38% cpu_time
Bug: angleproject:42265052
Change-Id: I18452cc1d39ca7e0ac376f6012974b498153cce8
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6182927
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
055123f8
|
2025-02-27T10:45:56
|
|
Vulkan: Don't maintain SharedCacheKeyManager for BufferBlock
Dynamic descriptor type uses the underlying BufferBlock in the
descriptorSet. There could be many BufferHelper objects sub-allocated
from the same BufferBlock. And each BufferHelper could combine with
other buffers to form a descriptorSet. This means the combination for
BufferBlock could potentially be very large, in thousands with some app
traces like seeing in honkai_star_rail. The overhead of maintaining
mDescriptorSetCacheManager for BufferBlock could be too big. In this CL
I have chosen to not maintain mDescriptorSetCacheManager in the
BufferBlock. The only downside is that when BufferBlock gets destroyed,
we will not able to immediately destroy all cached descriptorSets that
it is part of. They will still gets evicted later on if needed (see
evictStaleDescriptorSets for detail). After this CL, running with all
app traces we have, the max vector size of
SharedCacheKeyManager::mEmptySlotBits is no more than 2, versus ~70s
before the CL.
Bug: b/384839847
Bug: b/293297177
Bug: b/237686097
Change-Id: I7c7c91cd0aeacba4145575ac4270b713bf38b742
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6310837
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
5775a974
|
2025-02-21T11:00:05
|
|
Vulkan: Fix transition to FORIEGN and back in same submission
Image layout transitions are typically automatically handled. In some
cases however, the image layout is specifically "finalized". For
foreign images, the relevant cases are all about the point in time when
the image is being released.
When a foreign image's layout is finalized, a barrier is generated to
transition it to the FOREIGN queue on submission. Previously, an
incorrect assumption was made that after such a point, the VkImage will
no longer be used by any commands.
This was incorrect because of EGL Images, which let the same VkImage
(and ImageHelper) be shared between multiple textures. The following
scenario broke that assumption:
- Texture is bound to the (foreign) EGL image
- Texture is used and deleted
* VkImage's transition back to foreign is cached, but not executed
- Another texture is bound to the same EGL image
- Texture is used
* At this point, the texture is re-acquired from foreign, but it
wasn't released in the first place!
In this change, a vkQueueSubmit is issued after the foreign image's
layout is finalized to make sure the transition back to FOREIGN is
applied.
Bug: angleproject:42263241
Bug: angleproject:42262454
Bug: angleproject:390443243
Bug: chromium:382527242
Change-Id: Ibe3e6d60f282f9fb0eed1deba3325456017c3617
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6292804
Reviewed-by: mohan maiya <m.maiya@samsung.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
c96844d9
|
2025-02-14T10:26:25
|
|
Vulkan: More vector storage fix
BufferPool::mBufferBlocks reserves 32 entry storage based on data
gathered from trace.
BufferPool::mEmptyBufferBlocks switched to queue since we almost never
walk the entire list unless it gets destroyed.
Renderer::CollectGarbage is changed to take only one object. The only
time it get called with more than one object is from
ImageHelper::releaseImage(), which in this CL we now creates and pass
GarbageObjects to Renderer::collectGarbage directly. This also allows me
to delete recursive CollectGarbage() and DestroyGarbage() functions
(which is doing emplace_back quite often, even though only two entries).
PipelineHelper::mTransitions is updated to reserve storage for 8 entries
based on trace data.
Bug: b/293297177
Change-Id: I3e4552939a780dd26f9b7b8a67deee0d52d4f9bc
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6270518
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
ffb7575c
|
2025-02-07T10:25:22
|
|
Vulkan: Reserve reasonable amount storage for GarbageObjects
Based on data collected from app traces, set the initial storage enough
to accommodate most of the usage cases.
For ContextVk::mCurrentGarbage, the problem is that after the
collectGarbage call, it lose the capacity value, so next time it end up
with 0 and slowly grow the capacity again. This CL always keeps the
capacity after the collectGarbage call.
Bug: b/293297177
Change-Id: I70deccd879311aebe6ea3bbf4ecf5c54a74ef584
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6244922
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
03019646
|
2025-01-29T10:36:38
|
|
Vulkan: Fix invalidate of emulated format followed by more draws
If invalidating a color image with emulated channels, a clear is
automatically staged so the emulated channels don't contain invalid data
later. This is problematic with deferred clears; the clear marks the
framebuffer attachment as dirty, and the next command causes
`FramebufferVk::syncState` to pick the clear up as a deferred clear.
This is normally correct, except if the following command is another
draw call; in that case, the render pass does not close, yet the clear
is cached in `mDeferredClears`. When the render pass later closes, it
undoes the invalidate and attempts to remove the clear from the image...
but it does not exist there anymore (it's in `mDeferredClears`). Next
usage of the image then clears it, undoing the draws after invalidate.
In this case, the simplest approach is to close the render pass right
away here. Note that it is not possible to make
`FramebufferVk::syncState` avoid picking up the clear in
`mDeferredClears`, not apply the clear, _and_ keep the render pass open;
because future uses of the image (like with |glReadPixels|) will not
trigger `FramebufferVk::syncState` and the clear won't be done.
Bug: angleproject:353167428
Change-Id: Ie677bd12d9f11953cdcd5e4c374b59c4f63e7456
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6214331
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
0f75fc3d
|
2025-01-20T14:10:41
|
|
Vulkan: Transition foreign images to the FOREIGN queue on submit
Vulkan's interaction with AHB and dmabuf images is through the FOREIGN
queue family. When ANGLE uses these images, it must take ownership of
the images by doing a queue family ownership transfer (QFOT) away from
the FOREIGN queue family and into the graphics queue family used by the
Vulkan backend.
Prior to this change, ANGLE would do the QFOT away from FOREIGN once
such a foreign image is imported into an EGL image. Afterwards, usage
in ANGLE works correctly. What ANGLE did not handle is when a foreign
entity wants to use these images _after_ ANGLE has used them.
For the above to work correctly, ANGLE must do a QFOT back into FOREIGN
before the image can be used by the foreign entity. Unfortunately,
EGL does not provide a clear point for this hand-off to happen. ANGLE
has no choice then to proactively transition the images back into
FOREIGN at some point "just in case".
For some native drivers, this hand-off to FOREIGN can be quite frequent.
For example, on Android for most vendors there is no actual layout
transition between graphics and FOREIGN queue families (the actual data
layout is the same), so a cache flush/invalidate at strategic points
(such as the end of the command buffer) is sufficient as equivalent to
transition to FOREIGN (and another at the beginning of the command
buffer as equivalent to transition from FOREIGN).
As a layer over Vulkan's formalism, ANGLE is less lucky; it has to
enumerate exactly which image is being transitioned to and away from
FOREIGN. Transitions away from FOREIGN are in principle easy. As long
as the image is marked as being in the FOREIGN queue family, it will
automatically transition to the graphics queue family on first use.
In this change, when a foreign image is transitioned out of the FOREIGN
queue, it's added to a list of images to be transitioned back to FOREIGN
at submit time. Once submission is done, the image may or may not
actually be used by a foreign entity, but ANGLE cannot know that. The
next time the image is used in ANGLE, it is transitioned out of FOREIGN.
Verifying correctness with multi-threading is tricky, and relies on GL's
requirement that access in one context is followed by a synchronization
and rebind in another context before it can be used there. This means
that the image's transition to FOREIGN (at the end of one submission)
naturally happens before the transition back from FOREIGN (at the
beginning of the next submission). Because the set of images to
transition is tracked in the context, submissions in other contexts
don't interfere with the above logic.
The situation can be more complicated with one-off submissions, but
fortunately, no such usage of foreign images is present.
Another wrinkle is simultaneous usage of the image as read-only in two
contexts. According to GL, this is not a hazard and requires no
synchronization. However this is broken in ANGLE even for non-foreign
images (see http://anglebug.com/42266349), because as what _seems_ like
read-only usage of the image from GL's point of view (like sampling from
the image), there are associated write operations from Vulkan's point of
view (image layout transitions and QFOT). This change does not attempt
to address this corner case.
Bug: angleproject:42263241
Bug: angleproject:42262454
Bug: angleproject:390443243
Bug: chromium:382527242
Change-Id: Idd4ef1fecfa3fccf1a4063f1bddb08d28b85386b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6184604
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
adb52e06
|
2025-01-23T17:36:44
|
|
Avoid unnecessary copy ctor calls of gl::DepthStencilState
That object has a user defined copy ctor to copy padding
(https://crrev.com/c/783990). This together with copying instead of
using a reference results in a function call (which just wraps memcpy)
Bug: b/383305597
Change-Id: Ia92e726a887bd12ab14c1ca53f79c0b13b57a199
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6194695
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Roman Lavrov <romanl@google.com>
|
|
c3f9109e
|
2025-01-09T17:22:41
|
|
Vulkan: Change EventMaps from struct to class
For better encapsulation, this CL turns struct EventMaps to class
RefCountedEventArray.
Bug: angleproject:360274928
Change-Id: Ie28996fdb95d5a830399e6fa6cd5602f403e8725
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6164698
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
fbd230f5
|
2025-01-23T12:59:06
|
|
Vulkan: Split ErrorContext into ErrorContext and Context
ErrorContext continue to be context for error handling. vk::Context is
added to serve as common base class for ContextVk and CLContextVk.
Bug: angleproject:390443243
Change-Id: Ifac0b1d2d714ce610693ce60a35459c6c9cddf1a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6191438
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
c1214ec2
|
2025-01-22T14:22:56
|
|
Vulkan: Rename Context to ErrorContext
In preparation for adding another Context (derived by GL and CL
contexts), which includes logic that pertains to command recording (such
as barrier tracking).
Bug: angleproject:390443243
Change-Id: Idf495b62e63fb9aa901a2f16447fdaf3c2acd90b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6191248
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
40267ddc
|
2025-01-14T12:51:00
|
|
Vulkan: Add bufferWrite for multiple shader stages
This is mostly a clean up CL. When a buffer is used in multiple shader
stages, it was inserting barrier multiple times by calling bufferWrite
in a loop. This creates unnecessary barrier against one shader stage to
another shader stage. This CL adds a multiple shader stages version of
bufferWrite that takes "const gl::ShaderBitSet &writeShaderStages" as an
argument, in consistency to bufferRead. Otherwise this creates a problem
in future CLs where we use VkEvent to track the write and you end up
with WAW of the VkEvent that has not submitted.
Bug: angleproject:360274928
Bug: angleproject:42262235
Change-Id: I923dc9df39318d337f67f4fa0f6a68f336df24f7
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6180948
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
1d25be59
|
2025-01-09T11:09:22
|
|
Vulkan: Pass Context instead of Renderer to BufferHelper APIs
This is preparation CL for later CL. In later CL we need to access
context argument in BufferHelper's barrier related functions. release()
also preferred to have context argument so that the events can be
recycled within share group. Because of this, a lot of functions has to
propagate back to pass context as argument instead of renderer.
Bug: angleproject:360274928
Change-Id: I13e930666eeeefbcff7b542d0e3126f3b07ce286
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6164686
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
d8a95bf7
|
2024-12-19T17:35:05
|
|
Vulkan: Protect OneOff commands recording with pool mutex
Bug: angleproject:384940864
Change-Id: I518c54ae4b0fc5da0e58d330f8c531bc8d65529e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6108843
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
a5016e31
|
2025-01-17T17:50:27
|
|
Vulkan: Fix typos found by gerrit spellchecker
Bug: angleproject:360274928
Change-Id: Idbffd7a4609f28d161bd0a11ace817856dcd750c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6182930
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Auto-Submit: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
0554e7f0
|
2025-01-09T10:05:12
|
|
Vulkan: Resume render pass queries when render pass reactivates
Bug: angleproject:388144480
Change-Id: Ibcf3b247f347705feed4aa43d237406ccb142704
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6185098
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
f72428bb
|
2025-01-10T22:24:07
|
|
Vulkan: Fix MSAA swapchain resolve out of render pass
.. vs the optimization that transitions the swapchain image to
PRESENT_SRC as part of the render pass.
When the swapchain image is the resolve attachment, its layout is
decided when the render pass is closed (or through manual calls to
finalizeImageLayout()). If the render area forbids the swapchain image
from becoming the resolve attachment, it must be resolved after the
render pass.
Prior to this change, the swapchain image was still marked for
transition to PRESENT_SRC by the render pass. This is inefficient, as
the following out-of-render-pass resolve would have to transition the
image back out of PRESENT_SRC. Nevertheless, this also had a bug
exposed by an ASSERT in the dynamic rendering path:
* Before the out-of-render-pass resolve, the image layouts are
forcefully finalized.
* The code in finalizeImageLayout() checks which image is being
finalized; if the image is not any of the ones in the render pass, it
was silently ignored.
* The image marked for transition to PRESENT_SRC
(mImageOptimizeForPresent) is not separately checked, as it is
expected to be an attachment as well.
The code that optimized the final render pass always marked the
swapchain image for optimization, even if it was not going to become the
resolve attachment. This change makes sure this optimization is done
only if the image is definitely an attachment of the render pass.
Bug: angleproject:389048224
Change-Id: I9f451d2698944111ac96bd97fefd6efa23859b7f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6168388
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
0a207b65
|
2025-01-10T12:01:01
|
|
Vulkan: Assert size of GraphicsDriverUniformsExtended is within limits
ANGLE updates driver uniforms using push constants, ensure size of
ANGLE's driver uniform struct is within Vulkan spec's guaranteed limit
of 128 bytes.
Bug: angleproject:386749841
Change-Id: Iaa5ca8a46865a804b4c854ba27448bf4b6546646
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6164689
Commit-Queue: mohan maiya <m.maiya@samsung.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
bafb661e
|
2024-12-13T12:01:19
|
|
Vulkan: Remove debug log + dead code
Bug: angleproject:376572258
Change-Id: Ie774fd248a37fc65b4e05df0b4e4dffb778b9b4f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6090907
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Roman Lavrov <romanl@google.com>
Reviewed-by: Roman Lavrov <romanl@google.com>
|
|
c75bd915
|
2024-12-10T23:01:44
|
|
Vulkan: Remove asyncCommandQueue
It's been years and it never showed an advantage. In the meantime,
performance without this feature seems close to native drivers (i.e. the
feature has lost its appeal) and it's frequently a source of
complication and bugs.
Bug: angleproject:42262955
Bug: angleproject:42265241
Bug: angleproject:42265934
Bug: angleproject:42265368
Bug: angleproject:42265738
Bug: angleproject:42266015
Bug: angleproject:377503738
Bug: angleproject:42265678
Bug: angleproject:173004081
Change-Id: Id8d7588fdbc397c28c1dd18aafa1f64cbe77806f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6084760
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: mohan maiya <m.maiya@samsung.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
fc4fc174
|
2024-12-10T22:01:28
|
|
Vulkan: Prevent crash with D/S FF without D/S attachment
The spec says that the values for gl_LastFragDepth/StencilARM are
undefined if there is no depth/stencil attachment. This "just" works on
tiling GPUs, because reading input attachments simply translates to
reading _something_ from the tile memory.
For ANGLE, the situation is a little more complicated. ANGLE has to
bind descriptors for input attachments (because non-tilers read from the
input attachment descriptor instead of using the knowledge that input
and color/depth/stencil attachments are one and the same thing in tile
memory). When a depth/stencil attachment is missing, there is no image
to bind to the descriptor set.
ANGLE cannot skip binding an image to the descriptor set, because
OpImageRead (translated from subpassLoad()) attempts to access the
input descriptor; skipping this causes an internal crash in SwiftShader
for example.
ANGLE cannot bind a bogus image as input attachment, as Vulkan requires
that input attachments are also color/depth/stencil attachments.
ANGLE _could_ bind a bogus image as input attachment and also as
depth/stencil attachment. This is rather risky, as it then also has to
be careful to make sure that depth/stencil attachment is never actually
used (i.e. it affects the depth/stencil state, load/store ops etc).
In this change, the shader itself is modified to remove references to
the depth/stencil input attachments if the attachment is missing. This
is rather inefficient, as it means the pipeline warmup will not produce
a usable pipeline, but it's accepted as a workaround for something apps
shouldn't really be doing.
Bug: angleproject:376572258
Change-Id: I0de68252b61615cb82cba7d1730699aadf41e92f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6085368
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
e9ba1681
|
2024-12-10T21:29:26
|
|
Vulkan: Fix DR vs FF vs non-draw RP start
DR is Dynamic Rendering
FF is Framebuffer Fetch
RP is Render Pass
With DR, whether framebuffer fetch is used or not is no longer tracked
in the framebuffer's RenderPassDesc, because that property has no
bearing on the framebuffer anymore. It still exits in RenderPassDesc to
support legacy VkRenderPass objects.
After a draw call starts a render pass, the state of the command
buffer's copy of RenderPassDesc (copied from the framebuffer's) is
updated to include the correct framebuffer fetch mode. However, this
was not done when the render pass starts through other means, such as
when a scissored or masked clear would call `Context::startRenderPass`.
This change moves the aforementioned update of the framebuffer fetch
mode to `Context::startRenderPass` so it affects everywhere the render
pass may start from.
Bug: angleproject:383356851
Change-Id: I82eff43863fc5b9fe67e57453269ee73859a6cd7
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6085367
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
09578c42
|
2024-11-27T19:39:09
|
|
Vulkan: Cleanup CommandPoolAccess implementation
This is a follow up for:
Add a new mutex in CommandQueue to protect Vulkan Command Pool
crrev.com/c/angle/angle/+/6020895
Change simplifies `CommandPoolAccess` implementation as well as removes
source of bugs when need to know/remember what method from
`CommandPoolAccess` to use in order to collect/destroy the primary
command buffer.
Additionally, `CommandBatch` converted into a class to avoid invalid
use. The "retire" word replaced with "release" in methods such as
`releaseFinishedCommands()`.
Bug: b/362604439
Change-Id: Iaa72c55458604e5ea8ea5a402e437129a5c9180a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6056019
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
|
|
739bcef0
|
2024-12-03T17:58:34
|
|
Vulkan: Rework finishOneCommandBatchAndCleanup
This is a follow up for:
Vulkan: Fix finishOneCommandBatchAndCleanupImplLocked
crrev.com/c/angle/angle/+/6055419
The original `finishOneCommandBatchAndCleanup()` was not optimal in a
sense that it is always finish a batch, when cleaning existing garbage
may be sufficient. Also, because there was no feedback from the
`cleanupGarbage()`, this method may just end up finishing one batch
without cleaning any garbage, causing clients to "think" that there is
no more garbage to clean. Additionally, `cleanupGarbage()` was called
under the `CommendQueue::mMutex` lock, causing uncessary blocking.
This change replaces this method with new `cleanupSomeGarbage()`. It
solves all problems of the original method described above. It no longer
has the `retireFinishedCommandsLocked()` call, because it is not
necessary in scenarios where `cleanupSomeGarbage()` is used.
In order to implement the new method, output feedback parameter was
added to the `cleanupGarbage()` as well as to all methods that it uses.
Bug: b/280304441
Change-Id: I7078899838609a0c3e5edbc4f507c2fe4364380a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6063126
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
|
|
74609065
|
2024-11-27T16:09:44
|
|
Vulkan: Fix finishOneCommandBatchAndCleanupImplLocked
Fix the `finishOneCommandBatchAndCleanupImplLocked()` to always do
cleanup regardless if there is something to finish. This method is
designed not only to free space in `mInFlightCommands` but also to
cleanup already retired commends (in `mFinishedCommandBatches`) and
renderer's garbage. In case if `mInFlightCommands` is empty cleanup was
skipped - which is incorrect.
Change removed `Impl` from the name since it is already have `Locked`.
The `finishOneCommandBatchAndCleanup()` is updated to simply call the
locked version with the mutex lock held.
Change also improved `FixedQueue` assertions (always check that
`mSize <= mMaxSize`).
Bug: b/280304441
Change-Id: I67bd7c35b164b84e9c07306a5bf48b0adefdfa5e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6055419
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
224f836c
|
2024-12-04T09:35:09
|
|
Vulkan: Update setupDispatch comment
The comment was wrong and a source of confusion.
Bug: angleproject:382090958
Change-Id: I7b1a3d5f3b1c86539164d346e320d30b61254f2c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6069354
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Yuxin Hu <yuxinhu@google.com>
|
|
cb31b886
|
2024-11-22T13:15:57
|
|
Vulkan: pruneDefaultBufferPools when there is excessive garbage
What commonly happens with game (and traces) is that we upload a lot of
textures before first frame is drawn. These texture uploads uses a lot
of buffer memory and creates peak memory usage moment if not clean up
quickly. This CL adds back the check if there is excessive suballocation
memory gets destroyed, don't wait until frame boundary to prune empty
buffer blocks. Do the prune immediately so that these memory could be
reused for other purpose for the first frame rendering.
Bug: angleproject:372268711
Change-Id: Ie548245b5ce108be0e2c19b296a28025bface395
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6043405
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
70d1ef67
|
2024-11-20T11:34:39
|
|
Vulkan: Ensure onFramebufferBoundary is called for offscreen
There is peak memory regression observed from crrev.com/c/6022549. What
I suspect happening is that for offscreen or single buffered case,
glFlush/glFinish is called but bail out because it already submitted or
deferred. So we end up not calling onFramebufferBoundary(). This CL
ensures we always call onFramebufferBoundary from these two functions
for single buffer or offscreen.
Also fixed a bug when onSharedPresentContextFlush is called we may end
up calling onFramebufferBoundary.
To make API names consistent, existing flushImpl() is renamed to
flushAndSubmitCommands() and a new flushIMpl is added to wrap around
most logic inside flush().
Bug: angleproject:372268711
Change-Id: I54eed8a81f4153d52ab962f213cacc87a73b89ac
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6037491
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@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>
|
|
74f74b63
|
2024-11-14T10:07:34
|
|
Vulkan: Add ContextVk::onFramebufferBoundary() function
This makes a more formal API to track frame boundary. Also adds a
uint32_t mCurrentFrameCount to track the total number of frames rendered
so that we could use for heuristic purpose.
Bug: angleproject:372268711
Change-Id: I153497403ed0d8fde18f1786186ce600df60c514
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6022549
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
087cc411
|
2024-11-14T11:05:14
|
|
Vulkan: Add mRenderer to ShareGroupVk class
For convenience, instead of passing renderer to shareGroupVk's API, keep
mRenderer in SharGroupVk class at constructor call.
Bug: angleproject:372268711
Change-Id: I9534f7dbe24121856221b89ccf8fc6a353bbb0cc
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6022548
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
e3b3dd68
|
2024-11-14T23:00:52
|
|
Vulkan: Optimize color clears vs read-only depth/stencil switch
When switching to read-only depth/stencil mode, if the aspect that
intends to be in read-only mode has a deferred clear, the clear is
flushed separately beforehands (as that would be a write operation).
Prior to this change, _all_ deferred clears were flushed for simplicity.
In this change, only the aspect that is switching modes is cleared,
leaving the other aspects free to be optimized as loadOp of the
following render pass.
Bug: angleproject:378058737
Change-Id: Iba4371590bee99f5022575c09b0d32231562488c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6019829
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
adb80cbb
|
2024-11-12T22:38:38
|
|
Vulkan: Optimize read-only depth/stencil switch after clear
Prior to this change, if color is cleared then read-only depth/stencil
mode is enabled, ContextVk::switchToReadOnlyDepthStencilMode eagerly
flushed the deferred clears (starting a render pass).
However, if the render pass is marked dirty for any reason afterwards,
for example because we want to flush the render pass after a query
ends, the render pass that is just started above is unnecessarily
closed.
In this change, `switchToReadOnlyDepthStencilMode` only detects if a new
render pass is needed and marks the appropriate dirt bits. This way,
the render pass can only be restarted once.
Bug: angleproject:378058737
Change-Id: I83a5ebae6c223882eafea338eeec19895d87e5c1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6023414
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
ba81145f
|
2024-11-08T15:45:44
|
|
Vulkan: Emulate coherent framebuffer fetch everywhere
Many apps expect coherent framebuffer fetch to be available, and
multiple downstream emulators end up forcing coherent framebuffer fetch
enabled despite the hardware not being coherent.
This change attempts to do a best-effort emulation of coherent
framebuffer fetch by automatically inserting barriers before framebuffer
fetch draws. While this doesn't correctly handle self-overlapping
geometry, it works well enough in practice for the applications.
As a result, framebuffer fetch is practically enabled everywhere after
this change.
Bug: angleproject:377923479
Change-Id: I3900a1de0f4db755b7e70871f57df3ea112073f9
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6004336
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Cody Northrop <cnorthrop@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
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>
|
|
2df8d32b
|
2024-10-25T13:49:40
|
|
Vulkan: Tag DescriptorSets properly with every command buffer
When descriptorSetCache is disabled, there is a bug that the current
descriptorSet is not properly tagged with current ResourceUse. Right now
when we get a descriptorSet (from cache or reused or allocated new), we
retain to the current command buffer. But if we submit command buffer
and get a new command buffer, and draw with the same
program/buffer/textures, we will be reusing the current bound
descriptorSets, but it is not retained with new command buffer.
In theory, we have the same bug for pool eviction as well when cache is
enabled. It's just very hard to hit due to pool eviction occur very
rare. But with cache disabled, this is very easy to hit with multiple
tests.
In this CL, the retainResource call is moved from
ProgramExecutableVk::getOrAllocateDescriptorSet() call to
ProgramExecutableVk::bindDescriptorSets() call. Since bindDescriptorSets
is always get called when we get a new descriptorSet, and is always get
called when a new command buffer is allocated, this covers all usage
case.
And even better, with this change we are able to remove
commandBufferHelper from arguments of quite a few functions.
Bug: angleproject:372268711
Change-Id: I1f21a3e7e9ea34e2842e54025b5eb930dbf6c593
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4743599
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
1652f8ed
|
2024-10-17T13:35:39
|
|
Vulkan: end2end tests when descriptorSetCache is disabled
Some end2end tests are testing specific descriptorSet cache behavior.
When cache is disabled, these tests failed. In this CL these perfCounter
based tests haven been modified to check total allocation to ensure the
descriptorSets are properly reused instead of cache hit/miss.
Bug: angleproject:372268711
Change-Id: I1d2f4cfcf622b05cdcb3317c8804416a80e72c48
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3735732
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
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>
|
|
a769fad4
|
2024-10-24T20:46:42
|
|
Vulkan: Optimize and fix glFinish for single buffered surfaces
Fixed bug:
When calling `onSharedPresentContextFlush()` from `ContextVk::finish()`
need to also call `finishImpl()` to wait for submitted commands. This
bug was introduced in the original commit where
`onSharedPresentContextFlush()` was added.
Optimization:
Skip calling `onSharedPresentContextFlush()` from `ContextVk::finish()`
similarly to `ContextVk::flush()` when there is nothing to flush.
Bug: angleproject:42265370
Bug: b/229908040
Change-Id: Ide9f9c5d8757257c925970faece1e137acf10dec
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5961290
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
|
|
fe99836c
|
2024-10-25T14:34:23
|
|
Vulkan: Use ANGLE_PERF_WARNING when no serial for reserved serial
When we run out of OutsideRenderPassCommands' queue serial, we have to
call flushCommandsAndEndRenderPass() so that we can get a new set of
reserved serials for OutsideRenderPassCommands. The problem is that we
call ANGLE_VK_PERF_WARNING macro before calling
flushCommandsAndEndRenderPass(), which could insert a
CommandID::InsertDebugUtilsLabel command when debug marker is enabled.
This end up with mOutsideRenderPassCommands becomes not empty and
subsequent call of flushCommandsAndEndRenderPass end up with
flushOutsideRenderPassCommands and not able to early out due to command
buffer is not empty. This CL simply changes ANGLE_VK_PERF_WARNING to
ANGLE_PERF_WARNING to avoid getting into this situation. Assertion is
also added to catch the problem at at the spot it happens.
Bug: b/375661776
Change-Id: I2434af81b139c6b04d7ef1963f76035d60dfd471
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5967615
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Roman Lavrov <romanl@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|