src/libANGLE/renderer/vulkan/ContextVk.cpp


Log

Author Commit Date CI Message
Charlie Lao 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>
Mohan Maiya 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>
Shahbaz Youssefi 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>
Amirali Abdolrashidi 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>
Tingwei Guo 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>
Amirali Abdolrashidi 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>
Amirali Abdolrashidi 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>
Charlie Lao 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>
Amirali Abdolrashidi 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>
Charlie Lao 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>
Charlie Lao 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>
Charlie Lao 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>
Charlie Lao 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>
Charlie Lao 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>
Charlie Lao 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>
Charlie Lao 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>
Charlie Lao 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>
Charlie Lao 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>
Shahbaz Youssefi 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>
Shahbaz Youssefi 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>
Shahbaz Youssefi 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>
Shahbaz Youssefi 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>
Charlie Lao 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>
Tom Sepez 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>
Panfeng Hou 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>
Amirali Abdolrashidi 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>
Charlie Lao 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>
Panfeng Hou 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>
Amirali Abdolrashidi 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>
Charlie Lao 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>
Tingwei Guo 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>
Mohan Maiya 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>
Amirali Abdolrashidi 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>
Mohan Maiya 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>
Mohan Maiya 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>
Mohan Maiya 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>
Mohan Maiya 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>
Mohan Maiya 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>
Mohan Maiya 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>
Amirali Abdolrashidi 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>
Mohan Maiya 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>
Mohan Maiya 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>
Mohan Maiya 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>
Mohan Maiya 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>
Mavis Deng 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>
Alexey Knyazev 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>
Charlie Lao 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>
Shahbaz Youssefi 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>
Shahbaz Youssefi 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>
Mohan Maiya 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>
Amirali Abdolrashidi 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>
Igor Nazarov 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>
Charlie Lao 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>
Mohan Maiya 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>
Mavis Deng 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>
Shahbaz Youssefi 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>
Igor Nazarov 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>
Igor Nazarov 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>
Amirali Abdolrashidi 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>
Amirali Abdolrashidi 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>
Charlie Lao 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>
Shahbaz Youssefi 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>
Charlie Lao 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>
Charlie Lao 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>
Shahbaz Youssefi 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>
Shahbaz Youssefi 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>
Roman Lavrov 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>
Charlie Lao 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>
Charlie Lao 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>
Shahbaz Youssefi 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>
Charlie Lao 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>
Charlie Lao 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>
Igor Nazarov 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>
Charlie Lao 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>
Neil Zhang 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>
Shahbaz Youssefi 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>
Mohan Maiya 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>
Shahbaz Youssefi 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>
Shahbaz Youssefi 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>
Shahbaz Youssefi 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>
Shahbaz Youssefi 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>
Igor Nazarov 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>
Igor Nazarov 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>
Igor Nazarov 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>
Shahbaz Youssefi 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>
Charlie Lao 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>
Charlie Lao 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>
Charlie Lao 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>
Charlie Lao 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>
Charlie Lao 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>
Shahbaz Youssefi 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>
Shahbaz Youssefi 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>
Shahbaz Youssefi 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>
Mohan Maiya 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>
Charlie Lao 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>
Charlie Lao 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>
Shahbaz Youssefi 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>
Shahbaz Youssefi 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>
Igor Nazarov 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>
Charlie Lao 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>