src/libANGLE/renderer/vulkan/vk_helpers.cpp


Log

Author Commit Date CI Message
Shahbaz Youssefi f0370a41 2025-09-09T19:44:57 Vulkan: Use the GENERAL layout if VK_KHR_unified_image_layouts This lets ANGLE simplify synchronization by generally being able to use memory barriers instead of listing image barriers separately. Although the more specific access masks from VK_KHR_synchronization2 is possibly necessary for some hardware to work optimally (VK_ACCESS_2_SHADER_SAMPLED_READ_BIT in particular). It also lets ANGLE optimize a very specific scenario. Take an image used in the following scenario: 1. Copy to image in a transfer operation 2. Sample from image in the fragment shader of render pass 1 3. Sample from image in the vertex shader of shader pass 2 When GENERAL is not used, there's a layout transition between steps 1 and 2, changing the layout from TRANSFER_DST to SHADER_READ_ONLY_OPTIMAL (with dst stage == fragment shader). Later, at step 3, we need to make sure the vertex shader at least waits for this layout transition to finish... a dependency which is not expressible in Vulkan: * There cannot be a dependency to step 1, because the layout transition is not necessarily done * There is no stage mask that signifies the end of a layout transition. Without GENERAL, ANGLE has no choice but to issue a fragment->vertex dependency before step 3, serializing render pass 2's vertex pass with render pass 1's fragment pass on tilers. When using the GENERAL layout instead, step 3 can issue a transfer->vertex memory barrier, including using a VkEvent, parallelizing the two render passes. The above optimization is possible after this change, but not yet implemented. Bug: angleproject:422982681 Change-Id: Ieaae6f92b8b7d1e9c80c810a759c64b1e81d2dc1 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6936485 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com>
Shahbaz Youssefi 98915e44 2025-09-12T14:15:05 Vulkan: Fix blit src missing mip Bug: angleproject:433816259 Bug: angleproject:40644750 Change-Id: I50261279224dea8e37beff388207b927399d099a Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6944327 Reviewed-by: Cody Northrop <cnorthrop@google.com> Reviewed-by: Charlie Lao <cclao@google.com>
Shahbaz Youssefi b496b7a5 2025-09-14T22:56:16 Vulkan: Bug fix to tracking of last non-shader-read-only access Observed when an image is sampled in one shader stage and then another, the tracking of which non-shader stage the image was last accessed in was accidentally showing the first shader stage the image was sampled in. Bug: angleproject:388307202 Change-Id: Ic809994b67c00226cad44d9dbedec923639ca5b5 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6947445 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com>
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>
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>
Xiang Wang e77725a4 2025-09-02T12:14:55 Add VkFormat id to descriptor cache key's imageSubresourceRange This is to fix the bug when two shaders are modifying the same texture buffer but with different formats, the old buffer view with "incompatible" format can be reused. Bug: b/443105853 Change-Id: Ic3b2202a7d1d408fbbf826414bfcf2b1df4c3a15 Test: GLSLTest.TextureBufferWritesUsingDifferentFormats Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6916350 Reviewed-by: 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>
hoonee.cho e9a30817 2024-10-28T14:54:38 Vulkan: Support vulkan physical addr in vk_helpers - Add extraAllocationInfo for physical addressing in AllocateBufferMemory/AllocateImageMemory - Add getDeviceAddress which calls vkGetBufferDeviceAddressKHR API to get device address In CL, All the physical addressing supports are enabled when the runtime flag "supportsPhysicalAddressing" is set. Bug: angleproject:442950569 Change-Id: I1658062b3f031b3d55923937947cece0c1b67d67 Signed-off-by: hoonee.cho <hoonee.cho@samsung.com> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6916340 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Austin Annestrand <a.annestrand@samsung.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>
Shahbaz Youssefi 0042de5f 2025-09-08T12:04:33 Vulkan: Rename ImageAccess to ImageFormatSupport `ImageAccess` to be used for other purposes. Variable name `access` was also identical to variables of `CommandBufferAccess`. Bug: angleproject:422982681 Change-Id: I69b4d2bd773f1c5ff0fb15c7b611efd1f736061d Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6923330 Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi dbbae298 2025-09-05T12:39:01 Vulkan: Remove debug name from ImageMemoryBarrierData It was always there, but never became useful. Bug: angleproject:422982681 Change-Id: I409c061b07840a1cc9b85220fcbe792944358dba Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6919463 Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Shyam Manohar e842b5f8 2025-05-06T14:38:27 CL/Vulkan: Zero-copy support added for CL Buffers - Used VK_EXT_external_memory_host and VK_KHR_external_memory extensions - Added interfaces to CLBufferVk class for validating zero-copy ability - Added logic in CLBufferVk::create to use zero-copy if eligible - Added new HostExternalMemory class to provide utility functions - Added VkPhysicalDeviceExternalMemoryHostPropertiesEXT for querying Tests-Passing (having usage of CL_MEM_USE_HOST_PTR): - ocl_cts.test_api - ocl_cts.test_basic - ocl_cts.test_buffers - ocl_cts.test_mem_host_flags Bug: angleproject:441471275 Change-Id: I296e709a4f67911dcd6d0ae89750e8e0262625f4 Signed-off-by: Shyam Manohar <s.manohar@samsung.com> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6892624 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Austin Annestrand <a.annestrand@samsung.com>
Shahbaz Youssefi 1ed999ea 2025-08-25T16:02:01 Vulkan: Move sampler cache to share group The sampler cache (and the adjacent yuv-conversion-info cache) were in vk::Renderer, but they were not thread safe. Bug: angleproject:440364873 Change-Id: I2dc034f2db400f680ca91a9fde509d90f90c957e Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6870736 Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Yuxin Hu <yuxinhu@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>
Shahbaz Youssefi 677d8281 2025-08-25T15:59:46 Vulkan: Pass ContextVk to view-creation functions In preparation for moving the ycbcr conversion cache to the share group. This change is a no-op. Bug: angleproject:440364873 Change-Id: I0c18062259b07813dd04ec02650bb6fab48947ad Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6879204 Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Charlie Lao <cclao@google.com>
Raja  Wasim Husain 8ef76b6a 2025-08-04T12:34:17 CL/Vulkan: cl_khr_external_memory extension (pt.2) - Make this extension visible if Vulkan implementation support features supportsExternalMemoryFd and/or supportsExternalMemoryDmaBuf - Implemented APIs clEnqueueAcquireExternalMemObjectsKHR and clEnqueueReleaseExternalMemObjectsKHR - Updated clCreateBufferWithProperties to handle external memory file descriptor. Bug: angleproject:378017028 Change-Id: I1751982c8e9b2cd07b7e251cc54db5dcd1bcda20 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6843980 Commit-Queue: Austin Annestrand <a.annestrand@samsung.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Mohan Maiya 130fb2a1 2025-07-29T08:16:57 Vulkan: Don't allocate ExternalFormatIDs for sampling usecases Update the condition for allocating YUV ExternalFormatIDs to exclude sampling-only usecases. Also, rename "isYuvResolve()" to "isYuvExternalFormat()" to better reflect intent. Bug: angleproject:386749841 Change-Id: I0e4f5b79937ea8ad98b5d00fdc7531b34ffa7e16 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6797965 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: mohan maiya <m.maiya@samsung.com>
Mohan Maiya 214a48c4 2025-07-16T12:42:18 Vulkan: add support for yuv resolve with transient image Add support for the YUV_target extension in cases where the implementation supports VK_ANDROID_external_format_resolve without supporting nullColorAttachmentWithExternalFormatResolve. Bug: angleproject:386749841 Tests: ImageTest*YUV* Change-Id: Iebcb4f843b962f3d0d2f4e42db479902b6c1f849 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6761834 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: mohan maiya <m.maiya@samsung.com> Reviewed-by: Charlie Lao <cclao@google.com>
Kimmo Kinnunen 93b659f9 2025-07-04T12:35:29 Remove PoolAllocator push/pop feature PoolAllocator would manage a stack of memory pools upon client calling push() and pop(). This made the code unnecessarily complicated. The feature was only used with nesting of one, to mark the memory unused after a shader compile. Fix by removing the push/pop feature. Instantiate PoolAllocator in places the previous push() was and uninstantiating instead of previous pop(). This removes the feature where the PoolAllocator would hold on to the allocated memory in order to reuse it. This is seen as a progression: the allocator is held by the compiler, the compiler is held by the shader and each shader typically see only one compile. Thus the free pages were just leaking unused until the shader was destroyed. Instead, destructing the PoolAllocator instead of pop() will donate the memory back to platform/OS, where it is likely more useful. To preserve existing Vulkan behavior, add PoolAllocator::reset() which would mark the memory unused but leave them reserved for the PoolAllocator. Removes UB where PageHeader::nextPage would be accessed after ~PageHeader. Bug: angleproject:429513168 Change-Id: I21e58b46e0887380db3a2cab5ce22f0042cfae9e Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6701153 Reviewed-by: Geoff Lang <geofflang@chromium.org> Auto-Submit: Kimmo Kinnunen <kkinnunen@apple.com> Commit-Queue: Kimmo Kinnunen <kkinnunen@apple.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Amirali Abdolrashidi 9e000857 2025-02-04T16:12:47 Vulkan: Utilize VkBufferUsageFlags2 for bufferview * Added the following struct to bufferview createInfo in case of VK_KHR_maintenance5 support: VkBufferUsageFlags2CreateInfoKHR * Limited VVL 08779 to platforms without KHR_maintenance5 support. Bug: angleproject:394353300 Change-Id: I46beac693cda3216afc497c8ed74cbf51b72e549 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6231512 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Tingwei Guo ef29d42e 2025-05-22T15:52:49 Support ASTC decode mode extensions in ANGLE Added support for GL_EXT_texture_compression_astc_decode_mode and GL_EXT_texture_compression_astc_decode_mode_rgb9e5 in ANGLE. Also added corresponding end-to-end tests for ASTC decode mode queries, including ASTC decode mode queries and rendering with ASTC texture formats with different decode modes on GL_TEXTURE_2D works. Bug: angleproject:419403188 Change-Id: I0f2dced8468c4e25597740d1de346b2f699bb81e Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6575285 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: 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>
Cody Northrop 16b2bf5e 2025-05-06T16:23:24 Vulkan: Only expose ASTC HDR if 3D textures supported Not all hardware supports ASTC HDR for 3D textures. This CL adds a check for each ASTC HDR format, querying the driver for 3D support, and tracking it as a feature. We use that feature when deciding to expose GL_KHR_texture_compression_astc_hdr. Test: dEQP-GLES31.functional.copy_image.compressed.viewclass_astc_8x8_rgba Bug: b/407634958, b/416095435 Change-Id: Iaa6f26e247c7e6c7451f3d4eb8dd7175509bf45f Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6515816 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Cody Northrop <cnorthrop@google.com>
Shahbaz Youssefi 6f9f343a 2025-04-16T14:45:33 Reland "Vulkan: Prune superseded updates during host-image-copy" This is a reland of commit f8a8adf63c5834a725d1bd752acc6d63c3f45c05 Original change's description: > Vulkan: Prune superseded updates during host-image-copy > > Bug: angleproject:42266771 > Change-Id: I7aa8e85720a54537389df615b575ddfa9951770d > Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6462475 > Reviewed-by: Yuxin Hu <yuxinhu@google.com> > Reviewed-by: Cody Northrop <cnorthrop@google.com> > Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org> > Commit-Queue: Cody Northrop <cnorthrop@google.com> Bug: angleproject:42266771 Change-Id: I95e6f1d2421327a6394e627f03ef5b4cddf4a1e1 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6480011 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Cody Northrop <cnorthrop@google.com> Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Tingwei Guo 3f88a505 2025-04-03T17:29:20 GenerateMipmap encode and decode sRGB when GL_SKIP_DECODE_EXT is set According to the spec, if TEXTURE_SRGB_DECODE_EXT is set before GenerateMipmap for a texture with format sRGB, mipmap generation should skips the encode and decode steps during mipmap generation, matching the mipmap generation for a non-sRGB texture. Bug: angleproject:406829410 Change-Id: Icea8c27a1ab2f20e9fd6c8d79187c0c5cfe8e789 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6428506 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Auto-Submit: Tingwei Guo <tingwei.guo@arm.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: mohan maiya <m.maiya@samsung.com>
Shahbaz Youssefi 50a4ad19 2025-04-22T09:29:17 Revert "Vulkan: Prune superseded updates during host-image-copy" This reverts commit f8a8adf63c5834a725d1bd752acc6d63c3f45c05. Reason for revert: Has a bug in the calculation of image layers whose updates should be dropped. Bug: angleproject:42266771 Original change's description: > Vulkan: Prune superseded updates during host-image-copy > > Bug: angleproject:42266771 > Change-Id: I7aa8e85720a54537389df615b575ddfa9951770d > Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6462475 > Reviewed-by: Yuxin Hu <yuxinhu@google.com> > Reviewed-by: Cody Northrop <cnorthrop@google.com> > Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org> > Commit-Queue: Cody Northrop <cnorthrop@google.com> Bug: angleproject:42266771 Change-Id: I2b992c8598f58c40386338ade3cf59ffdb03abd5 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6480413 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Shahbaz Youssefi f8a8adf6 2025-04-16T14:45:33 Vulkan: Prune superseded updates during host-image-copy Bug: angleproject:42266771 Change-Id: I7aa8e85720a54537389df615b575ddfa9951770d Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6462475 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Cody Northrop <cnorthrop@google.com> Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Cody Northrop <cnorthrop@google.com>
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>
Yuxin Hu a0a5c565 2025-04-07T15:05:11 Vulkan: Add assert to check only clear is staged on swapchain image The swap after clear optimizations on swapchain image multisampled image https://chromium-review.googlesource.com/c/angle/angle/+/6072416 works with the assumption that the only staged updates on swapchain multisampled image is clear. This change adds an assert to validate the assumption holds true before applying the optimization. If the assert is ever triggered, we will know the assumption is violated, and we need to look into how to tweak the optimization or add other optimizations to solve the violated case. Bug: angleproject:382006939 Change-Id: I7ce23dd7767b7730f1fa3ec89cb6616689339602 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6437217 Reviewed-by: mohan maiya <m.maiya@samsung.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Yuxin Hu <yuxinhu@google.com>
Roman Lavrov 23c1e11e 2025-04-01T11:27:02 Disable platform trace events by default, except Chromium build Observed overhead in perf builds is too significant, some workloads generate thousands of events per second. There does not seem to be a simple way to get around the overhead - it could be somewhat reduced but the event rate is just too high. ANGLE_TRACE_EVENT*(...) etc become a no-op by default. Can be re-enabled with angle_enable_platform_trace_events=true gn arg Bug: angleproject:404542398 Change-Id: I8d7363ee28d22226f1860e24f2399bb4129cfb84 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6419308 Commit-Queue: Roman Lavrov <romanl@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Feels: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com>
Aurora Zhang 34db1c20 2025-03-20T12:56:42 Vulkan: glReadPixels should nearest sample the YUV render target Vulkan backend uses texture except texelFetch to obtain the YUV image value for glReadPixels. According to the chroma filter set in the image, it may apply LINEAR sampling. * Change this filter to NEAREST inside glReadPixels to get the correct pixel values. * Modify the fragment shader used in glReadPixels to make sure sampling from the center of the pixel. * Add a new end2end test. Bug: angleproject:404394628 Change-Id: I0e574a464639e11671f0a09eee3e9f38b5abd919 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6366299 Auto-Submit: Aurora Zhang <Aurora.Zhang@arm.com> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Igor Nazarov ac251fa8 2025-02-24T17:31:58 Vulkan: Remove doDeferredAcquireNextImage ContextVk dependency This is the continuation of the previous CL. After this change `lockSurface()` calls `doDeferredAcquireNextImage()` as the rest of the code do. The `ImageHelper::invalidateSubresourceContentImpl()` required `ContextVk` pointer before this change. The `ContextVk` is only used to print the performance warning when `layerIndex` exceed the maximum count, which is not possible in case of a `WindowSurfaceVk`. Added `layerLimitReachedOut` pointer instead of writing the warning. It is processed in `invalidateSubresource[Stencil]Content()`. Added `invalidateEntireLevel[Stencil]Content()` which do not require `ContextVk` to use in the `WindowSurfaceVk`. Bug: angleproject:397848903 Bug: angleproject:42264593 Change-Id: I58451a4818ad56fa196c3c971df3a5f7793f2bfe Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6298735 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Igor Nazarov <i.nazarov@samsung.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 ad6c3d74 2025-02-19T22:45:29 Vulkan: Fix RP resolve layouts w.r.t shared present mode This is partially a regression after the previous change: Vulkan: Fix present optimization w.r.t shared present mode Before the above change, swapchain image was still optimized for present even when using shared present mode. However, because SetBitField(mAttachmentOps[packedAttachmentIndex].finalResolveLayout line was using `getCurrentImageLayout()` (lucky coincidence) it was setting correct SharedPresent layout into `finalResolveLayout`. The `initialLayout` and reference `layout` was still `VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL`, but for some reason VVL was not producing any errors. This change adds setting `finalResolveLayout` for the resolve attachment, which in turn propagates `VK_IMAGE_LAYOUT_SHARED_PRESENT_KHR` to all renderpass layouts as well as to the dynamic rendering info. Test: angle_end2end_tests --gtest_filter=EGLSingleBufferTest.SharedPresentLayoutWithMSAA/* Bug: angleproject:42262606 Change-Id: I49a121f1d43a078890b0dc32e0574a79e3565270 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6281569 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Charlie Lao 65343c4c 2025-02-27T11:23:04 Vulkan: Improve ConvertImageLayoutToVkImageLayout() This CL removes supportsMixedReadWriteDepthStencilLayouts feature flag. This feature flag was introduced when ANGLE only requires vulkan 1.0. But now we require vulkan 1.1 and this is part of vulkan 1.1 core spec. So it is no longer needed and wasting CPU cycles to check this every time ConvertImageLayoutToVkImageLayout() is called. With supportsMixedReadWriteDepthStencilLayouts removed, convert from ImageLayout to VkImageLayout no longer needs renderer parameter. The layout information in kImageMemoryBarrierData is never modified by renderer at run time. So the renerer arguments has been removed in a lot of places, avoids another pointer de-reference. Bug: b/384839847 Change-Id: I5a89a890c0c0a1f99d2fdc1b2a85baf7de5c28bf Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6310839 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
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>
Charlie Lao 9202e05a 2025-02-21T18:42:42 Vulkan: Invalidate the SharedCacheKey when cache gets evicted When descriptorSet cache gets evicted, right now we have a bug that the sharedCacheKey does not gets invalidated. This caused SharedCacheKeyManager always think the sharedCacheKey is valid and the mEmptySlotBits never gets cleared, which leads to mEmptySlotBits growth over time, and increases CPU overhead when walking mEmptySlotBits vector. This CL adds an assertion to ensure that all valid sharedCacheKeys has a corresponding entry in the cache, which means without this CL, some traces and dEQP tests are hitting the assertion. This CL also fixes the bug. Bug: b/384839847 Change-Id: If013443144aceb5d62f67f619074ef831e73653b Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6292988 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Igor Nazarov 03bdf1ca 2025-02-18T16:37:49 Vulkan: Use correct actual FormatID for MSAA swapchain image Implementation of "overrideSurfaceFormatRGB8ToRGBA8" feature missed updating actual FormatID for the MSAA swapchain image. This bug makes possible to initialize RGBA8 swapchain image and RGB8 MSAA image. However, on practice MSAA is still RGBA8 because RGB8 renderable is generally emulated on Android. VUID-vkCmdResolveImage-srcImage-01386: srcImage and dstImage must have been created with the same image format. This fix is cosmetic and is not expected to fix any real bugs (because RGB8 is generally emulated with RGBA8). Bug: angleproject:42265147 Change-Id: Ief4b74ac31e93a655f5088b7927e970585255f25 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6275968 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Charlie Lao 8f8b41e3 2025-02-14T17:54:51 Vulkan: Optimize for multiple TexSubImage calls in the same level Based on app traces, some apps make glTexSubImage call for the same level multiple times in a row. One extreme example is lumino_city, which it creates a 2D texture with nullptr data, and then calls glTexSubImage2D many times back to back for each row of the texture to update the data. Because we uses std::vector to store the per level update struct (SubresourceUpdate), it means we copy these data structures every time it grows 2x, until it hit the max size 1081. The other common case we get into is app update some area of the texture (like google map and gacha_life) which also end up with a few texSubImage calls back to back. The other more common case is we staged a clear first and then glTexSubImage which end up with vector size of 2. This CL changes to use std::deque instead of std::vector to store the staged update for a given level, which allows it to grow without extra penalty. Bug: b/293297177 Change-Id: Iabbc143074ad9d6fcf47abbddee09ecf7f78d1a7 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6271964 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Charlie Lao <cclao@google.com>
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 3d29a799 2025-02-11T10:05:35 Vulkan: Reserve enough storage for ImageHelper::mSubresourceUpdates Most app specify textures from level 0 to level N, which works against std::vector storage grow scheme (which grows in size of 1,2,4,8,16). This CL simply reserve space for 12 mipmap levels to accommodate for most used texture sizes. Bug: b/293297177 Change-Id: I44818ed7ee436c73ab7ff146972f122ae9f08f33 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6253673 Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Amirali Abdolrashidi 9e86d8c0 2025-02-05T16:31:22 Vulkan: Fix VVL due to memory map range VVL: VUID-VkMappedMemoryRange-size-01390 * Updated BufferBlock::map() so the device memory uses the actually allocated buffer size. * To flush and invalidate a mapped memory range (non-coherent), the memory size is now aligned with nonCoherentAtomSize from the physical device limits. * Added an assert to make sure that the mapped size is within the allocated buffer size range. * Unskipped ExternalBufferTestES31 cases for Pixel6, except one case which seems to take a long time and result in timeout. * BufferDoesNotLeakAHB Bug: angleproject:394685081 Change-Id: Iddfb45997fed53c5ee99938d9bb57b670550b9a6 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6238059 Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi d252425d 2025-02-06T14:51:36 Vulkan: Check source image usage flags in copy paths ... instead of the format feature flags. If the source of the copy is has external format (allowed with glCopy[Sub]TextureCHROMIUM), the format feature checks are unable to query the format features. However, the image usage flags already have the required information (whether the image can be copied from, sampled from, etc). Bug: chromium:383056998 Change-Id: I2ba8820751eb526ef497a8be724193276fd46160 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6238265 Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com> Reviewed-by: Charlie Lao <cclao@google.com> Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Shahbaz Youssefi 0026006d 2025-02-10T12:03:40 Vulkan: Fix missing barrier between dispatch calls When storage images are used, ANGLE accidentally did not mark the images as being written to, so subsequent barriers were not produced when necessary. Bug: angleproject:352610491 Bug: b/394611669 Change-Id: Idd3e6aa6b90212605594240a533ebaec66850ea9 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6249459 Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Charlie Lao <cclao@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>
Charlie Lao 3dcd143c 2025-02-06T15:06:02 Vulkan: Reduce GL_EXT_texture_storage_compression related overhead Most of apps not using fixed rate compression extension, but we are getting into all these logic that checking for vulkan driver's support of compression rate. This CL adds a check in TextureVk::initImage(), so that it only goes down that logic if mState.getSurfaceCompressionFixedRate() is not GL_SURFACE_COMPRESSION_FIXED_RATE_NONE_EXT. This means for all existing app traces we have, we should not go down these logic any more. This CL also made TextureVk::getFormatSupportedCompressionRatesImpl() and ImageHelper::getCompressionFixedRate() out of TextureVk and ImageHelper class given they are not accessing the data member at all. Bug: b/293297177 Bug: angleproject:352364583 Change-Id: Ib5eebf54172f194d7c65c2d2d751326b7923403f Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6239523 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 9c82e55a 2025-01-16T17:47:41 Vulkan: Make VkEvent for Buffer work with more general usage Before this CL, BufferHelper::mCurrentWriteAccess and mCurrentReadAccess, mCurrentWriteStages, mCurrentReadStages still track all accesses, regardless if it is tracked by RfCountedEvent or via PipelineBarrier. This is okay for very limited usage case, but becomes fragile when expand the event for general usage case. The problem is that you can not correctly tell which bits in mCurrentReadAccess is for pipelineBarrier and which is for Event, since event and pipeline barrier could have the same VkAccessFlags. Similarly problem exist for mCurrentWriteAccess. The reliable way is actually track pipeline barrier access and VkEvent access completely separately. This CL changes mCurrentWriteAccess, mCurrentWriteStages, mCurrentReadAccess and mCurrentReadStage to only contain bits that not tracked by VkEvent. For this reason, RefCountedEventWithAccessFlags wrapper class is added to wrap mCurrentWriteEvent and its associated VkAccessFlags. Bug: angleproject:360274928 Change-Id: I057484f0c3baa2739d56c3a75889eb88a647a65a Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6210683 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 29e20d52 2025-01-29T15:58:04 Vulkan: Use single VkEvent to track depth/stencil and color attachment Right now ANGLE uses two VkCmdSetEvent calls to synchronize color and depth attachments in a render pass, one for color attachment and another for depth/stencil attachment. This is inefficient. ARM engineers confirmed combining both into one event with a combined stage mask (VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT | kAllDepthStencilPipelineStageFlags) should not negatively impact performance. This CL merges depth/stencil related events into color attachment. The benefit of this is that for most render passes, you will see one less VkEvent which translates to reduced overhead. Bug: b/393150736 Change-Id: I0808b4dfd0b91efaaa2af649fef8bb02abbb3039 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6187980 Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Amirali Abdolrashidi 1df10f8a 2025-01-29T14:50:21 Unsuppress VUID-VkImageViewCreateInfo-pNext-01585 * Updated ImageHelper::DeriveCreateInfoPNext() to check the usage flags as well. * If the image uses the storage bit, the format list should not be added to it as pNext. Otherwise, if the count is not zero, it expects the format used in its image view to be one of the stated formats and will result in a VVL if this is not the case. Bug: angleproject:42264452 Change-Id: I789ec5a9751366029929c4c25a942056df13b9ff Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6216381 Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 9d934912 2025-01-09T11:31:42 Vulkan: Use VkEvent to track transform feedback buffer write This CL adds event tracking into BufferHelper class: mCurrentWriteEvent is used to track the write event and mCurrentReadEvents is used to track all different reads from the buffer. Since you can have multiple different reads accumulate over time, read events are an array of EventStage and the actual VkAccessFlags per event is tracked in mCurrentReadEventsAccessFlags. Note that this is specifically designed to allow pipelineBarrier and eventBarrier to co-exist. If mCurrentReadStages contains more bits than mCurrentReadEvents, the remaining bits will be using pipelineBarrier. Similarly if mCurrentWriteStages contains more bits than mCurrentWriteEvent, the remaining bits will be using pipelineBarrier. A heuristic tracking is also added to track the buffer writes over a period of time. Right now we will opt buffer into VkEvent if the buffer ever written by transform feedback in the heuristic tracking window. This could be expanded in future if we found more usage pattern that would be benefit from using VkEvent. Also note that DrawIndirect and VertexInput will be using the same VkEvent to track. It still will be using different VkAccessFlags since the access flags comes from buffer instead of event. Bug: angleproject:360274928 Change-Id: I027ffed8a0fbff7f280f42cf70564b8a3f243d69 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6085490 Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> 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>
Charlie Lao f231d94b 2025-01-13T14:58:16 Vulkan: Add kBufferMemoryBarrierData to mirror image Right now we only maintain a mapping from EventStage (which is a value of VkPipelineStageFlags) to VkPipelineStageFlags for images. For next CL we need to indicate if use VkEvent is preferred or not for a given PipelineStage access. This CL expands kPipelineStageFlagBitMap (and renamed to kBufferMemoryBarrierData) to contain both the VkPipelineStages and EventStage to indicate if VkEvent should be used or not, similar to kImageMemoryBarrierData but a lot simpler. Right now it all set to EventStage::InvalidEnum which means will use pipelineBarrier. This will change in next CL. This CL also does some clean up: A few BufferHelper related functions changed argument from ErrorContext* to Context*, mainly because of BufferHelper::release() now takes Context* as argument so that we can recycle events within context's share group without lock. ImageLayoutToMemoryBarrierDataMap is added to replace angle::PackedEnumMap<ImageLayout, ImageMemoryBarrierData> kEventStageAndPipelineStageFlagsMap is removed. InitializeEventAndPipelineStagesMap is now using kImageMemoryBarrierData directly to construct mEventStageToPipelineStageFlagsMap. As result of this, EventAndPipelineBarrierHaveMatchingStageFlags is also removed since InitializeEventStageToVkPipelineStageFlagsMap already ensures this. Bug: angleproject:360274928 Change-Id: Idb74f3e4120ca9a04b8eccb7ed034aa769024bf9 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6172763 Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Austin Annestrand 95635ef0 2025-01-23T16:30:41 CL/VK: Implementation of Compute Pipeline Cache. Implemented ComputePipelineCache, hash map from OpenCL and OpenGL compute state vectors to compiled pipelines. Implemented ComputePipelineDesc, a tightly packed description of the current compute state. Compute Pipeline State includes the specialization constants, Pipeline Options (Protected, Robust). Updated-by: Austin Annestrand <a.annestrand@samsung.com> Bug: angleproject:391672281 Change-Id: I88944dc169d194d1b2c75747769d7346b041fa75 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6191437 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Austin Annestrand <a.annestrand@samsung.com>
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>
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 c7ad15e3 2025-01-23T13:37:28 Vulkan: de-duplicate ImageHelper::barrierImpl and barrierImplOneOff barrierImpl is renamed to recordBarrierImpl barrierImplOneOff renamed to recordBarrierOneOffImpl barrierImpl contains all the common logic between recordBarrierImpl and recordBarrierOneOffImpl. Bug: angleproject:390443243 Change-Id: I01ce9ea3f1f0acb30fe0efcdd20bd1caaa248a7c Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6195570 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Commit-Queue: Charlie Lao <cclao@google.com>
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>
Igor Nazarov 92cc4e02 2025-01-22T16:07:00 Vulkan: Fix incorrect initial RP layout for shared present Renderpass was using `ImageLayout::ColorWrite` as initial layout for the SharedPresent image. Vulkan validation did not detect errors because of limitations (or bug?): once command buffer with barrier is submitted, layers no longer track the current layout, and therefore skip the check. In other words, it seems like VVL only track layout transitions within a command buffer. Transition to `ImageLayout::SharedPresent` currently performed using one-off command buffer, which is always immediately submitted. This is the reason why VVL was ignoring the error for so long. Bug was discovered in `EGLSingleBufferTest.AcquireImageFromSwapImpl` during local testing, where one-off command buffer was replaced with outside RP commands. Other tests were still working fine, because they are using `glClear()` in the very first flush - no renderpass in the first submission, and so VVL can't track the layout once it is used in a renderpass in the second submission. Bug: angleproject:42262606 Change-Id: I19404b5be706e54e53890c2fec9cb4796296c698 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6182598 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
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>
Mohan Maiya aa6a9fae 2025-01-16T17:18:59 Vulkan: Selectively enable input attachment usage bit Add VK_IMAGE_USAGE_INPUT_ATTACHMENT_BIT iff supportsShaderFramebufferFetchDepthStencil feature is enabled. Also, add noncoherent qualifier in a few FramebufferFetchTest Bug: angleproject:352364582 Change-Id: I09c54a8d738b5cb4cbcf2716cdbff0c0ec9e31cf Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6181497 Commit-Queue: mohan maiya <m.maiya@samsung.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Zhonghang Chi ac7a85f4 2025-01-10T17:24:48 Vulkan: Replace copy image view with same read view in setStorage 1.Introduce a share flag in ImageViewHelper. 2.Update the share flag when copy view is same as read image view. 3.Only return read view when copy view is same read one. Bug: angleproject:387392704 Change-Id: I6a3a9ca043ba16cdeb430cce53d40197618a0d44 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6147667 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
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>
Charlie Lao d8f6df3e 2024-12-09T09:20:40 Vulkan: Fix assertion in RefCountedEvent::releaseImpl RefCountedEvent uses non-atomic uint32_t for reference counting, so it is not thread safe. To ensure we do not use it in a thread unsafe way, there is an assertion I added in RefCountedEvent::releaseImpl that the release call is not come from async command queue thread (all release calls are expected come from context thread which should be protected by context share group lock). A while ago dynamic rendering is implemented. With dynamic rendering you can't do final layout change in render pass. So the final layout change to Present is added to primary command buffer at the end of RenderPassCommandBufferHelper::flushToPrimary(). And if async command queue is enabled, that flushToPrimary is called from async command queue thread, which triggers the assertion I added in RefCountedEvent::releaseImpl(). This CL releases mCurrentRefCountedEvent for this specific situation (present image + dynamic rendering + asyncCommandQueue) so that we do not hit the assertion. The only downside is that it will force to use pipelineBarrier for this specific situation. But no one ships with asyncCommandQueue enabled, so there is no real concern here as well. Bug: angleproject:382580875 Change-Id: I042e3906db7f5bb7acb299997f8fc7e21b8350b6 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6072350 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
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>
Charlie Lao 7adbb3e8 2024-11-26T17:06:07 Vulkan: Remove explicit destroy calls Since now SharedPtr will automatically call destroy(device) when last reference goes away, there is no need for explicitly calling destroy(device) any more. Bug: angleproject:372268711 Change-Id: I208b17cf7e090babd51d6f337c20fdfd74c75b6b Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6052886 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Charlie Lao d81834b6 2024-11-26T15:25:35 Vulkan: Store VkDevice in vk::SharedPtr So that we don't need to have two versions of destroy() APIs. In previous CLs I had to add another version of destroy() that does not take device argument due to SharedPtr may calls destroy when last reference count goes away. Because we do not have device information at that time, destroy() API was added but mostly just doing assertion that Vulkan object has been explicitly destroyed. With this CL, we now stores device in the SharedPtr so that we no longer need two destroy() APIs. The explicit destroy(device) call will be removed in the next CL. Bug: angleproject:372268711 Change-Id: Idcacbc3a922e17ac3d0f6056466b8f3aa084b02e Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6052096 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Robic Sun f51170b3 2024-11-21T16:30:40 Enable GL_KHR_texture_compression_astc_hdr Vulkan supports GL_KHR_texture_compression_astc_hdr, so this extension can be enabled in Angle. Bug: angleproject:379186304 Change-Id: I438a120c3f884a7eefcd883ad71abf68f81cb473 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6038457 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Neil Zhang 01dee1cb 2024-10-14T15:04:28 Add implementation for GL_EXT_texture_storage_compression Bug: angleproject:352364583 Change-Id: I3dab4c68d5d0206d681e165e991217bd3de8eeb6 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6011055 Auto-Submit: Neil Zhang <Neil.Zhang@arm.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 6c1021ec 2024-11-22T16:48:45 Vulkan: Switch DescriptorSetLayout to use AtomicSharedPtr SharedPtr has better semantics and safer to use. This CL removes direct exposure of RefCounted object and also allows me to delete BindingPointer class in later CL. Bug: angleproject:372268711 Change-Id: I08a0dff3efcf794be843a4a548b9f2609bb9a5e1 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6044328 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 87d61997 2024-11-21T14:20:55 Vulkan: Switch ShaderModule to use SharedPtr This CL gets rid of many vk::RefCounted<vk::ShaderModule> usage which is risky due to it allows you to direct manipulate reference count. Switch to vk::SharedPtr manages the reference counting automatically. Bug: angleproject:372268711 Change-Id: I14f5c509bcbd9ea7d17101637e033652a68710a0 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6039117 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Yuxin Hu 2e25ea1e 2024-11-13T13:59:51 Add a new mutex in CommandQueue to protect Vulkan Command Pool Before this change, the CommandQueue::mMutex protects both: 1. Members of CommandQueue class, e.g. mInFlightCommands. 2. Operations on the same command pool and command buffers allocated from the same command pool. If one thread accesses resources 1, the other thread is doing operations in 2, they could be blocked by each other. For example, if thread 1 calls eglClientWaitSync() to check if certain commands finish execution (accessed resources in 1.), while thread 2 calls eglMakeCurrent() to flush commands (issue operations in 2.), thread 1 could be blocked by thread 2. This is against the egl spec where eglClientWaitSync() should return immediately when timeout passed to the call is 0. To fix the problem, this change creates a new class CommandPoolAccess that wraps operations in 2, and protects command pool and command buffer operations with a new mutex mCmdPoolMutex. With this new mutex, thread 1 and thread 2 would take different locks and not blocked by each other. Bug: b/362604439 Change-Id: Iccf0ae65809ccb0f593c5e318fde03e89e0c0fa3 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6020895 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Yuxin Hu <yuxinhu@google.com>
Charlie Lao 21d747de 2024-11-20T11:54:15 Vulkan: Use vk::SharedPtr for SharedDescriptorSetCacheKey This CL switches SharedDescriptorSetCacheKey from using c++ std::shared_ptr to our internal version of vk::SharedPtr. Also get rid of an extra pointer indirection that SharedDescriptorSetCacheKey is a reference counted of actual cache key instead of std::unique_ptr of cache key. Bug: angleproject:372268711 Change-Id: Id9af5070d24f67711d6decc3a30a260b8d4062d9 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6036302 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Yuxin Hu <yuxinhu@google.com>
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>
Gowtham Tammana 987cc0de 2024-08-06T12:16:37 Vulkan: Add release utility for BufferViewHelper Add a release helper that doesn't require ContextVk for BufferViewHelper. Bug: angleproject:378103913 Change-Id: Ib468d152501ecaec1dd71c9c6ed5527b73a1afa5 Signed-off-by: Gowtham Tammana <g.tammana@samsung.com> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6004686 Reviewed-by: Geoff Lang <geofflang@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi f44427b5 2024-11-05T15:18:59 Vulkan: Fix MSAA glReadPixels into PBOs The temporary image used to resolve the MSAA framebuffer during glReadPixels did not have the SAMPLED usage bit. Additionally, the image was supposed to be garbage collected afterwards but ImageHelper's release() function was accidentally immediately destroy()ing it. This was not an issue with blocking glReadPixels paths, because the command buffer was immediately flushed and the GPU work was waited on before the image was destroyed in RendererScoped's destructor. Bug: b/377437834 Change-Id: I1dca47172d6f363277059a848fe9446ac2a872d4 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5995530 Commit-Queue: Charlie Lao <cclao@google.com> Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Charlie Lao <cclao@google.com>
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>
Gowtham Tammana 79b6c7ab 2023-10-09T13:29:07 CL/Vulkan: Add fillWithPattern interface In CL, the buffer can be requested to filled with a pattern. Adding a pattern fill helper routine that fills up the buffer from CPU side. Bug: angleproject:42267074 Change-Id: I144e9b7c6f4d1263f21cabc2491c46e8951e604f Signed-off-by: Gowtham Tammana <g.tammana@samsung.com> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5916157 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Geoff Lang <geofflang@chromium.org>
Amirali Abdolrashidi 6b9d3762 2024-08-22T15:29:00 Vulkan: Optimize full texture clears Currently, a full texture clear (glClearTexImageEXT()) is treated as a special case of a partial clear (glClearTexSubImageEXT() with image dims as the input). However, it can be further optimized by treating it as a clear update. * For full clears from EXT_clear_texture, the clear update path is taken. * It leads to a more optimized path, including the usage of the following APIs: * vkCmdClearColorImage() * vkCmdClearDepthStencilImage() * It uses the following enum: ClearTextureMode * If a partial clear uses the extents for the entire image, it is treated as a full clear. * Updated the method to determine if a texture is renderable in clearSubImageImpl(). * Added perf counter: fullImageClears * Added new unit tests * Single 3D texture full clear (Clear3DSingleFull) * 2D RGB SNORM clear (Clear2DRGB8Snorm) * Added Vulkan perf counter test for 2D and 3D color image clear. * Updated the related skipped tests on Pineapple. Bug: angleproject:42266869 Bug: angleproject:375425839 Change-Id: I12ef3002dee190d7f8f43204f7d3f76e05d0b54f Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5806207 Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao d0a0fd1a 2024-10-17T14:50:51 Vulkan: Skip pool eviction when cache is disabled When cache is disabled, every time a new descriptorSet is allocated and bind to program, the previous descriptorSet will be added to the tail of garbage list, and the new descriptorSet is retrieved from the head of the garbage list, if its GPU usage has been completed. This means there will never have a situation that significant amount of descriptorSets are needed, therefore no need for pool eviction. One possible situation is that at one point you need a lot of descriptorSets and then after a while you only need small amount of descriptorSets. In that case we could delete the excessive unused descriptorSets. But since they are all allocated from a pool, as long as there is still one descriptorSet in the pool is used, you still can't destroy the pool. This means eviction is really not much useful when cache is disabled. Bug: angleproject:372268711 Change-Id: Id77b181b64e122f576ee43d11c39dc75bd681dcf Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5941126 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao af73a7eb 2024-10-18T17:19:29 Vulkan: Add WeakPtr to mirror std::weak_ptr This is a follow up from previous CL crrev.com/c/5938947. Because of pool eviction is based on reference count, there is need to have a weak pointer to the reference counted pool that does not add an extra reference count. This CL adds WeakPtr that works similarly to std::weak_ptr, and replaced direct RefCountedDescriptorPool pointer with WeakPtr wrapper. This is safer than RefCountedDescriptorPool in a way that it does not allow modification of underline reference count. Also the use of WeakPtr has been reduced to minimum in this CL. Bug: angleproject:372268711 Change-Id: Idd6fa77432a9351269c968c961785a7cf5fab50c Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5944061 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
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>
Charlie Lao 2dcc80dd 2024-10-17T13:59:23 Vulkan: allocateDescriptorSet to avoid repeated try on same pool DynamicDescriptorPool::allocateDescriptorSet has a few steps. It first tries to allocate from the same pool. Then tries to allocate from mCurrentPoolIndex and then loops all existing pools. This CL keeps the same basic logic, but avoids repeated tries on the same pool. Bug: angleproject:372268711 Change-Id: Ic3099ac8c68688fe9afe452f808be29ac9063d51 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5926182 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 9a4c7495 2024-10-15T13:05:28 Vulkan: Add feature flag to enable descriptorSet cache So that we can disable it to compare the performance difference. Bug: angleproject:372268711 Change-Id: I02da254e5d58815741080634a2dd005617aa7432 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5936135 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Charlie Lao dd54eeec 2024-10-11T13:26:46 Reland "Vulkan: Track GPU progress for individual DescriptorSet" This is a reland of commit 292102944add2ab30f4aa12a971cac456cc7726b with the fix of garbage being added back to garbage list. Original change's description: > Vulkan: Track GPU progress for individual DescriptorSet > > Right now ProgramExecutableVk keeps VkDescriptorSet object, and > DescriptorSetHelper is created when a cache entry becomes invalid. > Further, DescriptorSetCache keeps the cache of {VkDescriptorSet, > RefCountedDescriptorPoolHelper} pair. So we are having three different > type of objects at different stages of life: VkDescriptorSet, > DescriptorSetHelper, and {VkDescriptorSet, > RefCountedDescriptorPoolHelper. This CL makes DescriptorSetHelper at > creation and at cache and at garbage. With this change, you have a > reference counted DescriptorSetHelper object (i.e, DescriptorSetPointer) > during entire life cycle and is passed around between cache and program > as is. This CL is preparation for the future CL where we may disable > cache for descriptorSet. The descriptorSet will be added to garbage list > and reused constantly without go through the cache code. We need to > track the individual descriptorSet with ResourceUse so that it won't > reuse until GPU is finished. This CL is making DescriptorSetHelper a GPU > tracking object so that it will still just work when cache is disabled. > > Bug: angleproject:372268711 > Change-Id: I1cfb77cc5069b202d870388fd8809e265cdca90b > Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5918586 > Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> > Commit-Queue: Charlie Lao <cclao@google.com> > Reviewed-by: Yuxin Hu <yuxinhu@google.com> Bug: angleproject:372268711 Change-Id: Ic920f99cc78cde1e94690bdbee3b885844fa155b Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5954701 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Charlie Lao 45cc47af 2024-10-22T21:41:22 Revert "Vulkan: Track GPU progress for individual DescriptorSet" This reverts commit 292102944add2ab30f4aa12a971cac456cc7726b. Reason for revert: Causing bot failure in later CLs Original change's description: > Vulkan: Track GPU progress for individual DescriptorSet > > Right now ProgramExecutableVk keeps VkDescriptorSet object, and > DescriptorSetHelper is created when a cache entry becomes invalid. > Further, DescriptorSetCache keeps the cache of {VkDescriptorSet, > RefCountedDescriptorPoolHelper} pair. So we are having three different > type of objects at different stages of life: VkDescriptorSet, > DescriptorSetHelper, and {VkDescriptorSet, > RefCountedDescriptorPoolHelper. This CL makes DescriptorSetHelper at > creation and at cache and at garbage. With this change, you have a > reference counted DescriptorSetHelper object (i.e, DescriptorSetPointer) > during entire life cycle and is passed around between cache and program > as is. This CL is preparation for the future CL where we may disable > cache for descriptorSet. The descriptorSet will be added to garbage list > and reused constantly without go through the cache code. We need to > track the individual descriptorSet with ResourceUse so that it won't > reuse until GPU is finished. This CL is making DescriptorSetHelper a GPU > tracking object so that it will still just work when cache is disabled. > > Bug: angleproject:372268711 > Change-Id: I1cfb77cc5069b202d870388fd8809e265cdca90b > Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5918586 > Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> > Commit-Queue: Charlie Lao <cclao@google.com> > Reviewed-by: Yuxin Hu <yuxinhu@google.com> Bug: angleproject:372268711 Change-Id: I4d3c34058d100112a098144276b52c0faf8d593a No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5955529 Auto-Submit: Charlie Lao <cclao@google.com> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Rafay Khurram 99ba07d3 2024-03-26T00:58:57 CL/Vulkan: Implement createImage Enabling functionality of: - clCreateImage Tests-Passing: OCLCTS.test_api get_image<1d|2d|3d>_info Bug: angleproject:42266936 Signed-off-by: Rafay Khurram <r.khurram@samsung.com> Change-Id: I0281f092bff13cdd81b87d596fdd15b33dda7e46 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5796527 Reviewed-by: Geoff Lang <geofflang@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 29210294 2024-10-11T13:26:46 Vulkan: Track GPU progress for individual DescriptorSet Right now ProgramExecutableVk keeps VkDescriptorSet object, and DescriptorSetHelper is created when a cache entry becomes invalid. Further, DescriptorSetCache keeps the cache of {VkDescriptorSet, RefCountedDescriptorPoolHelper} pair. So we are having three different type of objects at different stages of life: VkDescriptorSet, DescriptorSetHelper, and {VkDescriptorSet, RefCountedDescriptorPoolHelper. This CL makes DescriptorSetHelper at creation and at cache and at garbage. With this change, you have a reference counted DescriptorSetHelper object (i.e, DescriptorSetPointer) during entire life cycle and is passed around between cache and program as is. This CL is preparation for the future CL where we may disable cache for descriptorSet. The descriptorSet will be added to garbage list and reused constantly without go through the cache code. We need to track the individual descriptorSet with ResourceUse so that it won't reuse until GPU is finished. This CL is making DescriptorSetHelper a GPU tracking object so that it will still just work when cache is disabled. Bug: angleproject:372268711 Change-Id: I1cfb77cc5069b202d870388fd8809e265cdca90b Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5918586 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Charlie Lao 4bdcdf0d 2024-10-16T11:44:49 Vulkan: Switch RefCountedDescriptorPoolBinding to use SharedPtr This mostly a clean up. RefCountedDescriptorPoolBinding is replaced with DescriptorPoolPointer, which is defined as SharedPtr<DescriptorPoolHelper>. It has more intuitive semantics to use. Bug: angleproject:372268711 Change-Id: I0397111b5228e896c1d226e00930851319d955a0 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5938947 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao c52e8493 2024-10-11T14:21:19 Vulkan: Switch DescriptorPoolPointer to use SharedPtr To make the reference counting easier to maintain, SharedPtr class is added to automatically tracking the reference counting and object creation/destruction. Right now we have BindingPointer class doing similar things except it does not automatically manage the object create/destroy, which makes it less robust as well as redundant code to manage object life cycle. The other problem with BindingPointer is that it does not work with normal assign/copy operator which made it hard to read and use. SharedPtr uses exact same API semantics as std::shared_ptr, which makes the reference counting very easy to use. The main difference of SharedPtr and std::shared_ptr is that it does not use any atomic or lock since it assumes user only uses it under thread safe environment, which ANGLE's backend is. This CL also changes mDescriptorPools to mDynamicDescriptorPools to make it clear that it is dynamic descriptor pool not the descriptor pool. This is also preparation CL for the next CL where we will use SharedPtr to manage DescriptorSetHelper life cycle, which otherwise a bit complicated to manually manage. Bug: angleproject:372268711 Change-Id: I1033d9bf259bbc075a9b374d8a28e1f67d889873 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5926183 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi a19f0947 2024-10-17T22:42:30 Vulkan: Cache depth- and stencil-only views Existing depth/stencil blit and resolve paths created temporary depth- and stencil-only views. For GL_ARM_shader_framebuffer_fetch_depth_stencil, such views are needed as well. In preparation for that extension, this change adds depth- and stencil-only views to ImageViewHelper and allows them to be retrieved through RenderTargetVk. The blit and resolve paths are consequently simplfied as a side-effect. Bug: angleproject:352364582 Change-Id: Ia822efb44ca7c82f63afce904eb19dd1bed02ff5 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5938149 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Yuxin Hu <yuxinhu@google.com> Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Shahbaz Youssefi a1584f49 2024-10-11T21:17:32 Vulkan: Qualify framebuffer fetch with "Color" In preparation for depth/stencil framebuffer fetch, many framebuffer fetch symbols are affixed with Color to indicate that they pertain to color framebuffer fetch logic. Bug: angleproject:352364582 Change-Id: I86000ada5e6ef47387dec0b6a3fca589d816cdc2 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5926593 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Charlie Lao 62f33a5c 2024-10-09T16:06:54 Vulkan: Make retainResource for descriptorSetPool consistent Right now the cache hit and cache miss case are handled differently. This CL makes it consistent. Now Caller of DynamicDescriptorPool::getOrAllocateDescriptorSet will handle this retainResource call regardless of cache hit or miss. Bug: b/372268711 Change-Id: I11e47ab9e56a24eb68a0231c5e553ab6b8833c82 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5921640 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Mohan Maiya b3d85cce 2024-09-30T14:28:35 Vulkan: Consolidate write colorspace override states ColorspaceState struct is now used to cache write colorspace related states to determine the colorspace of Vulkan draw image views. ImageViewHelper methods are called during initialization and when colorspace related states are toggled dynamically which in turn process these states and determine the final write colorspace. We can now fully support rendering to EGLImages, with colorspace overrides, via texture or renderbuffer EGLImage targets Bug: angleproject:40644776 Tests: ImageTest*Colorspace*Vulkan MultithreadingTestES3.SharedSrgbTextureMultipleContexts*Vulkan ReadPixelsPBOTest.SrgbUnorm*Vulkan Change-Id: I2be2cd3b5b2b4ac8ecb803c34cde2b846cbd1cbe Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5901256 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: mohan maiya <m.maiya@samsung.com>
Mohan Maiya b38cc7fa 2024-09-30T12:43:09 Vulkan: Consolidate read colorspace override states ColorspaceState struct is now used to cache read colorspace related states to determine the colorspace of Vulkan read image views. ImageViewHelper methods are called during initialization and when colorspace related states are toggled dynamically which in turn process these states and determine the final read colorspace. Bug: angleproject:40644776 Tests: ImageTest*Colorspace*Vulkan SRGBTextureTest.SRGB*TextureParameter*Vulkan SRGBTextureTestES3.SRGBDecodeTexelFetch*Vulkan Change-Id: I16b3666cd80865936b826dc0738fc9210dabeda9 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5901255 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: mohan maiya <m.maiya@samsung.com>