kc3-lang/angle/src/libANGLE/renderer/vulkan/vk_helpers.cpp

src/libANGLE/renderer/vulkan/vk_helpers.cpp

Log

Author Commit Date CI Message
Shahbaz Youssefi 52fe3116 2023-07-17T16:20:54 Vulkan: Deduplicate share group's context set tracking Bug: angleproject:8224 Change-Id: I7a59a37229682fb91ff777f31e02e05d7ab2b80f Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4690345 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Geoff Lang <geofflang@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 6ffd0d20 2023-07-12T12:09:45 Vulkan: Clean up depth stencil feedback mode part 2 Right now the tracking of depth stencil buffer readOnly or feedback loop is in FramebufferVk class. This really belongs to ContextVk, since it is not a permanent state of framebuffer, but current state of context. This CL moves it to ContextVk and changes to use BitSet instead of four boolean. Bug: b/289436017 Change-Id: I955c439259935f82eff30ddfff776a69723e5d0d Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4679886 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Charlie Lao a33ec5dd 2023-07-11T18:01:12 Vulkan: Clean up depthStencil feedback loop implementation Part1 This is first clean up effort for depth stencil feedback loop implementation. This CL moves updateRenderPassStencilReadOnlyMode and updateRenderPassDepthReadOnlyMode methods from FramebufferVk to RenderPassCommandBufferHelper class. The method is actually updating renderPass's state, not FramebufferVk's state. In the next CL, FramebufferVk will be removed from the argument as well. With this change, I also removes updateStartedRenderPassWithDepthMode() and updateStartedRenderPassWithStencilMode() to use updateStartedRenderPassWithDepthStencilMode() directly. This CL is mechanical changes only, no behavior chnage is expected. Bug: b/289436017 Change-Id: Id3960f973a7115c05ebea199cb8ef802e995941a Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4679365 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Shahbaz Youssefi 0892420b 2023-06-28T23:03:51 Vulkan: Optimize PBO download between RGBA and BGRA Google Meet hits this path in Chrome when blurring the background. The CPU readback was particularly slow on Intel/Mesa where readback from the temp buffer took hundreds of milliseconds. This change adds a compute shader that directly copies from the image to the pack buffer in simple but common cases. Bug: b/286882707 Change-Id: I9877ea01e3d8377db96f2539362aca67cf832b4a Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4657058 Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Yuxin Hu <yuxinhu@google.com>
Amirali Abdolrashidi 5f9548c3 2023-05-19T11:51:04 Vulkan: Free the garbage memory before realloc Currently image allocations fall back to system memory in case of a device OOM. However, in some cases, it is also possible to gain some memory by freeing garbage memory from the device. This allows us to keep the allocation on the device memory. * Updated the image allocation fallback, so we will try cleaning the garbage memory through the renderer before retrying the allocation. * finishOneCommandBatchAndCleanup() in RendererVk, which will call a similar function in its CommandQueue. It will be called until there are no more in-flight submissions. * The existing finishOneCommandBatchAndCleanup() in CommandQueue has been renamed to finishOneCommandBatchAndCleanupImpl(). * Updated the flags used for VMA image allocations. If any device memory is freed after garbage cleanup to make enough space for the new allocation, it will take precedence over the system memory. * Added unit tests in which a new image allocation could happen on the device after freeing the garbage memory. * They use a 2D texture and a 2D texture array for garbage. Bug: b/280304441 Change-Id: Ia5e605e180833b44af8c77550ab1b0b8ba21724e Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4547941 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Shahbaz Youssefi 86e21fa2 2023-06-12T13:36:21 Vulkan: Refactor angle::Format depth/stencil checks Bug: b/246008627 Change-Id: If0a2992c5bd66adf27c6866aea04e54ba465a522 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4608489 Reviewed-by: Roman Lavrov <romanl@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Charlie Lao ba857c47 2023-06-01T11:33:22 Vulkan: Move some bufferRead logic into CommandBufferHelperCommon Some of the logic of bufferRead is common, to avoid code duplication, it has been refactored into bufferReadImpl and moved into CommandBufferHelperCommon. Bug: b/282194402 Change-Id: I98cd0788db7fe9f14bd3155b28dc208f9f4a138a Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4581061 Reviewed-by: Roman Lavrov <romanl@google.com> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao 2501903e 2023-05-31T11:59:36 Vulkan: Merge UpdateShader***Buffers into updateShaderBuffers Both UpdateShaderUniformBuffers() and DescriptorSetDescBuilder::updateShaderBuffers() walks the list of uniform blocks (or storage blocks). Some of the logic are the same and we are paying that overhead twice. In this CL, UpdateShaderStorageBuffers, UpdateShaderUniformBuffers and UpdateShaderAtomicCounterBuffers functions are merged into DescriptorSetDescBuilder::updateShaderBuffers and DescriptorSetDescBuilder::updateAtomicCounters. In order to handle the usage that same buffer used by multiple shader stages, a new variant of bufferRead() function is added that takes "const gl::ShaderBitSet" instead of single PipelineStage. This also paves way for next CL so that we can call updateOneShaderBuffer individually. Bug: b/282194402 Change-Id: I09d045d6295827b60bdb4c05df9333fe593fa40e Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4574288 Reviewed-by: Roman Lavrov <romanl@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Shahbaz Youssefi b76166d0 2023-05-18T09:57:25 Vulkan: Separate image and sampler 2D view of 3D features The sampler feature is used to determine if EGL_KHR_gl_texture_3D_image can be exposed. The image feature is used to support base GLES 3.1 storage images. Bug: b/274478146 Change-Id: Ifb283633078ace7ee65f8aafe756d0a02b727bd7 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4545005 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 80dd54f9 2023-05-17T22:16:59 Vulkan: Enable VK_EXT_image_2d_view_of_3d and set flag Based on a change by Yiwei Zhang <zzyiwei@chromium.org> Enabling the extension was missed from https://chromium-review.googlesource.com/c/angle/angle/+/3648586, and some implementations do rely on the feature enablement (e.g. RADV). This also fixes the VVL violations on satisfied implementations. Additionally, the VK_IMAGE_CREATE_2D_VIEW_COMPATIBLE_BIT_EXT flag is always set on 3D images when this extension is supported; it is needed for both sampled and storage images, not just storage images. Bug: b/274478146 Change-Id: Ibc210275e2d39ac0c54d1ae4c2451a5402360972 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4544762 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org> Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Cody Northrop ec308b35 2023-05-15T15:03:10 Vulkan: Add feature to limit sample count to 2 This CL adds a feature called `limitSampleCountTo2`. Using it will have the Vulkan backend limit max samples to 2. Why 2? That's the minimum required in Vulkan to multisample without error. Here's an example validation error: vkCmdResolveImage: srcImage sample count is VK_SAMPLE_COUNT_1_BIT. The Vulkan spec states: srcImage must have a sample count equal to any valid sample count value other than VK_SAMPLE_COUNT_1_BIT. https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-vkCmdResolveImage-srcImage-00257 Using a limit as opposed to forcing a value allows non-multisampling (sample count of 1) to continue working. To see how tests fare when the feature is set, see the following test results that force the value on: https://chromium-review.googlesource.com/c/angle/angle/+/4534098/4 Test: adb shell setprop debug.angle.feature_overrides_enabled limitSampleCountTo2 Bug: b/279498079 Bug: angleproject:8162 Change-Id: I1df2822709151e6084c32055b5aff444e0b10db5 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4518562 Commit-Queue: Cody Northrop <cnorthrop@google.com> Reviewed-by: Geoff Lang <geofflang@chromium.org> Reviewed-by: Greg Schlomoff <gregschlom@google.com> Reviewed-by: Charlie Lao <cclao@google.com>
Amirali Abdolrashidi 6f959e07 2023-04-28T16:00:11 Vulkan: Add non-device memory option for VMA image * Updated the required flags for allocateAndBindMemory() to no longer include VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT, though still preferred. This allows VMA to allocate from another memory type if the device is out of memory. * Added a debug message to indicate when allocated memory for VMA image does not have all the preferred property flags. * Also added a warning in the case of memory allocation fallback. * Added a perf counter to keep track of image allocation fallbacks from the device memory. * deviceMemoryImageAllocationFallbacks * Added a test to make sure that VMA images can still be allocated from other memory types even if device memory is unavailable. * VulkanImageTest.AllocateVMAImageWhenDeviceOOM Bug: b/280304441 Change-Id: Ic452c18ded25345cdb7e271442372b99aede045e Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4493483 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Igor Nazarov e24f4519 2023-01-19T02:30:39 Vulkan: Add externalFence into submitCommands() Currently one-off fence in the `queueSubmitOneOff()` is used only in `SyncHelperNativeFence::initializeWithFd()` to submit external fence. Other `queueSubmitOneOff()` calls may use `QueueSerial` instead of a fence. Providing `fence` into `queueSubmitOneOff()` prevents tracking that submission with `QueueSerial`. Therefore using `mUse` to collecting `mFenceWithFd` as garbage will not work as intended. This CL removes `fence` from `queueSubmitOneOff()` and adds optional `externalFence` into `submitCommands()` instead. Providing `externalFence` will cause additional `vkQueueSubmit()` call: - first submission will submit everything as usual except using the `externalFence`. - second, will only submit internal `CommandQueue` fence for `QueueSerial` tracking. As the result of this CL, call to `initializeWithFd()` will always produce two (2) `vkQueueSubmit()` calls. Previously it may be one (1) or two (2) submissions. Future CL will reduce submission count to one (1). If add additional submission into `queueSubmitOneOff()` instead of `submitCommands()`, then maximum number of submissions will be three (3). Bug: angleproject:8117 Change-Id: I6f1ec12682aaab71bfc871e665fec2659df96b26 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4392877 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Amirali Abdolrashidi a73e546c 2023-04-14T13:40:19 Vulkan: Add pending memory size for VMA images * Added implementation for vma::FindMemoryTypeIndexForImageInfo(). * Add pending memory allocation tracking for VMA images using the memory requirement from getMemoryRequirements() and the memory type index from the function above. Bug: b/218891184 Change-Id: I1c3d3a8f5f36eb57bd7a5a059aa3bf713b819831 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4428535 Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com>
Shahbaz Youssefi 13935469 2023-04-25T09:58:42 Vulkan: Fix access mask of generateMipmap's blit Bug: angleproject:8143 Bug: angleproject:7125 Change-Id: I6e5b6cd1f445c2c41d4b78aeb368e30cc4c5354b Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4475444 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Roman Lavrov 2ce6d8df 2023-04-20T17:16:00 TextureVk calls onStateChange when releasing buffer views TextureVk::setBuffer releases buffer views and they don't get initialized unless a dirty bit is set. That works on the first draw call because Texture::Texture() sets DIRTY_BIT_IMPLEMENTATION in constructor, but when called twice mBufferViews remains unitialized causing mBufferViews.getView() misbehavior. Fix this by calling onStateChange when buffer views are released. As mBufferViews is only initialized conditionally for texture buffers, add a bool for tracking whether it is in the initialized state to avoid marking texture as dirty unnecessarily. Note that this isn't handled by signalDirtyStorage() inside Texture::setBufferRange because (in this test case?) there are no observers on Texture so onStateChange called from Texture is a no-op. Texture however observes its TextureVk implementation so onStateChange calls from TextureVk end up setting the dirty bit in Texture::onSubjectStateChange. Bug: b/278585075 Change-Id: I2b83160cdd89a086ed81e8412cd64d0aad930911 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4457147 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Roman Lavrov <romanl@google.com>
Amirali Abdolrashidi a7bd3f53 2023-03-31T16:57:35 Fix the retrace issue for VMA image suballocation After adding the VMA image suballocation feature, VVL errors were seen when using the retracing script for some traces, causing failure. After analysis, it was seen that the functionality of the allocation differs from the original method when it comes to non-zero memory allocation. * In allocateAndBindMemory(), the memory property flags from the allocated memory are returned to be used for non-zero memory feature usage. * Added mapMemoryAndInitWithNonZeroValue() to ImageMemorySuballocator, which is used when allocateNonZeroMemory is enabled and the allocated memory is host-visible. * Merged the following into ImageHelper::initializeNonZeroMemory(): * mapMemoryAndInitWithNonZeroValue() * InitMappableDeviceMemory(); used when VMA image suballocation is disabled. * Moved onMemoryAlloc() inside allocateAndBindMemory(). Test: retrace_restricted_traces.py Bug: b/277618656 Bug: angleproject:8058 Change-Id: If411a073e900c1c034d40a99e3fffefe30c82548 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4391403 Reviewed-by: Cody Northrop <cnorthrop@google.com> Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com> Reviewed-by: Charlie Lao <cclao@google.com>
Charlie Lao d58fbf04 2023-04-05T12:32:09 Vulkan: Wait for surface ANI semaphore only if image is used Right now there is a bug that surface's ANI semaphore is added to context when WindowSurfaceVk::getAttachmentRenderTarget get called, which gets called from FramebufferVk::syncState, which is before we end the previous render pass, due to the endRenderpass usually is deferred until next renderPass starts. This caused ANI semaphore gets added to the previous render pass's submission, which does not use surface, and thus a bubble in GPU execution pipeline where the user FBO rendering gets unnecessarily blocked until ANI semaphore is signaled. This lowers GPU utilization and thus GPU frequency gets dropped and frame time increased. This CL stores ANI semaphore to ImageHelper object and when barrier is generated, the ANI semaphore is moved to CommandBuffer. When CommandBuffer gets flushed and submitted, it gets added to the waitSemaphores vector and submitted to vulkan. Since all use of swap chain image must go through barrier code first (you need at least change layout), this ensures ANI semaphore gets waited in exact and robust way. Only the submission that references the swap chain image will be waited. With this CL, professional_baseball_spirits reduces frame time from 3.8 ms to 2.7 ms, achieving parity with native GLES on pixel 7 pro. Bug: b/275624771 Change-Id: Ifa6cacf9e3bc147bfde54eb7def2fca48c50aca0 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4400011 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 65ed3050 2023-04-04T11:57:38 Vulkan: Let recordWriteBarrier use CommandBufferHelper This is preparation for next CL. It changes OutsideRenderPassCommandBuffer argument to OutsideRenderPassCommandBufferHelper for recordWriteBarrier() and recordReadBarrier() calls, so that it has access to the helper object (will be used in next CL). It passes CommandsState to executeBarriers() instead of PrimaryCommandBuffer. No actual functionality change is expected. Bug: b/275624771 Change-Id: Ia06a0398a127539b0b642005803a498cb2a9d7f1 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4400407 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 20f3df07 2023-03-30T11:36:29 Vulkan: ImageHelper::initExternal missing some variable init When ImageHelper::releaseImage is called and then re-initialized (due to mipmap change or usage change etc), right now we have a bug that mCurrentShaderReadStageMask and mLastNonShaderReadOnlyLayout are still left as is. And they do not get reset when image is initialized. This means if the image was reinitialized again, it may end up think the new image was previously used by fragment shader and insert an unnecessary barrier when new VkImage is used. This was discovered when I do the experimental work try to ghost VkImage for glTexSubImage call and realized that new VkImage was having a strong fragment->vertex dependency which it should not (since this is a new VkImage). This CL initialize mCurrentShaderReadStageMask and mLastNonShaderReadOnlyLayout and mCurrentQueueFamilyIndex from initExternal call since it is a new vkImage. Bug: b/273808966 Change-Id: I5bbeae5f1012f10c24620cfae8fa20365a7b5ab7 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4386136 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Igor Nazarov 9524c639 2023-01-17T18:47:47 Vulkan: Fix Secondary Command Buffers with asyncCommandQueue. This change fixes following errors (asyncCommandQueue = true): 1. "vkEndCommandBuffer()" called from "asyncCommandQueue" thread. Call stack: vkEndCommandBuffer() VulkanSecondaryCommandBuffer::end() OutsideRenderPassCommandBufferHelper::flushToPrimary() CommandQueue::flushOutsideRPCommands() CommandProcessor::processTask() Fixed by calling "vkEndCommandBuffer()" from the Context thread in the new "OutsideRenderPassCommandBufferHelper::detachCommandPool()" method. 2. "vkAllocateCommandBuffers()/vkBeginCommandBuffer()" called from "asyncCommandQueue" thread. Call stack: vkAllocateCommandBuffers()/vkBeginCommandBuffer() VulkanSecondaryCommandBuffer::initialize() <*>CommandBufferHelper::initializeCommandBuffer() <*>CommandBufferHelper::reset() <*>CommandBufferHelper::flushToPrimary() CommandQueue::flush<*>Commands() CommandProcessor::processTask() Fixed by calling "vkAllocateCommandBuffers()/vkBeginCommandBuffer()" from the Context thread in the new "<*>CommandBufferHelper::attachCommandPool()" method. 3. "SecondaryCommandPool::collect()" called from "asyncCommandQueue" thread without synchronization. Call stack: SecondaryCommandPool::collect() rx::vk::RecycleCommandBufferHelper() CommandBufferRecycler<>::recycleCommandBufferHelper) RendererVk::recycle<*>CommandBufferHelper() CommandProcessor::processTask() No need for this call, because "SecondaryCommandPool" is already detached. Notes: This CL not only fixes errors, but also optimizes CommandBufferHelper recycling. Before, there was no recycling plus unnecessary "VulkanSecondaryCommandBuffer" allocation/freeing. Further optimization may add multiple "VkCommandPool"s to the "SecondaryCommandPool" to allow resetting buffers in the async thread. Bug: angleproject:6811 Bug: angleproject:6100 Change-Id: I7004c27a112e916c5c973b43b137193017d6aa3d Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4342189 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Greg Schlomoff a621ea88 2023-03-17T10:21:56 Adding a trace point for texture metrics. Bug: b/236121838 Change-Id: I28e7977f7b5dc6e24cb5a2be10689c223851ba0b Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4348737 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Doug Horn <doughorn@google.com> Reviewed-by: Charlie Lao <cclao@google.com>
Igor Nazarov 7d1a401b 2023-01-17T18:45:55 Vulkan: Fix freeing not completed Secondary Command Buffers. Problem: - Protected Context flushes its commands to the Protected Primary Command Buffer; - Unprotected Context flushes its commands to the Unprotected Primary Command Buffer; - Context with different "egl::ContextPriority" may flush commands into different Primary Command Buffers. - Secondary Command Buffers from all Contexts end-up in the single "CommandBufferRecycler::mSecondaryCommandBuffersToReset" list; - One of the Contexts submits its Primary Command Buffer, and attaches current "mSecondaryCommandBuffersToReset" list to the "CommandBatch"; - Secondary Command Buffers of other Contexts may be collected and later freed by "SecondaryCommandPool" without submitting/completion corresponding Primary Command Buffers. Fix: - Moving "mSecondaryCommandBuffersToReset" to the new "SecondaryCommandBufferCollector" class. - Separate "SecondaryCommandBufferCollector" instance is stored in the "CommandQueue" for each current Primary Command Buffer. Additionally fixes "asyncCommandQueue" related problem: "releaseCommandBuffersToReset()" may get outdated results if flush is not yet executed in the "asyncCommandQueue" thread. Bug: angleproject:6100 Change-Id: I7df161ac1f999fb34d4eccaebb603c58ecb1ac11 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4334579 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Igor Nazarov 9b6368cc 2023-03-14T14:48:30 Vulkan: Fix freeing Secondary Command Buffers from wrong thread. Problem: - Secondary Command Buffers are freed in the "CommandQueue" class. - This may happen from any Context thread that calls "checkCompletedCommands()" or "finish<*>()" methods. - As the result, one Command Buffer may be freed from one thread, while other Command Buffer from the same "VkCommandPool" is allocated/reset/recorded in the other thread. Vulkan spec demands external "VkCommandPool" synchronization for any modifications (begin/end/reset/free/cmd) on its "VkCommandBuffer"s. Fix: - Added new "rx::vk::SecondaryCommandPool" class that replaces the "rx::vk::CommandPool" wrapper. - This class has "collect()" method for storing "VkCommandBuffer"s. Collected buffers are freed from the correct thread on the next "allocate()" call. This CL only fixes the problem, keeping Secondary Command Buffer memory management as is (allocate/free single buffer without reuse). In the future CLs this behavior may be changed (reuse buffers, reset/free entire pools). Bug: angleproject:6100 Change-Id: If938416c4df4fe55f0cfb418b6759721ac53098b Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4334577 Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Igor Nazarov <i.nazarov@samsung.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 4c157b4b 2023-03-14T18:45:38 Vulkan: Switch staging buffer to Buddy algorithm Staging buffer should be considered as dynamic and uses buddy allocator. Bug: b/271915956 Change-Id: I7cbe3765fdae120582034b24376560043e007e67 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4327290 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Charlie Lao d6a25bfa 2023-03-07T15:06:10 Vulkan: Optimize glBufferData call to improve storage reuse If app calls glBufferData with certain size, then calls it again with size 0, and then call it again with same old size again, we should try to reuse the existing storage. When size is zero, with the existing logic, we never free the storage. When glBufferData is called third time with the same size as the first glBufferData call, we expect to reuse the existing storage. But because of the storage reuse logic is comparing buffer's new size to the old size (which is 0), we missed the opportunity to reuse the existing storage. This CL update the reuse logic so that it checks the new size against storage's size (instead of OpenGLES buffer's size) and if we will end up with same sized allocation and same pool and memory type, then we reuse instead of reallocate. This reduces efootball_pes_2021 frame time from 4.670 ms to 4.277 ms on pixel 7 pro. Bug: b/271915956 Change-Id: I6f91e3e85b104eca215b28e7d0bea413ecc4401c Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4317488 Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 67ad3ddc 2023-03-06T16:44:36 Vulkan: Relax size limit for dynamicBuffer to pick buddy algorithm If glBufferData's usage is one of the dynamic usage, app may keep calling glBufferData frequently, which means get into suballocation code frequently. There are two suballocation algorithms today: buddy algorithm (faster) and generic (slower). Right now the decision of which algorithm (i.e, which pool) to use is purely based on size or memory type. This CL also utilize usage information so that dynamic usage will pick buddy algorithm with bigger size threshold. mSmallBufferPool is removed and replaced with the BufferPoolPointerArray that gets picked based on allocation algorithm. This CL reduces average frame time of efootball_pes_2021 from 7.518 ms to 4.670 ms on pixel 7 Pro. Bug: b/271915956 Change-Id: I1c2f270ac49f56e6f405501d20691cfbab49e7eb Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4313685 Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Igor Nazarov 233c128b 2023-01-17T19:21:58 Vulkan: Fix UBs when deleted attachment is used in a RenderPass. Problem: - "RenderbufferVk"/"TextureVk" with "mOwnsImage == false" used as RenderPass attachment. - "RenderbufferVk"/"TextureVk" deleted. - Owning resource is destroyed ("EGLImage" and all siblings / "EGLSurface"). - Crash (UB) may happen when ending RenderPass, flushing or executing commands. Fix adds tracking of "vk::ImageSourceID" value in "vk::RenderPassAttachment" - IDs of objects, that originally provide "vk::ImageHelper" images. This is necessary, because when using EGLImage, there may be multiple "TextureVk" objects with same "vk::ImageHelper", and need to call "finalizeImageLayout()" for the correct attachment. Bug: angleproject:8032 Test: angle_end2end_tests --gtest_filter=ImageTest*DeletedWhileInUse* Test: angle_end2end_tests --gtest_filter=PbufferTest.UseAsFramebufferColorThenDestroy* Change-Id: I50fdd9d6b6a9677adad2262373303b46de1dee4c Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4296014 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Igor Nazarov 244e1931 2023-01-17T19:22:10 Vulkan: Fix use of pending Outside RenderPass CommandBuffer. Regression from this commit: 730c127102b540ce2c4ec086b037c8b732706e26 "Vulkan: Submit queue more often for texture data" Bug: angleproject:6354 Test: angle_end2end_tests --gtest_filter=*SubmittingOutsideCommandBufferAssertIsOpen* Change-Id: I5f72f499cd7153c94c8e5f8a3415df2182726c8e Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4296802 Commit-Queue: Igor Nazarov <i.nazarov@samsung.com> Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Igor Nazarov ad7949c6 2023-01-17T19:24:59 Vulkan: Remove "rx::vk::ImageHelper" move constructor. Move constructor was only used in the "rx::SwapchainImage" structure. This CL replaces "image" member with "std::unique_ptr<vk::ImageHelper>". This will remove source of bugs. Bug: angleproject:8052 Change-Id: Ic16f674095233baaa56fbe8a8fb7ef3e323a7331 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4294905 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Igor Nazarov dbece66f 2023-01-17T19:25:24 Vulkan: Fix move constructor/assignment of Resource classes. Bug in "DynamicallyGrowingPool<Pool>::PoolResource" causes real problems with queries. "QueryPool" may be reused without waiting for the previous use. Bugs "QueryHelper" may affect "mInFlightGpuEventQueries" (not used in "QueryVk"). Updated "FramebufferHelper" move assignment so it uses "Resource" assignment instead of protected member access. Bug: angleproject:8053 Change-Id: I441b62102fcf232456027fb42eefa97ed8958676 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4300050 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Charlie Lao 7eb6869a 2022-08-30T16:28:08 Vulkan: Change ResourceAccess::Write to ResourceAccess::ReadWrite AS a preparation for the next CL which will optimize for WriteOnly access, this CL changes Write to ReadWrite and adds WriteOnly access (but not used yet). Mechanical changes only and no function difference is expected. Bug: b/243711628 Change-Id: I509d6045ae87635e24076b646af42f35d88d52cf Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3866672 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Igor Nazarov 764cdbad 2023-01-25T18:25:57 Vulkan: Add missing mutex lock into resetCommandBuffer(). Regression after the commit: 77d19e39794cc2de28f33a714f27af5a7de128ae Vulkan: Add ThreadSafeCommandQueue class Bug: b/261106868 Change-Id: I083b1bdc42a1382d32ab9087c92adbb963ff7d1e Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4300869 Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Igor Nazarov 1365f5b3 2022-09-09T17:19:26 Vulkan: Fix Swapchain Acquire Image Semaphore wait stage flags. There is a screen tearing on G996B with single "glClear(GL_COLOR_BUFFER_BIT)" no scissor in the frame. Fixed by defining "kSwapchainAcquireImageWaitStageFlags" and adding "VK_PIPELINE_STAGE_TRANSFER_BIT" stage flag. Also added "VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT" stage, because first use of the Swapchain Image after Acquire may be in the "glBlitFramebuffer()" command. This fix may slightly affect performance. In such case, a better fix should be implemented (include only stages based on the actual first use). However, this may be not trivial. Additionally, "kSwapchainAcquireImageWaitStageFlags" is used as a source stage mask in the "ImageLayout::Present" pipeline barrier. This is needed in order to build a dependency chain from the Acquire Image Semaphore to the layout transition's first synchronization scope, so that layout transition happens after acquire semaphore is signaled. Reference: https://github.com/KhronosGroup/Vulkan-Docs/wiki/Synchronization-Examples#combined-graphicspresent-queue https://vulkan-tutorial.com/Drawing_a_triangle/Drawing/Rendering_and_presentation Alternative fix of both issues is to define: kSwapchainAcquireImageWaitStageFlags = VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT This might potentially delay command buffer execution relative to the Swapchain Acquire Image Semaphore signal operations, but will relax the pipeline barrier. Bug: angleproject:8030 Test: angle_end2end_tests --gtest_also_run_disabled_tests --gtest_filter=EGLSurfaceTest.DISABLED_RandomClearTearing* Change-Id: I29f58862c4b369524b2555dd944e2fb67eebe956 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4271377 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Igor Nazarov <i.nazarov@samsung.com> Reviewed-by: Charlie Lao <cclao@google.com>
Amirali Abdolrashidi 3a7904e1 2023-01-25T23:56:56 Vulkan: Use VMA suballocation for images There is a maximum limit for device memory object allocation. On some platforms, there can be an error regarding too many object allocations when 4096 device memory handles have been allocated. Suballocation can help mitigate this issue. In this CL, some images will be allocated using VMA API calls, which use suballocation. * Added a new feature (useVmaForImageSuballocation). * Added VMA allocation for ImageHelper, which is used in initMemory(). * Suballocation is used for VMA image allocation. * If enabled, mVmaAllocation will be initialized in the ImageHelper object (instead of mDeviceMemory). * It is currently used for all platforms. * Minor change to the name of an arg in CreateBuffer() declaration. * Added test to make sure we can allocate at least 4096 images on supported platforms (8000 in the test). * Skipped the test "NonZeroBaseEmulatedClear" when run on Linux/Intel if this feature is enabled (due to output color mismatch). * Skipped several tests for capture/replay on Windows. Bug: b/218891184 Change-Id: Ibf80c9c8c485b301da7d23b5ba4bcbb1a8e3194f Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4191202 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Igor Nazarov 9a4a9f3f 2023-02-16T17:33:52 Revert "Fix dEQP-EGL.functional.mutable_render_buffer#basic" This PARTIALLY reverts commit: 629da7fc9cd4886dd87f07a069c259551e892936. Fix dEQP-EGL.functional.mutable_render_buffer#basic From the reverted CL: This CL also addresses similar issue in some other rx::vk::ImageLayout items in kImageMemoryBarrierData. These were unnecessary changes that may harm performance: - adding BOTTOM_OF_PIPE for source stage when transition from LAYOUT_UNDEFINED may add unnecessary GPU bubble. - Transition to LAYOUT_PRESENT_SRC_KHR does not require barrier. All writes will be automatically made visible for Presentation Engine. Execution dependency satisfied by VkSemaphore. - Transition from LAYOUT_PRESENT_SRC_KHR is RAR/WAR. Execution dependency satisfied by VkSemaphore. - Some layouts may not be a destination so BOTTOM_OF_PIPE is OK. Bug: b/264420030 Change-Id: I8b57b1636e1f5cf5b647003adf1502bd3286c5a3 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4262067 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Igor Nazarov <i.nazarov@samsung.com> Reviewed-by: Charlie Lao <cclao@google.com>
Charlie Lao c402ea1c 2023-02-15T12:01:38 Vulkan: Rename hasUnfinishedUse to hasResourceUseFinished Most usage of hasUnfinishedUse is for !hasUnfinishedUse, and there was feedback that negative API is not preferred. This CL changes it to positive API name. Similarly renamed hasUnsubmittedUse to hasResourceUseSubmitted. Bug: b/267348918 Change-Id: Idb10b0f998ec50116ffb6aada19a98a516e87824 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4257105 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Igor Nazarov 8cac53cd 2023-01-17T19:22:57 Vulkan: Fix incorrect "SharedPresent" barrier. Previous fix swapped top/bottom barriers: 629da7fc9cd4886dd87f07a069c259551e892936 Fix dEQP-EGL.functional.mutable_render_buffer#basic Above fix is only partial, because it only includes execution dependency without memory barriers (top/bottom stages has no memory access). Fixed by forcing all possible stages for "SharedPresent" images. Better solution requires creating specific versions of "ImageLayout::SharedPresent". Added new test that skips "glFlush()" before "glReadPixels()". Performing flush executes present and may "fix" the barrier problem. New test fails on "Samsung Galaxy S22+ S906B" Bug: b/264420030 Test: angle_end2end_tests --gtest_filter="EGLSingleBufferTest.SharedPresentBarrier*" Change-Id: Icbb50900d99e42d2e9482cd6109981bbc460348a Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4262068 Commit-Queue: Igor Nazarov <i.nazarov@samsung.com> Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Yuxin Hu 629da7fc 2023-01-26T12:25:04 Fix dEQP-EGL.functional.mutable_render_buffer#basic These are vulkan commands submitted between glClear() and glReadPixels() when the EGL_RENDER_BUFFER is EGL_SINGLE_BUFFER (ImageLayour is SharedPresent): ``` vkCmdClearColorImage() vkCmdPipelineBarrier: ( VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT,//srcStageMask VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT,//dstStageMask VK_ACCESS_MEMORY_WRITE_BIT,//srcAccessMask VK_ACCESS_MEMORY_WRITE_BIT|VK_ACCESS_MEMORY_READ_BIT//dstAccessMask ) vkCmdCopyImageToBuffer() ``` This means that operations at the bottom of pipeline in vkCmdCopyImageToBuffer() need to wait for operations at the top of pipeline in vmCmdClearColorImage(), which translates to vkCmdCopyImageToBuffer() does not have to wait for vkCmdClearColorImage() to finish. Even the dstAccessMask ensures that vkCmdCopyImageToBuffer() will invalidate cache before copying image, it is possible that it will retrieve the old Framebuffer color attachment data as the vkCmdClearColorImage() has not finished. This CL fixes the bug by making the srcStageMask to be VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT and the dstStageMask to be VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT, when the ImageLayout is SharedPresent. This ensures that vkCmdCopyImageToBuffer() waits for vkCmdClearColorImage() to finish. This CL also addresses similar issue in some other rx::vk::ImageLayout items in kImageMemoryBarrierData. Bug: b/264420030 Change-Id: If47ab071afaf96e396357cb0f50131339fa58509 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4198476 Commit-Queue: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com>
Igor Nazarov 8b9bd182 2023-02-08T16:17:10 Vulkan: Refactoring to use ProtectionType enum instead of bool This is a second stage of refactoring that was started here: Vulkan: Minor CommandQueue implementation refactoring. 0210b46d35b51ea04bddafb48ba406a87c39e58e Enumeration renamed: CommandContent -> ProtectionType. Currently interfaces of ContextVk/RendererVk/CommandQueue use "hasProtectedContent" boolean. Internally CommandQueue uses "vk::ProtectionType" enumeration to separate states related to Unprotected/Protected commands. This CL replaces boolean with enumeration for consistency. Bug: angleproject:7995 Change-Id: Ibb98cce661358d464be7c6a8367a1297d7093b1c Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4232114 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Kaiyi Li ac0a4a7d 2023-02-03T15:34:32 Add finer memory allocation type ... so that when we hit an OOM we have better understanding on why. Bug: b/266466279 Test: trigger a Vulkan OOM, see detailed allocation logging info Change-Id: I71c1ebd83e18ddb22e7abfd29a785bf4ad6454dc Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4219365 Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Reviewed-by: Charlie Lao <cclao@google.com> Auto-Submit: Kaiyi Li <kaiyili@google.com> Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Igor Nazarov a88d9f03 2023-02-07T02:37:53 Vulkan: Refactoring in RenderPassCommandBufferHelper. This is a follow-up refactoring after CL: cae00d9bba91bd6857d71c07b853dba8485e2ab8 Vulkan: Cleanup shared ring buffer cmd alloc feature. "mCurrentSubpass" naming is a bit confusing. When custom Vulkan secondary command buffers are used, "mCurrentSubpass" is always "0". This is because custom command buffers allows storing multiple subpasses. This CL renames this member into "mCurrentSubpassCommandBufferIndex", to clearly state that it is refer to command buffer index of a current subpass. Custom command buffers will always use single buffer ("0"), while Vulkan secondary command buffers will have a buffer per subpass. Bug: b/256666069 Change-Id: I6777e3ca4ee57513e1c36f05f8d223eb086b095a Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4227072 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Igor Nazarov ef056a06 2023-01-20T14:15:48 Vulkan: Use SubmitPolicy::AllowDeferred whenever possible. Using of SubmitPolicy::EnsureSubmitted is not necessary, because there are finishQueueSerial() call immediately after that. Changing to AllowDeferred avoids extra waiting call (NO-OP) and saves some CPU cycles. Bug: angleproject:8001 Change-Id: Id618253a4b59d006975044eb437ac60468199a98 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4194187 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Igor Nazarov fa0681d1 2023-01-17T17:43:48 Vulkan: Per Context Serial cleanup. Comment in the "OutsideRenderPassCommandBufferHelper::reset()" is misleading. New "mQueueSerial" is always generated after "RendererVk::flushOutsideRPCommands()". This change removes comment and invalidates "mQueueSerial" to catch possible errors. Call "generateOutsideRenderPassCommandsQueueSerial()" in the "ContextVk::flushImpl()" only when needed. This call is necessary only with empty submission with only "signalSemaphore" and NO OutsideRP commands are written inside the "flushImpl()" (mIsAnyHostVisibleBufferWritten or mGpuEventsEnabled). Bug: b/267806287 Change-Id: Ibc547f97a6b38f70ad3d5901eca7b659b93014c0 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4218363 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Igor Nazarov cae00d9b 2023-01-17T18:44:48 Vulkan: Cleanup shared ring buffer cmd alloc feature. Changes: - Simplified "SharedCommandBlockPool" interface. Removed "ptrOut" and "usesCommandHeaderSizeForOffsetOut" parameters, because "headerOut" has exactly the same value. - Refactoring of "SharedCommandBlockPool" classes. Some public methods made private, inline, or moved into ".cpp". - Replace some getters with more specific/restrictive methods: - "RingBufferAllocatorBuffer::getStorageSize()" -> "isEmpty()" - "CommandBufferHelperCommon::getAllocator()" -> "hasAllocatorLinks()" - Added extra ASSERT()s. - fixed typo "kMinRingBufferAllocatio(r)Capacity" - other minor modifications. Bug: angleproject:6401 Bug: b/256666069 Change-Id: I8f5c1c928bac5f8ecdfce7d411834f7ea39d11ac Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4218364 Commit-Queue: Igor Nazarov <i.nazarov@samsung.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Alexey Knyazev 17931e23 2023-01-27T00:00:00 Fix stencil and depth/stencil data uploads Multiple changes were made to depth and stencil load functions, removing redundant code and fixing issues. Failures were caused by incorrect assumptions about component locations in combined formats. * D32_FLOAT_S8X24_UINT has the same layout as GL_FLOAT_32_UNSIGNED_INT_24_8_REV * D24_UNORM_S8_UINT has stencil data in its MSBs, while GL_UNSIGNED_INT_24_8 puts it in LSBs. Bugfixes * Added LoadD24S8ToS8D24 that swaps D24 and S8 components * Added LoadS8ToS8X24 for stencil-only uploads on D3D * Replaced LoadD24S8ToD32F with LoadD32ToD32F * Fixed D and S extraction in LoadD24S8ToD32FS8X24 * Fixed stencil load and store in LoadD32FS8X24ToS8D24 and LoadD32FS8X24ToD32FS8X24 * Fixed S8_UINT subresource updates in Vulkan * Fixed D24_UNORM_S8_UINT subresource updates from GL_FLOAT_32_UNSIGNED_INT_24_8_REV data in Vulkan Cleanup * Renamed LoadUNorm16To32F to LoadD16ToD32F * Removed LoadUNorm32To32F, replaced it with LoadD32ToD32F * Renamed LoadR32ToR24G8 to LoadD32ToX8D24 * Renamed LoadD32FS8X24ToD24S8 to LoadD32FS8X24ToS8D24 * Removed unused LoadG8R24ToR24G8 * Removed Metal-specific LoadS8D24S8ToD32FX24S8, made use of the fixed LoadD24S8ToD32FS8X24 instead * Simplifed LoadD24S8ToD32F Added Texture2DTestES3.TexImageWithStencilData. Fixed: chromium:1408004 Fixed: angleproject:5317 Change-Id: I231345353aa4a7cebe46ded8458ac80de2c59e01 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4203427 Reviewed-by: Geoff Lang <geofflang@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
Charlie Lao 9a72a98e 2023-01-19T13:17:42 Vulkan: Fix the VVL error for shaderRead to shaderRead barrier When we use image from fragment shader read to vertex shader read, we detect the case (same layout with only shader stage change) and just merge the barrier into one. But that can only done if these two usages are for the same render pass. If it is different render pass, then you still have to issue a new barrier. Previously there is no way to detect that the barrier was issued for which render pass. With the fix in crrev.com/cl/4136948, we now know which render pass issued the last barrier. With that we are able to limit the shader stage consolidation only if they are for the same render pass, thus fixing the VVL errors. Bug: angleproject:6663 Change-Id: I3d884336e8cf1f3cf16fc3e5a3423357ae2ed3c1 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4182542 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 77d19e39 2023-01-11T14:03:18 Vulkan: Add ThreadSafeCommandQueue class This is preparation CL for the next few CLs. Instead of having RendererVk owns mCommandQueueMutex and takes lock before calling CommandQueue APIs, this CL creates a ThreadSafeCommandQueue wrapper class that wraps CommandQueue class' public APIs with a mMutex. Right now this is purely a mechanical change, expecting no real functional or behavior differences. But in the future CLs, we are going to implement some APIs without holding lock while doing the wait. This also conceptually cleaner that a mutex lock should protect data not methods. Because of this, this CL also adds OneOffCommandPool class to wrap around all oneoff command buffers with its own lock. The same change also applied to CommandProcessor class by adding a ThreadSafeCommandProcessor class (this will be removed in later CLs). This CL also removes CommandQueueInterface base class and made all these virtual functions no longer virtual, thus reduces the overhead associate with calling virtual functions. Bug: b/261106868 Change-Id: Ifdc0085cef7f00d840b4ef3fa602172fed3c0fb1 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4156637 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Commit-Queue: Charlie Lao <cclao@google.com>
Amirali Abdolrashidi 48e40ef6 2023-01-06T13:35:21 Add per-heap memory allocation trackers * For each member of MemoryAllocationType, we now have a per-heap counter to keep track of the allocation size in each available heap. * mActivePerHeapMemoryAllocationsSize * mActivePerHeapMemoryAllocationsCount (debug mode only) * Added the memory type index to onMemoryAlloc() and onMemoryDealloc() as an input. It can then be used to determine the used memory heap index for that allocation using the memory properties defined in the renderer. * checkForCurrentMemoryAllocations() will now log the heap index of the current memory allocations in debug mode and during an OOM crash. * logPendingMemoryAllocation() will now log the heap index of the pending allocation during an OOM crash. * Renamed constexpr values used for tracking for more consistency. * kTrackMemoryAllocation -> kTrackMemoryAllocationSizes * kDebugMemoryAllocationLogs -> kTrackMemoryAllocationDebug Bug: b/262029018 Change-Id: I178a3556b3107edc0c72c6b23ea2f2d6b12da947 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4149431 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com> Reviewed-by: Ivan Neulander <ineula@google.com>
Charlie Lao 410d8ba5 2022-12-21T13:27:00 Vulkan: Cleanup ContextVk::hasStartedRenderPass APIs ContextVk has a few hasStartedRenderPass APIs which interpret "start" inconsistently. A RenderPassCommands' life should be notStarted, started, requestEnd, and end (which is equivalent to notStarted). When someone calls onRenderPassFinished on a started renderpass, it does not immediate endRenderPass, but it will set DIRTY_BIT_RENDER_PASS dirty bit so that next draw call will trigger endRenderPass and start a new renderPass. We do not have a name for this state, which adds some confusion. This CL renames the stage between start and onRenderPassFinished to be "active" renderpass, when you have mRenderPassCommandBuffer pointer being valid and you can actively adding draw commands into the renderPass. For this purpose, I haves renamed hasStartedRenderPass to hasActiveRenderPass. This CL also simplifies hasStartedRenderPass implementation to only check mRenderPassCommandBuffer and turned mRenderPassCommands.started as assertion. This CL also changes hasStartedRenderPassWithQueueSerial to actually check mRenderPassCommands.started instead of being "active", so that name reflects what it is actually checking. This CL also changed hasStartedRenderPassWithCommands to hasActiveRenderPassWithCommands to make name and implementation consistent. One added benefit of this is that after this CL we now allow load/store optimization on a started but inactive renderPass as well (for example glInvalidateFramebuffer call after glFenceSync call, or invalidate after FBO blit as demonstrated by MultisampleResolveTest.ResolveD32FSamples tests). Bug: angleproject:7903 Bug: angleproject:7551 Change-Id: I8c8ec4c0d54b9ad0a9e373108dfce6b151c8fe0e Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4119693 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Amirali Abdolrashidi f1872822 2022-12-22T17:17:37 Vulkan: Fix imageless framebuffer VVL issue In some tests, including some blink tests, there were cases of VVL messages spamming the output log, even though they did not always cause a failure. Investigation showed that in some cases, the call to EGL_CreateImageKHR() was not setting all the attributes in the ImageHelper object that is used later for an imageless framebuffer, specifically the one created in VkImageImageSiblingVk::initImpl(). * Added the usage flags and view formats in the new image created in VkImageImageSiblingVk. * Added a Vulkan image test to make sure the error is fixed. Bug: b/261473248 Bug: angleproject:7845 Change-Id: I1874b2930e9ce62e5b603cf7acff6fd78b957d5b Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4117584 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Charlie Lao 26e28089 2023-01-04T15:15:46 Vulkan: Improve RPCommandHelper::isImageWithLayoutTransition() RenderPassCommandBufferHelper::isImageWithLayoutTransition() was added in crrev.com/c/3366014 to detect if there is a barrier inserted for the renderPass. If yes, we have to endRenderPass before compute shader, since compute dispatch goes into outsideRenderPassCommands, which writes into primary command buffer before renderPassCommands. Otherwise the compute dispatch will be using the image before the actual layout transition occurs, which is wrong. But to detect if the image has a layout/barrier transition in the renderPass, it maintains an angle::FlatUnorderedSet. With recent change for per active context queue serial, we can use the queue serial to detect this. This CL adds a queueSerial for image layout/barrier change and compares it with RenderPassCommands' queueSerial to decide if the renderPass has a layout/barrier for the image. This CL also did some minor clean ups: Removed unused API ContextVk::getActiveImages(). Removed writtenByCommandBuffer() check in CommandBufferHelperCommon::bufferWrite() before calling setWriteQueueSerial, since the check is more expensive than set. Added setQueueSerial call in OutsideRenderPassCommandBufferHelper::imageWrite to be consistent with imageRead. (This might be fixing a bug here). Replaces a few retainResource(image) to image->setQueueSerial for consistency. Bug: b/264472911 Change-Id: I74badd6b8a35f86640e42d330a1a709ccfb961c3 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4136948 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao 2662f28f 2022-12-30T17:26:22 Vulkan: Fix imageRead from RP and outsideRP simultaneously When a texture is been sampled from both fragment shader and compute shader, you will have the same VkImageLayout. We will not try to end renderPass, which means you end up running into similar situations with OutsideRenderPassCommandBufferHelper::bufferRead where an image is already read accessed by a started renderPass and now read accessed by an outsideRenderPassCommands. Since renderPass has greater queueSerial, we should not tag it with outsideRenderPassCommands' queueSerial. This CL also adds two tests, one for color texture and another for depth texture (which is car_chase uses). Both exposes the same bug. Bug: angleproject:7916 Change-Id: I840ca8947caeb7a96c4c9ccb7c9eca2476837c9c Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4133548 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Commit-Queue: Charlie Lao <cclao@google.com>
Shahbaz Youssefi 6c41793f 2022-12-20T15:20:50 Vulkan: Use read/write depth/stencil layouts This allows an application to have depth in read-only feedback loop while stencil is being written to for example. Bug: angleproject:7899 Bug: b/192477489 Change-Id: Ic2e11d32da7c7e3a7f3cd86dbafc5c56a0dbbfd7 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4116730 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 295f6830 2022-12-21T10:56:03 Vulkan: bufferRead should accommodate deferred endRenderPass ContextVk::onSyncObjectInit() will request end of current renderPass but deferred (in this case, mRenderPassCommandBuffer is nullptr but mRenderPassCommands->started() still returns true). The next draw call will actually end current renderPass and starts a new renderPass. But if next call is glCopyBufferSubData, it will not actually trigger endRenderPass. This CL modifies OutsideRenderPassCommandBufferHelper::bufferRead logic to accommodate this deferred endRenderPass scenario by checking mRenderPassCommands->started() instead of hasStartedRenderPass so that the answer to "if this buffer been used by current renderPass or not" will return correct result. Bug: angleproject:7903 Change-Id: Ie5c9977ccf083e7d355a2cd8fd08e9077049ee9a Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4119692 Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Shahbaz Youssefi 626b10c1 2022-12-20T20:22:19 Vulkan: Add read/write depth/stencil layouts This CL only adds the layouts in the list, but does not use them. The layouts are renamed for consistency in this change. Bug: angleproject:7899 Bug: b/192477489 Change-Id: I47986c7252d32626e9f26c6670c0a4e3496fe0c8 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4116736 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Charlie Lao <cclao@google.com> Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 301ed545 2022-12-20T20:16:22 Vulkan: Pass context to layout getters In preparation for a change that optionally uses read/write depth/stencil layouts. Context is used to test for the supportsMixedReadWriteDepthStencilLayouts feature to know whether those layouts are supported or that a fallback must be chosen. Bug: angleproject:7899 Bug: b/192477489 Change-Id: I1453dc9d060453a3806ad0f261b94368fe01fb29 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4116735 Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao 5c8c0347 2022-12-15T15:46:38 Vulkan: Remove ContextVk::retainResource and retainImage() Clean up some retain* APIs. retainImge and retainReadOnlyResource and retainResource are doing exact same thing, they are consolidated into just retainResource. ContextVk::retainResource is removed since mUse can now safely copied from DescriptorSetHelperPool object which tracks mUse. Bug: b/262047600 Change-Id: I56ea08696e870826bd94ccb79dd621f35923bc6a Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4114500 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao 376d309c 2022-12-15T09:43:00 Vulkan: Remove unnecessary usesBuffer() check There are places that we call setQueueSerial after usesBuffer() check. This was useful when we had the ResourceList where it is more expensive to set serial. But now setQueueSerial is cheap (actually is cheaper than usesBuffer check), so there is no need to do this check any more. This CL removes the check to further reduce the CPU overhead. Because of this, mUsedBufferCount will not be accurate, so this CL also removes the tracking of mUsedBufferCount (was only for informational purpose anyway). This CL also removes commandBufferQueueSerial.valid() check in Resource::usedByCommandBuffer() and turns it into assertion. Some places in contextVk will ensure we only call it on started renderpass so that other places that calls usedByCommandBuffer will not need to eat the if check. Bug: b/262047600 Change-Id: I6b8004b6aa5b567fa94c0eb56801054f818838b1 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4112145 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao cd367796 2022-12-12T15:10:09 Vulkan: Add assert to ensure never setQueueSerial backwards This CL add an assertion in ResourceUse::SetQueueSerial to ensure that we never set a serial smaller than what it already has. If that happens, we could potentially destroy it while GPU still accessing it. With this assertion, it exposed a bug that when a buffer is read accessed by a renderpassCommands and then read accessed by outsideRenderPassCommands, we were incorrectly setting the queueSerial with outsideRP's serial, overwriting the queueSerial already set by renderPassCommands. To fix this, this CL detects this case and keeps the queueSerial set by renderPassCommands. Bug: b/262047600 Change-Id: I51b17ab4a93bccd0d0b079784af96cef9d79f16f Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4099804 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Shahbaz Youssefi 77c95de4 2022-11-16T21:12:28 Vulkan: Threaded monolithic pipeline creation With this change, once a pipeline is created out of libraries, a task is scheduled (if necessary) to asynchronously create a corresponding monolithic pipeline. Once the task is complete, the linked pipeline handle is replaced by the monolithic one, gaining back any performance that might have been lost due to the use of libraries. Bug: angleproject:7369 Change-Id: I525fb1e09f8bedc61b9dbef19f9cce7026ff9c53 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4031151 Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Charlie Lao 89cd8583 2022-12-12T11:23:59 Vulkan: Clean up Resource class Resource::retainCommands() API name no longer make sense. This CL removes retainCommands and retainReadOnly and retainReadWrite APIs and replaced with setQueueSerial and setWriteQueueSerial call directly. This CL also merges some of single inline functions to minimize the file, sine the class is small anyway. Bug: b/262048658 Change-Id: I9d16b82c79b27f3285311393601705a4ee7f6d8a Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4098005 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Charlie Lao f3ebb2ca 2022-12-08T17:02:12 Vulkan: Better mUse tracking for DynamicallyGrowingPool<Pool> This is used only from DynamicallyGrowingPool<Pool>::onEntryFreed to set the its tracking QueueSerial. There is better way to do this now with per context serial. We can simply merge the QueryHelper's mUse into the pool instead of setting pool's use to the current queueSerial. The benefit of doing that is to possibly allow pool gets reuse/freed earlier (i.e., more accurate tracking). This CL switches it to more accurate tracking and removes mCurrentSerial from Context. This CL also removes unused DynamicSemaphorePool class. Bug: b/262054987 Change-Id: Iac3e2495cc0e3623ba63e9da7f32ad6e9c223467 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4089847 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Amirali Abdolrashidi 684ff60b 2022-06-21T10:52:31 Vulkan: Add shared ring buffer cmd alloc feature * Added RingBufferAllocator.cpp with implementation. * Main classes: * RingBufferAllocator (fast allocation with bulk deallocation) * SharedRingBufferAllocator (wrapper to help with shared use and multiple threads) * Implemented "angle_enable_vulkan_shared_ring_buffer_cmd_alloc" feature. (Disabled by default) * Details (from the original CL) * The angle::PoolAllocator replaced with angle::RingBufferAllocator. * Before, there was separate angle::PoolAllocator per each CommandBufferHelper. Now, a single angle::RingBufferAllocator is shared between multiple CommandBufferHelper objects. * Commands data from multiple CommandBufferHelpers is tightly packed without fragmentation. * Significantly less memory overhead, observed with enabled async queue. * Moved the parts of the code related to the allocators into the classes in the new AllocatorHelperPool and AllocatorHelperRing files for better management. The allocator can be switched by changing the following BUILD flag: `angle_enable_vulkan_shared_ring_buffer_cmd_alloc` * It is connected to the following macro: ANGLE_ENABLE_VULKAN_SHARED_RING_BUFFER_CMD_ALLOC * The two main allocator classes in each file are aliased as: * SecondaryCommandBlockAllocator (in CommandBufferHelper objects) * SecondaryCommandBlockPool (in SecondaryCommandBuffer) * Also added placeholder functions for VulkanSecondaryCommandBuffer. * Added descriptions regarding the two allocators. * renderer/vulkan/doc/Allocators.md Credit: Original CL authored by Igor Nazarov <i.nazarov@samsung.com> Bug: angleproject:6401 Bug: b/256666069 Change-Id: I0f24793eef6334bf4ff8e327b9665338807dad37 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3715968 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Charlie Lao f8980c98 2022-12-08T11:51:42 Vulkan: Make ReadWriteResource subclass from Resource To simplify the code slightly. The main reason for this is that the two class variables of ReadWriteResource totally does not make sense: mReadOnlyUse actually manes any usage, read or write. mReadWriteUse actually means write usage. Since Resource class's mUse means any access, subclass ReadWriteResource from Resource class makes more sense since mUse means exact same thing in both classes. This CL also changes ReadQriteResource::mReadWriteUse to mWriteUse. Bug: b/262048658 Change-Id: I0e3172a70b8cb6a6481045c46690b69fbfe9523c Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4089983 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao 6830b7d3 2022-11-23T11:51:28 Vulkan: Use finishQueueSerial for queueSubmitOneOff Right now for oneoff submission we are creating a fence and pass in the fence and then wait for fence outside the normal wait code path. This creates a problem that the command buffer and garbage clean up code does not gets run and may end up hitting assertion. This might be necessary before because complication with ResourceList. With recent work that removes ResourceList, this can be much simpler now. This CL removes the fence creation and wait in the oneoff submission code path (except the external fence) and switch to finishQueueSerial call. Bug: b/255414841 Change-Id: I2b16c187becbda9c2397685c7212abac994e8dc2 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4053261 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao 1219f55a 2022-12-07T16:19:37 Vulkan: Remove Resource::isCurrentlyInUse Due to header file include order, this function can not directly made inline. This CL removes the function and replace it with renderer->getUnfinishedUse() to reduce one extra function call of one line function. Bug: b/262048658 Change-Id: Ied33b63d0ec88336a5ce42cf7726f16b2b883b86 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4089623 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 02cc4cd5 2022-12-07T12:03:26 Vulkan: Remove ImageHelper::mImageAndViewGarbage This was introduced in crrev.com/c/3449450. At that time this is necessary, because we can not copy mUse for immediate view garbage collection. Now with recent work, mUse is copyable, we no longer need to accumulate the view garbage. They can be released immediately with a copy of image's mUse. Bug: b/261737134 Change-Id: Ic4393f8c4ee7c0e3be4669a0a557507c909a77ab Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4087323 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 1193b664 2022-10-11T01:00:40 Vulkan: Use VK_EXT_pipeline_protected_access This extension allows pipelines to be restricted to protected or unprotected command buffers only. Bug: angleproject:7714 Change-Id: Id07be4c2ffd7ca19b8b4a2a869828bc11e89e467 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3943535 Reviewed-by: Charlie Lao <cclao@google.com> Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Charlie Lao 8181c056 2022-11-22T15:34:48 Vulkan: Remove RenderPassSerial RenderPassSerial was introduced to uniquely identify a RenderPassCommands. With the work of per current context queue serial, now every started RenderPassCommands already have a unique QueueSerial. This CL removes RenderPassSerial and use renderPass's queueSerial instead. Bug: b/255414841 Change-Id: Id0a87319a9132cdb74aba195f1f05aa31454592b Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4049966 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Amirali Abdolrashidi 58d7ace2 2022-11-22T16:08:07 Vulkan: Add memory allocation log support in debug * Added a memory tracker to the renderer object to keep track of the memory allocations and deallocations in more detail. * This feature is used for debugging only. * To enable it, set angle_enable_memory_alloc_logging=true in GN args (added in renderer/vulkan/BUILD). * It is related to ANGLE_ENABLE_MEMORY_ALLOC_LOGGING in the code. * The tracker are updated in the memory allocation tracking functions if the feature is enabled. (The counter is always updated, even if the feature is disabled.) * At the end of a RendererVk object, it checks for and logs any remaining allocated memory from MemoryAllocationType members. * The data is stored in the map object "mMemoryAllocationTracker". The key used for it is currently of type angle::BacktraceInfo. * If angle_enable_unwind_backtrace_support is disabled, or not on Android, the key is an empty object. * MemoryAllocInfoMapKey is used as a key to access the allocation information. Bug: b/242641395 Change-Id: If701a4bdea2f8738a830ee47e0c7c5cdacf95b87 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4050103 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Charlie Lao 2e5ca217 2022-11-18T10:44:49 Vulkan: Let each current context has its own QueueSerial. This CL makes every current context has its own queueSerial. At context creation time or when context becomes current, it allocates a QueueIndex from renderer. When it becomes non-current, it releases QueueIndex for others to reuse. This way we significantly reduces the max number of QueueIndexs for reasonable usage. Each CommandBuffer has its own unique QueueSerial and we use that to determine if a resource is being used by the given CommandBuffer. The QueueSerial for RenderPassCommands is deferred until renderPass starts, and when we generate queueSerial for renderPassCommands, we also reserve a range of serials for outsideRenderPassCommands so that we can do incremental submission of outsideRenderPassCommands without need to close renderPassCommands. In rare situation, if that reserved serials runs out, we also close renderPassCommands to ensure the ordering of serials matches ordering of command buffers. With per current context queue serial, this CL is able to set resource queue serial as it is being used. This CL completely removes usage of ResourceUseList class since it was introduced due to deferred setSerial. This CL also get rid of refCount from ResourceUse since there we no longer add it to a ResourceUseList. With that, we also able to remove SharedResourceUse class since access to ResourceUse itself is now thread safe since we are able to make a copy of it when we add it to GarbageList. Because RenderPassCommands now has its own unique QueueSerial as it encodes command, we can use it to detect if a resource is being used by it or not, thus this CL also removes usage of CommandBufferID. Bug: b/255414841 Change-Id: I36dcbeaa7bc996f04e6c04bf9ad44cd0d630f61a Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4038096 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao 7dd8478e 2022-11-17T10:11:02 Vulkan: Make ResourceUse::serial an FastVector of Serials In preparation for per context queue serial, this CL makes ResourceUse::serial a FastVector of Serial. Right now we still limited to one serial index so that it still work the same way as before. This CL adds necessary data type and change the function names to reflect that tracking GPU progress needs a ResourceUse object instead of a single Serial number. Bug: b/255414841 Change-Id: Ic60cdf5ec8da45d1821f65a55947f5c553f65737 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4034548 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Amirali Abdolrashidi b2f55ec3 2022-11-14T16:07:19 Vulkan: Add memory allocation/deallocation counter * Added a counter to the renderer object to keep track of the memory allocations and deallocations per allocation type. * The counters are updated with the functions onMemoryAlloc() and onMemoryDealloc(), which can be added next to the allocation or deallocation point. * Currently used for buffer memory and image memory. * Removed some of the redundant arguments from vk_helper and suballocation functions. Bug: b/242641395 Change-Id: I58b38f619df7bef0ba5fa3373a8db5aed0ef142c Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4014164 Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 8378032e 2022-11-15T11:47:55 Vulkan: Remove get API for mLastCompletedQueueSerial In preparation for per context queue serial, this CL makes mLastSubmittedQueueSerial and mLastCompletedQueueSerial private to CommandQueue. Before this CL, we have a get function to return the last submitted serial and last completed serial and passing these serials around. This works because the serial is a single uint64_t number. With per context queue serial, this will be an array of serials and there is potential risk associated with access it from different threads. This CL makes these serials private to CommandQueue and when you want to know if GPU is completed with resource, you ask RendererVk/CommandQueue directly. This way we can ensure they have thread safe access in the CommandQueue (no lock is necessary, but all access will be restricted to one class). Bug: b/255414841 Change-Id: Ica565decce4a80588e0b447e179a2b634b55d7c3 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4021676 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao 71d28a9b 2022-11-02T13:19:20 Vulkan: Remove unused ShaderAndSerial The serial in the ShaderAndSerial is unused. This CL removed ShaderAndSerial and replaced with ShaderModule directly. Bug: b/257116399 Change-Id: I50d42af7818a12888309a80423531d75135e0bfd Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3998747 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi adde4265 2022-10-19T23:33:48 Vulkan: Separate pipeline cache query and insertion In preparation for VK_EXT_graphics_pipeline_library usage, the query and insertion functions of the graphics pipeline cache are separated. This will allow the implementation using VK_EXT_graphics_pipeline_library to query the monolithic pipeline cache, and if a pipeline is not found, create it through the pipeline library caches. Bug: angleproject:7369 Change-Id: Iebf7669ae3ea95e180646198c4861cc59d67e580 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3963854 Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Sungyong Choi c6390143 2022-10-12T09:57:55 Vulkan: Make compatible with GCC Resolves below warnings occurred with GCC build. 1) deperecated-copy Overriding an assignment operator without a copy constructor caused the deprecated-copy warnings. 2) unused-function 3) parenthesis Warnings occurred due to missing parenthesis around some logical expressions, add them to quiet the warnings. 4) unused variable 5) 'maybe-unused' attribute ignored Introduces 'ANGLE_MAYBE_UNUSED_PRIVATE_FIELD' macro to avoid 'attribute ignored' warning which is only occurred with GCC because GCC doesn't warn about 'unused non static data member' whereas Clang has Wno-unused-private-field. Signed-off-by: Sungyong Choi <sywow.choi@samsung.com> Bug: angleproject:7764 Change-Id: I8e7410a5ed8cb9b8f8b3202073d779fea63d6b75 Reviewed-by: Jeff Vigil <j.vigil@samsung.com> Reviewed-by: Mohan Maiya <m.maiya@samsung.com> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3963830 Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 025504b9 2022-10-17T17:03:03 Pass worker pools to image load functions In preparation for the ASTC decoder using threaded decoding. Bug: b/250688943 Change-Id: I70d669bcb57b900dbb633304182e174aec362203 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3961339 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Greg Schlomoff <gregschlom@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi fbd7d5fa 2022-10-17T17:20:09 Move thread pool classes to common/ In preparation for access by image_util files. Bug: b/250688943 Change-Id: I24777269a5071eae9a60f939635d01ed7246461f Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3961454 Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi b521be4c 2022-10-14T23:09:26 Vulkan: Decouple shader-set from pipeline caches In preparation for VK_EXT_graphics_pipeline_library, where different pipeline caches (for the complete pipelines and the shaders subset partial pipelines) may create pipelines from the same shader set, the pipeline caches are pulled out of ShaderProgramHelper. In an upcoming change, ProgramExecutableVk will have more than one GraphicsPipelineCache instance, both creating pipelines through the same ShaderProgramHelper. The pipeline creation methods in ShaderProgramHelper are now const. This means a thread would be able to create pipelines using an object of this class while the main thread creates other pipelines using the same object, but in a different pipeline cache. Bug: angleproject:7369 Change-Id: Ib8a76dedf1105ba9dfcad9e972157c92ba18e349 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3956944 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 1119dfbd 2022-10-03T16:47:29 Vulkan: disable supportsHostQueryReset feature if func is null This is try to clean up a old fix for chromium security bug chromium:1273344 that in some bots we are seeing supportsHostQueryReset feature enabled but vkResetQueryPoolEXT pointer is null. We fixed that in crrev.com/c/3313382 that added a check of vkResetQueryPoolEXT AND supportsHostQueryReset feature flag. This CL disables the feature flag if vkResetQueryPoolEXT pointer is null so that other places we only need to check feature flag. Bug: b/250706693 Change-Id: I2d9f9726f081e21a37bbb0bb205003c390f2d32c Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3929236 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Ian Elliott <ianelliott@google.com>
Shahbaz Youssefi 135022e4 2022-10-11T00:03:11 Vulkan: Create robust pipelines based on context state Previously, pipelines were made robust based on whether any context in the share group has so far been made robust. This means that pipelines created on non-robust contexts would still be compiled as robust. Inefficiency aside, this was buggy because robustness was not part of the pipeline cache key, so if a pipeline was created as non-robust first, then recreated in a robust context, it would reuse the non-robust variant. With VK_EXT_pipeline_protected_access, a similar situation arises for context protected-ness. However, it is incorrect in that case to create pipelines as protected unnecessarily. This change makes pipeline robustness a part of the pipeline cache key, in preparation for protectedness to be added similarly. Compute programs may now generate multiple pipelines as a result too. Bug: angleproject:7629 Change-Id: Ie95f10eff878f8c8b221c1018da44385c7aad15e Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3943534 Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com>
Amirali Abdolrashidi c19ec948 2022-08-23T10:43:59 Vulkan: Implement imageless framebuffers * Added the attachment image and create info objects to be used for imageless framebuffers created in getFramebuffer(). * New helper class for framebuffers in RenderPassCommandBufferHelper: MaybeImagelessFramebuffer, which includes a framebuffer object, if the framebuffer is imageless, and the image views. This is to make sure that the args for render pass begin info will be correctly set up according to the status of the used framebuffer. * Refactored the collection of attachments in getFramebuffer() into a new function, getAttachmentsAndImagesFromRenderTargets(). It also returns their corresponding ImageHelper* objects used to create the framebuffer (from their image properties). * New struct: RenderTargetInfo; which keeps track of render targets and whether resolve image should be used for the render pass in the form of the enum class RenderTargetImage. * Added a new arg to getFramebuffer(): resolveRenderTargetIn; to use when there is a valid resolveImageViewIn. * Without using the framebuffer cache, we would require to handle the framebuffer destruction by adding it to the garbage instead of releasing it. For example, FramebufferVk::destroy() now adds mCurrentFramebuffer to the garbage. * Added new framebuffer unit tests. * Added tests where two textures with different attributes are bound to the same framebuffer before drawing, one after another. * Added test where a blit occurs from a multisample texture into a non-zero level of a resolve texture, each bound to a separate FBO. * Added a new perf test to compare performance for enabled imageless framebuffers vs disabled. (Credit: cclao) Bug: angleproject:7553 Change-Id: Iacdbd73aaa01cbb0e37abf01ae4892bdfdd4b12f Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3827644 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com> Reviewed-by: Charlie Lao <cclao@google.com>
Shahbaz Youssefi 13195f8a 2022-10-05T11:17:35 Vulkan: Fix missing input attachment usage on MSRTT When combined with advanced blend (or framebuffer fetch for that matter), MSRTT attachments could be used as input attachments. This change fixes the missing usage bit. Bug: angleproject:7739 Change-Id: I2190e4a6e534e120357dd68189fb9de07b6c54fa Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3936444 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Shahbaz Youssefi 7d10d160 2022-09-29T23:31:40 Vulkan: Fix VK_EXT_pipeline_robustness vs compute Robustness was not specified for compute. Bug: angleproject:5845 Change-Id: I3f3b1e90cc4e965ff4cfcd569587caa952e5eaa2 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3924871 Reviewed-by: Alexis Hétu <sugoi@chromium.org> Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 1d73bad5 2022-10-01T22:50:48 Vulkan: Fix reclear of rendered-to depth/stencil An optimization drops re-clears of images to the same value. When a render pass does: - clear - render - store the "cleared" status of the image was removed because at the end of the render pass, the image no longer has the cleared value. However, this was mistakenly only done for color, but should have been done for depth and stencil as well. Bug: b/239430388 Change-Id: Ib99e0df460eaa82ce87b593276abd9b07f0a8375 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3931972 Reviewed-by: Cody Northrop <cnorthrop@google.com> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Hailin Zhang 836cc5e2 2022-09-09T22:06:22 Vulkan: add etc to bc compute transcoding. use compute shader to transcode etc format to bc format. Bug: b/243398683 Change-Id: Idbd0820a2df8d92fe690055dae2933bc559e9bfd Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3888501 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Hailin Zhang <hailinzhang@google.com>
Amirali Abdolrashidi b9cd542e 2022-09-15T17:31:35 Vulkan: Use serial to check which FBO has open RP In preparation for the scenario where an imageless framebuffer is shared, checking whether the started render pass belongs to a certain framebuffer is tweaked to use a serial-based method instead of checking the framebuffer handle. * Added the last render pass serial to ContextVk, which increments every time a render pass begins. The serial is also stored in the FramebufferVk object invoking it. * Added the type RenderPassSerial for this purpose. * Serials are generated through a serial factory in ContextVk. * Updated hasStartedRenderPassWithSerial() to match the serials instead of the handles. * Removed the getFramebuffer() calls from FramebufferVk and UtilsVk that are now unused. Bug: angleproject:7553 Change-Id: Id60dcbf7973558d35e55ff4af4c71e50c6853bba Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3897970 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Antonio Caggiano a8a04ce1 2022-08-16T17:59:20 Vulkan: Add supportsPresentation feature Some platforms do not support presentation through any Vulkan queue. In this case we should not transition the color image layout to present. Bug: angleproject:7217 Change-Id: I71cad0e52bc1fdb531de5a34e917a1862a4cf070 Signed-off-by: Antonio Caggiano <antonio.caggiano@collabora.com> Suggested-by: Sungyong Choi <sywow.choi@samsung.com> Suggested-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3853598 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 18f90857 2022-09-09T11:28:00 Vulkan: Use DontCare if attachment is invalidated If an attachment is invalidated, there is no need to preserve the old content. NONE means old content is still preserved, DontCare means discard old content. In this case we do want to discard instead of preserve old content. Bug: b/243711628 Change-Id: I242ac86db6993574b5627d61f7185d155beec0ba Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3888938 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Auto-Submit: Charlie Lao <cclao@google.com> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Mohan Maiya a2f00721 2022-06-19T15:17:22 Vulkan: Extend bounding box when pruning updates Add support for extending the bounding box when there are updates that enclose the current bounding box. Bug: angleproject:4691 Bug: angleproject:7389 Test: Texture2DArrayTestES3.TextureArrayPruneSupersededUpdates* Change-Id: Ie7e3cc28f17213361b1be407dbb2d984865fe6bd Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3712897 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: mohan maiya <m.maiya@samsung.com>
Ian Elliott 9aeb6311 2022-08-29T10:50:01 Revert "Extra buffer logging/checking on Android Cuttlefish" This reverts commit 5cb05e0482ed1a2c4048f76c1a7fd444849410d8. The root cause was found, and this extra logging/checking is no longer needed. Bug: b/236098131 Bug: b/245339714 Change-Id: Ibefbeec30be974788789650f2dc86696a6eba11a Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3862408 Auto-Submit: Ian Elliott <ianelliott@google.com> Reviewed-by: Jason Macnak <natsu@google.com> Commit-Queue: Jason Macnak <natsu@google.com>
Charlie Lao d9f5b2f8 2022-08-31T13:00:00 Vulkan: Dont skip texture upload if only color space differs sRGB color space does not affect actual data storage, it only affects Image data interpretation. We should still allow data copy if the only format difference is sRGB bit. Bug: b/205995945 Change-Id: Id72b9aae626ee0d1863cde17388f1c1e82f321f8 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3864050 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Hailin Zhang 553b1334 2022-07-28T23:33:28 Vulkan: fix default msaa framebuffer resolve issue. Bug: b/239217726 Change-Id: I826aad7495814e0a178a586c4cfd5943278cddac Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3793304 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Charlie Lao dc77621b 2022-07-29T16:46:40 Vulkan: Fix RefCountedDescriptorPoolHelper leak DynamicDescriptorPool::mDescriptorPools really owns the pool, make it std::unique_ptr instead of plain c++ pointer to automatic handle object destruction. Bug: chromium:1346946 Change-Id: Iec2fff920d624cd983d314086cc08832c6c61984 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3795008 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao 5db09e9b 2022-07-21T10:45:12 Vulkan: Try allocate from existing DescriptorPool before create new When we allocate a new descriptorSet, right now we only look at current bound pool or the last pool, or allocate a new pool. We never look at the other pools for the possibility of allocation. This is likely due to we never free descriptorSet in the past. With the recent CLs, we now release invalid descriptorSets when texture or buffer gets deleted or re-specified. This opens up opportunity to allocate from other existing pools before allocating a new pool. This CL changes the allocation logic to add the pass to iterate over existing pools for allocation before allocating a new pool, thus reducing the number of descriptorSetPools. This CL also consolidates DynamicDescriptorPool::getOrAllocateDescriptorSet()'s actual descriptorSet allocation logic with DynamicDescriptorPool::allocateDescriptorSet(). This CL also moves mEmptyDescriptorSets from ProgramExecutableVk to DynamicDescriptorPool so that we will only have one empty descriporSet per pool instead of per program. Bug: b/235523746 Change-Id: I012346acce17f785ee6683ec55fdf21be00ea1a0 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3780847 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Charlie Lao <cclao@google.com> Auto-Submit: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi be708446 2022-07-25T15:24:52 Vulkan: Remove the bindEmptyForUnusedDescriptorSets workaround Only applied to older Qualcomm-based phones. Bug: angleproject:2727 Change-Id: I37a611e2ff79d898eff9401467407543f3c690b8 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3785290 Reviewed-by: Charlie Lao <cclao@google.com> Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Yuxin Hu <yuxinhu@google.com>
Charlie Lao 00e48c13 2022-07-20T17:35:01 Vulkan: Destroy DescriptorPoolHelper when its unused. DynamicDescriptorPool keeps an array of DescriptorPoolHelpers. Right now we only grow this array of pools, we never shrink the pool count. This is partly due to we never release descriptorSet. But in the past few CLs, we now release invalid descriptorSet when texture/buffer gets deleted or re-specified. This means we could now have a pool with no valid descriptorSets. This CL adds the ability to actually release the pool when all of its descriptorSets has been released, thus reduce the pool count when a lot of textures have been deleted. Bug: b/235523746 Change-Id: I2d5047269154cc8ece8305408f08f2ad7c9dd8a6 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3780845 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Lingfeng Yang 6c418f8c 2022-07-07T14:28:06 Vulkan: __samplerExternal2DY2YEXT-aware TextureVk This CL adds the ability for TextureVk to return an ImageView that is created with a VkSamplerYcbcrConversion object that uses an identity conversion model. This allows direct sampling of YUV values without RGB conversion, which is needed for __samplerExternal2DY2YEXT. Bug: b/223456677 Change-Id: Ie1d4e12375b7808a1f060747bc2d74baeda3fdea Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3751889 Commit-Queue: Lingfeng Yang <lfy@google.com> Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
kmx.io     mail     discord kmxgit v0.4.0