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

src/libANGLE/renderer/vulkan/BufferVk.cpp

Log

Author Commit Date CI Message
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>
Shahbaz Youssefi 25e60197 2023-03-31T14:17:26 Vulkan: Unify buffer alloc strategy for uploads and GPU copies With this change, glCopyBufferSubData uses the same buffer allocation strategy as glBufferSubData. Only exception is with buffer self-copies which never allocate a new buffer for simplicity. Additionally, this change allows glCopyBufferSubData to be done on the CPU if possible, i.e. if the source buffer is not being written to by the GPU and whenever the equivalent glBufferSubData would have used a CPU upload. Bug: b/276002151 Change-Id: Ice8df5891c5516b148245d5d6fa9b19b787df4ce Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4390023 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 552d4271 2023-03-31T10:59:30 Vulkan: Refactor buffer init logic Bug: b/276002151 Change-Id: I28d3fa34ab11340cc8b38743e87664a514870068 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4388547 Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Charlie Lao f4e71351 2023-03-14T14:55:04 Vulkan: Switch acquireAndUpdate to use Buddy pool Based on survey of all app traces we have, it is common that we end up with BufferVk::acquireAndUpdate even though the buffer was created with STATIC usage. This is mostly due to glBufferSubData call on the STATIC usage buffers and on ARM we most likely end up with acquireAndUpdate. Similarly, we also getting into ghostMappedBuffer and mapRangeImpl with STATIC usage buffers, even though with less app traces. Since the usage pattern usually repeats, using generic allocation algorithm has performance penalty. This CL moves these usage to buddy algorithm to ensure alloc/free are fast. This CL and previous CL crrev.com/c/4327290, reduces efootball_pes-2021 frame time from 4.2 ms to 2.87 ms, achieves parity with native GLES on pixel 7 pro. Bug: b/271915956 Change-Id: I56e0195181c77a3130513c74ec8a5075b2b29ea4 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4321870 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Charlie Lao 4982b903 2023-03-14T19:56:51 Revert "Vulkan: Remove inUseAndRespecifiedWithoutData from BufferVk" This reverts commit 755bfe471d23bc2aac5e78493537801dc5f90792. Reason for revert: Causing flaky on pixel 6 angleproject:8082 Original change's description: > Vulkan: Remove inUseAndRespecifiedWithoutData from BufferVk > > BufferVk::setDataWithMemoryType() has one optimization that it tries to > detect glBufferData(target, size, nullptr, usage) and if existing > storage is busy, it immediately reallocate storage. With the > optimization in previous CL (crrev.com/c/4317488), the storage reuse > logic should detect if we can reuse the storage or not. If the size > matches the existing storage's size, then there is no reason we can not > reuse existing storage. Later on when glBufferSubData or > glMapBufferRange is called, there are optimization in those calls that > will detect if we should reallocate storage or not as the further > optimization. This CL removes this check and replies on the other > optimization to handle the storage reallocate (shadowing) if necessary. > This simplifies code and also potentially avoids storage reallocation in > certain usage cases. > > This CL also fixes a test bug in > BufferDataTestES3.BufferDataWithNullFollowedByMap that was calling > glMapBufferRange with MAP_UNSYNCHRONIZED_BIT but incorrectly expecting > GL to do synchronization. > > Bug: b/271915956 > Change-Id: I7901687b3e3e262e77699f14eb8602d8a57eda3e > Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4322048 > Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> > Commit-Queue: Charlie Lao <cclao@google.com> > Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Bug: b/271915956 Change-Id: Ie5716b609ab96b96afbe5927f20dfcf2bf5d4db6 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4338263 Auto-Submit: Charlie Lao <cclao@google.com> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Charlie Lao 755bfe47 2023-03-08T14:31:33 Vulkan: Remove inUseAndRespecifiedWithoutData from BufferVk BufferVk::setDataWithMemoryType() has one optimization that it tries to detect glBufferData(target, size, nullptr, usage) and if existing storage is busy, it immediately reallocate storage. With the optimization in previous CL (crrev.com/c/4317488), the storage reuse logic should detect if we can reuse the storage or not. If the size matches the existing storage's size, then there is no reason we can not reuse existing storage. Later on when glBufferSubData or glMapBufferRange is called, there are optimization in those calls that will detect if we should reallocate storage or not as the further optimization. This CL removes this check and replies on the other optimization to handle the storage reallocate (shadowing) if necessary. This simplifies code and also potentially avoids storage reallocation in certain usage cases. This CL also fixes a test bug in BufferDataTestES3.BufferDataWithNullFollowedByMap that was calling glMapBufferRange with MAP_UNSYNCHRONIZED_BIT but incorrectly expecting GL to do synchronization. Bug: b/271915956 Change-Id: I7901687b3e3e262e77699f14eb8602d8a57eda3e Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4322048 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com> 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>
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>
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>
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 798b97b8 2022-12-07T15:37:51 Vulkan: mapRangeImpl should call flushImpl if unflushed write BufferVk::mapRangeImpl() want to ensure any GPU write command has been flushed and finished. Right now it calls flushImpl if there is any unflushed access. It should only need to flush if there is any unflushed *write* command. This CL changes check of any access to any write access. This CL also inlines isCurrentlyInUseForWrite/finishGPUWriteCommands and removed these two single line function calls. Bug: b/261772793 Change-Id: I1628ec31eaceb87f82e654cb1f317570ff2f6c12 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4086972 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Charlie Lao <cclao@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 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>
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 2c351351 2022-08-07T22:31:40 Vulkan: Don't break render pass on read-only buffer updates When uploading to a buffer that is in use by the GPU, we either acquire a new buffer and copy the contents over, or stage the update and do a GPU copy. Ignoring all other conditions, this decision was made based on whether a small or large part of the buffer is being updated; small updates where staged. However, if the current render pass uses the buffer in read-only mode, the staged update would break it (to apply the update). In this change, this situation is detected and the acquire-and-update path is chosen even for small updates. Bug: angleproject:7534 Change-Id: Ie2c0989449dcc7d03695a003cf6f353920f8fb65 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3812566 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 80022b96 2022-07-26T21:07:04 Vulkan: Fix xfb buffer redefine to smaller size In 89e11878b275b15735eaf273ababfa6fd43a2e3d, a use-after-free bug was fixed where glBufferData redefined a buffer, leading to a change in storage. This was only tested for the case where the new buffer was larger than the old buffer. When the new buffer is smaller however, another issue remains where the buffer size as cached by the transform feedback object used the old object's size. This is worked around in this change, with a fix for the real issue (that the buffer state is updated after calling into the backend instead of before) coming up. Bug: chromium:1345042 Change-Id: I6c9e9344705fefe49926a14cf6ce73ce84305872 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3788308 Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com> Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Charlie Lao 53d40aed 2022-07-15T15:03:25 Vulkan: Destroy descriptorSet cache when BufferHelper destroyed For atomic counter buffers or other cases, dynamic descriptor is not been used. Right now when such buffer is destroyed, the cache is still lingers around. With this CL, when a new cache entry has been created, we record the cache entry in the BufferHelper. When BufferHelper is destroyed, we also immediately destroy the cache entry since the cache will no longer reused. Bug: b/237686097 Change-Id: I26eee96318fbc003e65318c0b8263dc61092f350 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3764044 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Geoff Lang 31c13df5 2022-05-30T15:06:26 Revert "Initialize buffer contents separately from BufferImpl::setData" This reverts commit 34cff1a14b635c76a9063b8710e948d04ef98a79. Reason for revert: Speculative revert for Mac M1 WebGL failures. Bug: chromium:1330314 Original change's description: > Initialize buffer contents separately from BufferImpl::setData > > Some backends can initialize buffer data faster than allocating a > zero-filled scratch buffer (GL can map and memset for example). > Allow those backends the opportunity to make these optimizations. > > Verified that GL, D3D and VK backends do not regress by using a > separate set data call. > > Bug: chromium:983167 > Change-Id: Ibcbe6016059434dc36ab3c754df6a24f0a6e5e72 > Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3039778 > Reviewed-by: Jamie Madill <jmadill@chromium.org> > Reviewed-by: Peng Huang <penghuang@chromium.org> > Commit-Queue: Geoff Lang <geofflang@chromium.org> Bug: chromium:983167 Change-Id: Id1bfa76b832c35fd0b3ade04da16735aa089fdd2 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3677335 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Peng Huang <penghuang@chromium.org>
Geoff Lang 34cff1a1 2021-07-19T14:29:35 Initialize buffer contents separately from BufferImpl::setData Some backends can initialize buffer data faster than allocating a zero-filled scratch buffer (GL can map and memset for example). Allow those backends the opportunity to make these optimizations. Verified that GL, D3D and VK backends do not regress by using a separate set data call. Bug: chromium:983167 Change-Id: Ibcbe6016059434dc36ab3c754df6a24f0a6e5e72 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3039778 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Peng Huang <penghuang@chromium.org> Commit-Queue: Geoff Lang <geofflang@chromium.org>
Charlie Lao ff011779 2022-05-13T12:36:24 Vulkan: Let texture buffer handle BufferVk's storage change When buffer's storage changed due to glBufferData call, texture buffer code should also respond to this and update the texture descriptor set. This CL merges BufferVkStorageChanged message into InternalMemoryAllocationChanged and removed BufferVkStorageChanged all together. Bug: angleproject:7283 Change-Id: I230ee7268634e747d06eab1954f5a76ecf84c9d6 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3646955 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: mohan maiya <m.maiya@samsung.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 6b9c5c8d 2022-04-22T11:06:16 Vulkan: Improve GetStorageMemoryType logic This is follow up from previous CL. For discrete GPU (preferDeviceLocalMemoryHostVisible is disabled), we will get HostVisible memory if any map can be created on it. For non discrete GPU, this CL also adds the check if the buffer will never gets updated, we just use DeviceLocal memory without HostVisible bit. Bug: angleproject:7047 Change-Id: I73bdc133badbf01c098db23563b30898d4d16a41 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3602943 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao 3b38b379 2022-04-20T10:44:24 Vulkan: Add feature avoid HOST_VISIBLE and DEVICE_LOCAL combination Discrete GPUs device local memory usually is not CPU accessible. This adds a feature flag to control that. Fixed bug in BufferVk that when mapRangeImpl is called from angle internal, unmapImpl was using front end mapping parameters that is incorrect. We have to cache the mapping parameters in the backend to hangle the mapRangeImpl/unmapImpl calls from internal. Fixed the test bug in ComputeShaderTest.BufferImageBufferMapWrite that we are calling glMapBufferRange with GL_MAP_READ_BIT but are actually writing to the map pointer. This should result in undefined behavior per spec. Fixed the test bug in GLSLTest.* that VerifyBuffer calls glMapBufferRange, but was giving incorrect length which result in data only been partially copied. This bug was hidden due to previously all buffers are CPU accessible and there is no copy needed. Fixed the test bug in ReadPixelsPBOTest.* and ReadPixelsPBONVTest.* that calls glMapBufferRangeEXT, but was giving incorrect length which result in data only been partially copied. This bug was hidden due to previously all buffers are CPU accessible and there is no copy needed. Added new skipped syncval messages. Because this CL triggers a copyToBuffer call for some of the buffers and that changes the syncval message signature for the same reasons (i.e, feedback loop or synval does not know the exact range of buffer been used for vertex buffers etc). Bug: angleproject:7047 Change-Id: I28c96ae0f23db8e5b51af8259e5b97e12e8b91f2 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3597711 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao d3dbaa8d 2022-04-19T10:45:57 Vulkan: Remove BufferVk::mHasBeenReferencedByGPU This variable was added before due to we used to only track GPU progress on the entire buffer instead of suballocation. Now each suballocation tracks its own GPU progress, so this is no longer needed. Bug: b/201826021 Change-Id: I2c2b1744b624e028fd905f0752a4264327620515 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3594620 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Charlie Lao <cclao@google.com>
Mohan Maiya 37cdf93d 2022-04-15T12:49:09 Vulkan: Acquire a new buffer even when size is unchanged If a buffer is respecified using glBufferData with no changes to size but client data pointer is null, we need to acquire a new BufferHelper to avoid affecting the results of previously submitted draws. Test: BufferDataTestES3.BufferDataWithNullFollowedByMap*Vulkan Bug: angleproject:7211 Change-Id: Icc20fe3509f94098c7a15988a9ebc888b06fd3c8 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3588955 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: mohan maiya <m.maiya@samsung.com>
Amirali Abdolrashidi bdb52cb8 2022-04-08T13:20:54 Vulkan: Remove retains before acquireBufferHelper * Removed the retainReadOnly() functions in BufferVk, since the BufferHelper object is now moved to a temporary buffer and retaining it is no longer necessary. Bug: angleproject:7103 Change-Id: Id5da88d7cfa4d7a8532eb596f552c70a9ff1d358 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3579862 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Charlie Lao fe28a429 2022-03-30T15:34:49 Vulkan: Create buffer for vertex array if robust enabled If robust access is enabled (i.e., chrome), we want to ensure vulkan driver never access beyond that OpenGL buffer boundary. But with suballocation from BufferPool, we are using the same VkBuffer for all suballocations from the same BufferBlock. this combined with the fact that there is no size information in the vkCmdBindVertexBuffers, it means vulkan driver can not properly ensure vertex access not go beyond the subrange. It can only guarantee not access beyond the entire VkBuffer size. This CL creates a dedicated vkBuffer object and bind it to the suballocation of the vkDeviceMemory so that vulkan driver will see the exact range of the subrange instead of entire buffer. Since we may allocated more memory than actual requested size and the extra paddings are not zero filled , user size is used to create this vkBuffer. This is only enabled when robust access is enabled. This CL also ported webgl conformance test out-of-bounds-index-buffers.html and out-of-bounds-array-buffers.html to end2end test. Bug: chromium:1310038 Change-Id: I3499ae600028149b1039082e5011232b3e4e5e80 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3553940 Reviewed-by: Yuxin Hu <yuxinhu@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao 527ceb73 2022-02-07T18:25:02 Vulkan: Switch XFB counter buffer to suballocation Bug: b/205337962 Change-Id: I2e26fa3ab150b858f07665459fa108440af988d5 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3402333 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Ian Elliott <ianelliott@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao 419bca3f 2022-01-19T18:22:56 Vulkan: Use Vulkan API directly for BufferPool's buffer allocation There are two motivations in this CL. 1) There are two layers of suballocator right now. BufferPool provides first suballocation. It tries to allocate from one of the buffers in the pool. If that failed, it try to create a new BufferBlock (i.e, a VkBuffer). Right now that calls into VMA which creates another pool to allocate a buffer. We really only need one layer of suballocation. And 2) Because we uses VMA to do actual VkBuffer allocation, we have to use Allocator object. But VMA can not handle external buffers, so we end up having a BufferMemory class just to handle two different cases. This CL attempts to clean up this by let ANGLE calling into vulkan driver directly for the actual buffer allocation, just like we did for VkImages. By doing so, we able to remove BufferHelper::mMemory data member as well as BufferMemory class all together. External memory is now treated exactly the same at BufferHelper. Bug: b/205337962 Change-Id: I7c183ab0fd7d9aceb6cf416b0214c300798bc010 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3402740 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao d2354968 2022-01-20T10:59:05 Vulkan: Rename BufferHelper::initFor* to allocateFor* Simply name change per feedback from other CL's review. Bug: b/205337962 Change-Id: Ieb53ed9a2922d09716a1219eb340fe273e5f1807 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3402882 Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao 1b5efe51 2022-01-19T14:04:35 Vulkan: Rename SubAllocation to Suballocation Simply a name change to make it one word. No functional change is expected. Bug: b/205337962 Change-Id: Ic505536821f18141c0d036b13d9aa81554a8bafd Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3403158 Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao 15439f8e 2022-01-13T14:58:41 Vulkan: Remove BufferMemoryAllocator This class was added in crrev.com/c/3036256. The original intention was to use VMA to implement buffer suballocation. Because VMA itself does not support buffer suballocation, I was thinking to use VMA custom pool to implement it and this class was intended to wrap all these functionality into one class. But now thanks to Jamie's effort, VMA exported generic suballocation algorithm via API and we have implemented buffer suballocation using that virtual allocation API. So this BufferMemoryAllocator class is really no longer useful. This CL mostly reverted that CL and flatten out the buffer allocation call to directly use VMA's Allocator object. Bug: b/205337962 Change-Id: I0336056e440f39e2ff49fee8e0ff4b1f355cefe4 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3244022 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Shahbaz Youssefi acd8fc76 2021-12-16T01:05:02 Vulkan: Distinguish RP and outside-RP command buffer types What goes inside and outside a render pass command buffer is largely mutually exclusive. Moreover, the size and frequency of allocations is different between the two. This change distinguishes the C++ types used for inside and outside render pass command buffers: - The type now documents which command buffer a function is able to receive. - `isRenderPass` flag passing, checking and asserting is largely removed. - A follow up change experiments with using different (Vulkan vs ANGLE) secondary command buffers for inside and outside RP command buffers. - A future change could specialize the pool behaviors per command buffer type. Bug: angleproject:6811 Change-Id: Ia4bc669d26ac7e94e8a0dfb9b361666c82f42cc3 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3344373 Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 60a8b593 2022-01-05T11:06:16 Vulkan: Remove std::unique_ptr usage from BufferVk::mBuffer BufferVk::mBuffer is std::unique_ptr mostly because BufferHelper object itself does not support move assignment. Now crrev.com/c/3366855 added move assignment support, we can now use BufferHelper directly. The main downside I can see is that in BufferVk::ghostMappedBuffer() and BufferVk::acquireAndUpdate() functions where we have to use move assignment of mBuffer object, it becomes slightly more expensive than moving pointer. But switch to using BufferHelper directly makes code simpler and other access to mBuffer (which is more common usage) slightly cheaper by removing one pointer indirection. Bug: b/208323792 Change-Id: Ia7e7731e284eb6c76db954fef194e9d1de82174b Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3362252 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao ad27d5d6 2021-12-21T11:22:30 Reland "Vulkan: Consolidate all vertex conversion buffers to shared pool" This is a reland of cca412cd8b349b7281727c50f2a59d115fd90a05 Further inspection shows it was red-herring. The original CL does not have the un-intended diff that I saw in the commit email. This is try to reland the original CL without any modification. Original change's description: > Vulkan: Consolidate all vertex conversion buffers to shared pool > > There are various conversion buffers that holds converted vertex or > element or index data. They are DynamicBuffer for now. This CL switches > them to use the shared group buffer pool. With this change, all > allocation is represented by a BufferHelper object instead of an offset. > I am able to remove the offset arguments from a lot of APIs. > > Bug: b/208323792 > Change-Id: Ib611beb0c16cddbdd9ddf7b8961c439da9fa5180 > Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3352489 > Reviewed-by: Tim Van Patten <timvp@google.com> > Reviewed-by: Jamie Madill <jmadill@chromium.org> > Commit-Queue: Charlie Lao <cclao@google.com> Bug: b/208323792 Change-Id: I90852ad38c2b9ac423800bb6854757bcc17cd166 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3370602 Reviewed-by: Tim Van Patten <timvp@google.com> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao 4e85bdd9 2022-01-06T17:06:25 Revert "Vulkan: Consolidate all vertex conversion buffers to shared pool" This reverts commit cca412cd8b349b7281727c50f2a59d115fd90a05. Reason for revert: There is accidental code merge bug left in. Original change's description: > Vulkan: Consolidate all vertex conversion buffers to shared pool > > There are various conversion buffers that holds converted vertex or > element or index data. They are DynamicBuffer for now. This CL switches > them to use the shared group buffer pool. With this change, all > allocation is represented by a BufferHelper object instead of an offset. > I am able to remove the offset arguments from a lot of APIs. > > Bug: b/208323792 > Change-Id: Ib611beb0c16cddbdd9ddf7b8961c439da9fa5180 > Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3352489 > Reviewed-by: Tim Van Patten <timvp@google.com> > Reviewed-by: Jamie Madill <jmadill@chromium.org> > Commit-Queue: Charlie Lao <cclao@google.com> Bug: b/208323792 Change-Id: I18bba207d1d8bb76dff32d9855a744dba93bc6d6 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3370601 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao cca412cd 2021-12-21T11:22:30 Vulkan: Consolidate all vertex conversion buffers to shared pool There are various conversion buffers that holds converted vertex or element or index data. They are DynamicBuffer for now. This CL switches them to use the shared group buffer pool. With this change, all allocation is represented by a BufferHelper object instead of an offset. I am able to remove the offset arguments from a lot of APIs. Bug: b/208323792 Change-Id: Ib611beb0c16cddbdd9ddf7b8961c439da9fa5180 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3352489 Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao 43b0e92b 2021-12-13T15:38:32 Vulkan: Consolidate mHostVisibleBufferPool and mMapInvalidate BufferVk::mHostVisibleBufferPool is allocated when BufferVk::mBuffer is not hostvisible and we need to map it. In that case mHostVisibleBufferPool is allocated and data copied from mBuffer to it and the pointer to mHostVisibleBufferPool is returned to user. BufferVk::mMapInvalidateRangeStagingBuffer is used when map is called on a small range. In this case we allocate memory for the small range of buffer and return that intead of waiting for entire buffer for GPU to finish. Also when BufferSubData is called, we also needs to allocate a staging buffer and issue a copyBuffer from staging buffer to main buffer. This CL consolidate all these three usage cases into one mStagingBuffer. It removes mHostVisibleBufferPool and mMapInvalidateRangeStagingBuffer from BufferVk class. This makes overall logic of managing data consistency much simpler as well since we only have two buffers: The main buffer storage mBuffer or mStagingBuffer. And mIsStagingBufferMapped tracks if mStagingBuffer is the one actually mapped to user or not so that at unmap time we know if we should flush the data to mBuffer or not. Bug: b/208323792 Change-Id: I4f0c79a2d86da1a43844ed2ba83ddeb7dd4a5c0b Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3335216 Reviewed-by: Lingfeng Yang <lfy@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao 2f3e6cc0 2021-12-13T17:40:18 Vulkan: Remove mShadowBuffer from BufferVk class. The shadow buffer was initially designed to avoid synchronization in glMapBuffer call while buffer itself is still busy. There are many optimization done inside BufferVk::mapImpl that try to avoid wait for GPU as much as we can by distinguish GPU write versus read, by detecting map call read/write intention by checking access bit, and finally by allocating a staging buffer to return a CPU friendly copy of data to caller. This shadow buffer implementation also have known bugs that are not keeping data in sync. With all these optimization added after initial mShadowBuffer implementation, I believe we do not have a good reason to still keep mShadowBuffer. And this has been disabled for months in main branch. This CL removes this code path completely which makes code a lot simpler. Bug: b/208323792 Change-Id: Ie5999e38b6120a371ec2e969f196e4754ebd0f8d Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3313333 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: mohan maiya <m.maiya@samsung.com> Reviewed-by: Tim Van Patten <timvp@google.com> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao 6c894e82 2021-11-04T14:49:41 Vulkan: Replace BufferVk::getBufferAndOffset() with getBuffer() Now BufferHelper class already keeps offset information. There is no reason for BufferVk to have that information any more. Bug: b/205337962 Change-Id: I6e014fb480bfcd5018ef9231b0fb87a50021f179 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3266147 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao 83a670ab 2021-10-29T09:12:26 Vulkan: Implement BufferPool using VMA's virtual allocator VMA's allocation calls used to be sub-allocating a pool of memory. What we really want is sub-allocate a VkBuffer object. VMA recently added support to expose the underlying range allocation algorithm via APIs, which user can use it to sub-allocate any object. This CL uses that new virtual allocation API to sub-allocate from a pool of VkBuffers. In this CL we only switched BufferVk::mBuffer to sub-allocate from the BufferPool object. Bug: b/205337962 Change-Id: Ia6ef00c22e58687e375b31bc12ac515fd89f3488 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3266146 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Amirali Abdolrashidi 89e11878 2021-12-06T09:42:46 Vulkan: Fix the UAF issue with BufferData * Fixed the use-after-free issue with stale buffer handles after calling BeginTransformFeedback. * Added an observer for TransformFeedbackVk to update the buffer handles when buffer's storage is changed and the buffer update type is StorageRedefined. * Added a function to TransformFeedbackVk::onDestroy() to release the counter buffers in order to avoid crash due to TransformFeedbackVk::end() not being called, e.g., as a result of no glEndTransformFeedback() calls. Bug: chromium:1274316 Change-Id: I8ed477f36e6ff89dd4764bb59af564c69efe33e2 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3321789 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Hailin Zhang 7b13a9ac 2021-12-09T18:37:59 Vulkan: Fix dynamic partial update buffer data issue. add test case for dynamic update buffer data. Signed-off-by: Hailin Zhang<hailinzhang@google.com> Bug: b/207714894 Change-Id: I8c1e93d152847c3162c0e2dd49abe3d899c859a0 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3328869 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Hailin Zhang <hailinzhang@google.com>
Hailin Zhang 3be551d7 2021-12-08T16:44:56 fix directUpdate buffer pointer issue. inside mapWithOffset already add the mBufferOffset Signed-off-by: Hailin Zhang<hailinzhang@google.com> Bug: b/207714894 Change-Id: Ia400bccbef1abc756cd8155e93a775338a30e8b9 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3325025 Reviewed-by: Lingfeng Yang <lfy@google.com> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Hailin Zhang <hailinzhang@google.com>
Lingfeng Yang 27bc56c6 2021-11-15T18:18:53 Vulkan: MAP_UNSYNCHRONIZED_BIT: Skip ghosting/idling Respect the following spec language: No GL error is generated if pending operations which source or modify the buffer overlap the mapped region, but the result of such previous and any subsequent operations is undefined Test: cpu time improves in unsync case in perf-tests/MapBufferRange.cpp Bug: angleproject:6680 Change-Id: I6133952546735aced6e6ee8468ef2ac695316fb6 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3272018 Commit-Queue: Lingfeng Yang <lfy@google.com> Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com>
Lingfeng Yang 647a703e 2021-11-12T13:48:06 Vulkan: Reorder logic in BufferVk::mapRange This CL flattens the logic, ordering read case first, then write, and simpler cases before more complex ones. This is to prepare for an optimization where we ignore certain paths if MAP_UNSYNCHRONIZED_BIT is set. No change in functionality or performance is expected. Bug: angleproject:6680 Change-Id: I0a2e9ee969216c90353eac7af6dabf648dea2173 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3279615 Commit-Queue: Lingfeng Yang <lfy@google.com> Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Shahbaz Youssefi dbc0c646 2021-11-06T01:09:26 Vulkan: Output the reason for RP closure in command buffer To make it easier when viewing the command buffer in a graphics debugger, this change inserts a marker just before closing the render pass that specifies why the render pass was closed. Bug: angleproject:2472 Change-Id: I862e500cd58332d6e199c853315c560fe6a73dc2 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3265609 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Lingfeng Yang cd822868 2021-10-28T13:00:09 Vulkan: MAP_INVALIDATE_RANGE_BIT: shadow or exclude One method of dealing with glMapBufferRange + range invalidation; treat it like bufferSubData and stage the update. Another method is to ghost the buffer but copy only memory outside the invalidated range. This CL pursues a policy where if less than half of the buffer is invalidated, we stage. Otherwise, we ghost and copy only memory outside the invalidated range. DynamicBuffer is chosen over DynamicShadowBuffer because it turns out to end up implicitly tracking all active invalidate ranges (through its freelist), and performs buffer copy on GPU. if we use a DynamicShadowBuffer and then BufferVk::stagedUpdate, it's the same thing but more work (an extra memcpy into the staging buffer). To make this clear, we split the logic of stagedUpdate into two parts, the allocation/map, and the flush, and reuse one half in glMapBufferRange, and the other half in glUnmapBuffer. Test: Faster performance in MapBufferRange perf test, no non-noisy regress in trace tests Bug: angleproject:6634 Change-Id: Ie2e6a9586824b8cb59a97419bb8052acd1de2033 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3251686 Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Lingfeng Yang <lfy@google.com>
Charlie Lao bae19e06 2021-10-26T13:35:57 Vulkan: Avoid unnecessary wait if mapBufferRange indicates read only When we call BufferVk::mapRangeImpl(), both from internal code paths for data reads or due to glMapBufferRange call, we are not passing the access bit to the call. This CL passes the proper access bits to the call and only wait for GPU writes to finish if access is for read only. This CL also adds access bitfield to the BufferVk::mapImpl() API and have various callers pass in the proper access bits as well. Bug: b/203582620 Change-Id: Ica8493c902dbd7b15996266c81ce0fd4dbfc2520 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3245487 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao 6b315a78 2021-10-26T19:04:06 Revert "Vulkan: Let BufferVk call into VMA for allocation when possible" This reverts commit 894ce75fb2f75e718ce76e466b8938524f65ac07. Reason for revert: crbug.com/1253325 Original change's description: > Vulkan: Let BufferVk call into VMA for allocation when possible > > Previously BufferVk class maintains a DynamicBuffer pool per BufferVk > object. This CL makes BufferVk skip DynamicBuffer pool in most cases and > do its own BufferHelper allocation directly. DynamicBuffer pool is only > used when desired, which is controled by a flag. With this CL, only > UBO/SSBO/AtomicBuffer will still use DynamicBuffer pool if the buffer > has to be allocated more than once. > > Bug: b/195588159 > Change-Id: I3aa08cef10ee9ee9f01f16403c6fbb99b37f4a8a > Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2901241 > Commit-Queue: Charlie Lao <cclao@google.com> > Reviewed-by: Tim Van Patten <timvp@google.com> > Reviewed-by: Jamie Madill <jmadill@chromium.org> Bug: b/195588159 Change-Id: Iecda3baa6bc887fa0caa86ab076994cae7c10f93 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3244257 Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Charlie Lao <cclao@google.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Charlie Lao 894ce75f 2021-05-21T10:59:14 Vulkan: Let BufferVk call into VMA for allocation when possible Previously BufferVk class maintains a DynamicBuffer pool per BufferVk object. This CL makes BufferVk skip DynamicBuffer pool in most cases and do its own BufferHelper allocation directly. DynamicBuffer pool is only used when desired, which is controled by a flag. With this CL, only UBO/SSBO/AtomicBuffer will still use DynamicBuffer pool if the buffer has to be allocated more than once. Bug: b/195588159 Change-Id: I3aa08cef10ee9ee9f01f16403c6fbb99b37f4a8a Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2901241 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Jamie Madill 123ba58d 2021-10-14T11:56:35 Vulkan: Remove "last submitted serial". This fixes race conditions with the async command processor. Instead of querying specific serial numbers, we ask the command queue to either wait for idle, or return the answer to "are you busy" directly. Bug: b/172704839 Change-Id: I06a8268d9b58d8c33b783af00ca74979ee158316 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3223641 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao ea580484 2021-10-05T13:40:01 Vulkan: Add feature flag to prefer CPU copy instead of staged update For ARM GPU, use GPU to do buffer to buffer copy has performance penalty due to potential bubble in the vertex pipeline. This CL adds a feature flag preferCPUForBufferDataSubData so that we can enable this behavior for ARM GPUs. This CL also tracks if GPU has referenced this BufferVk's storage since it got new storage. Due to sub-allocation, we may get a new sub-range of the same BufferHelper object when allocating new storage. But we currently do not have a way to track GPU progress of the sub-range of a buffer. So we will end up using BufferHelper's queueSerial to decide if it is still GPU busy or not. This CL adds mHasBeenReferencedByGPU boolean variable that will set to false when we got a new allocation and set to true as soon as buffer is been referenced by any GPU command. We use this to avoid checking queueSerial if it never been referenced by GPU. This is a temporary workaround for the bug, the full fix is tracked by https://issuetracker.google.com/201826021 Bug: b/200067929 Change-Id: I231fb0a678b0165a2ce1775d0aa4dbe7512fb4a8 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3183398 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com>
Charlie Lao 74b2886f 2021-09-22T13:49:57 Vulkan: Try to use CPU to copy when preserving old buffer data When glBufferSubData is called, we may acquire a new buffer if buffer is still GPU busy. When this happened, we have to preserve buffer content if old buffer has valid data in it. Instead of always use GPU to do copy, this CL will check if GPU is not writing to the buffer, we will just use CPU to do the copy form old buffer to new buffer from the ranges outside subData, controlled by the feature flag preferCPUWhenPreservingBufferData. Bug: b/200067929 Change-Id: I42053104b2be8da5f399cca92e934254988f2fd8 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3177322 Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao e437c4ad 2021-09-22T09:15:19 Vulkan: Only preserve buffer data when BufferVk has valid data When we receive glBufferSubData call and GPU is still accessing the buffer, we have two code paths to update data. If subData is more than half of the entire buffer range, we choose to acquire a new buffer and use DMA to copy the rest of buffer that outside of subData range from the old buffer back to the new buffer so that existing buffer data is being preserved. Otherwise we stage subData to use GPU buffer to buffer copy later on when buffer is been used. The reasoning behind is to minimize the amount of data copy. The improvement here is that if previously app called glBufferData with null pointer, we really do not have any valid data in the buffer and there is no need to preserve the existing buffer data. This CL tracks whether buffer has any valid data or not and also put this into consideration when we pick which code path to go. We also use this information to avoid preserve the existing data in BufferVk::acquireAndUpdate Bug: b/200067929 Change-Id: I266dd93bed2d3c07e3a5af3e4e613e7f6023b393 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3176500 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com>
Jamie Madill cf8c5678 2021-09-17T13:16:36 Vulkan: Don't sync VAOs after BufferSubData calls. We still need to syncState after buffers that contain converted attributes are updated. Includes a perf regression test. Bug: angleproject:6371 Change-Id: I54227fc43e7b3fe79072da7783dab0177ccb0486 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3182706 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Jamie Madill cebca7c2 2021-09-24T07:55:38 Texture: Ignore buffer contents changed events. Texture doesn't need to care when its attached buffer gets different contents via a SubData call. This CL updates the BufferVk logic to ensure that SubData calls trigger a storage changed notification when there's a new storage, and otherwise Texture can ignore SubData calls. Will make it easier to split "contents" changed notifications to their own event, for optimizing Vertex Buffer updates. Bug: angleproject:6371 Change-Id: I4f15ad3ad2da5d838bd51fb065184b7344b188d8 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3181562 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com>
Tim Van Patten a1b829dd 2021-09-22T18:29:08 Vulkan: Retain src buffer in acquireAndUpdate() It's possible for acquireBufferHelper() to garbage collect the original (src) buffer before copyFromBuffer() has a chance to retain it, so it must be retained before then. Previously, we were relying on the retain calls in copyFromBuffer() to be sufficient. However, there is a race condition when the asynchronous CommandProcessor is enabled, since the garbage could be freed before copyFromBuffer() has a chance to retain the buffer (and allow destroyIfComplete() to skip destroying the object). For the full context, see the comment chain here: https://chromium-review.googlesource.com/c/angle/angle/+/3146319/16..24/src/libANGLE/renderer/vulkan/BufferVk.cpp#b833 Bug: angleproject:5971 Change-Id: I7c812069343fdad948189d696bfebab8da68c1a3 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3179866 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Tim Van Patten <timvp@google.com>
Tim Van Patten 68c0da83 2021-09-15T12:00:08 Vulkan: Inform frontend when new buffer is allocated When a buffer is mapped with GL_MAP_INVALIDATE_BUFFER_BIT while it's currently in use, the Vulkan backend will allocate a new buffer, map it, and return the pointer to the new buffer. This was missing a call to inform the frontend that a new buffer was allocated, causing the old buffer data to be accessed in subsequent draw calls. The fix is to add a onStateChange(angle::SubjectMessage::SubjectGhosted) call when the new buffer is allocated, to inform the frontend. Bug: angleproject:5971 Bug: angleproject:6396 Test: TextureBufferTestES31.MapTextureBufferInvalidateThenWrite Change-Id: I9984d1049ab4d6a2066f4440fc710c9b93ff6ab8 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3163244 Commit-Queue: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Tim Van Patten 9158436e 2021-07-31T18:26:16 Vulkan: glMapBuffer(): Create new buffer (Buffer Ghosting) When glMapBuffer() is called, if the buffer is in use but not being written to by the GPU: 1.) Create a new buffer. 2.) Copy the contents of the old buffer into the new buffer. 3.) Map the new buffer and return the pointer. Creating a new buffer prevents ending the renderpass and flushing the commands to allow the in-use buffer to be mapped. This change increases Idle Heroes performance from 40FPS to 125FPS. Bug: angleproject:5971 Test: VulkanPerformanceCounterTest.MappingGpuReadOnlyBufferGhostsBuffer Test: BufferDataTest.MapWriteArrayBufferDataDrawQuad Test: BufferDataTest.MapWriteArrayBufferDataDrawArrays Change-Id: I1d433d179f9f5110a948f191c5aedda5397acac8 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3065799 Commit-Queue: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com>
Tim Van Patten 57d59e83 2021-09-07T17:41:11 Vulkan: Add ResourceWrite to track Read and Write Access vk::Resource currently only tracks accesses in general, not which type of access is being performed. This CL adds the new class ResourceWrite to track whether the access is a Read or Read/Write access and when the access completes. This allows a follow-on CL to know when a buffer is being written to by the GPU or if the GPU is only reading from a buffer. Tracking write accesses to buffers is required when attempting to "Ghost" (duplicate) GPU-read-only buffers to prevent breaking the render pass when the CPU maps the buffer memory. Bug: angleproject:5971 Test: ComputeShaderTest.ImageBufferMapWrite Change-Id: I965e3e75730719ccce77334744ae4feae33c6101 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3146319 Commit-Queue: Tim Van Patten <timvp@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com>
Shahbaz Youssefi eaa6961d 2021-05-17T18:56:53 Revert "Vulkan: Disable BufferVk suballocation" This reverts commit 76181384075c6eb0a5788bf1b732a1e05f6d73bc. Reason for revert: Bug exposed by this is fixed in https://chromium-review.googlesource.com/c/angle/angle/+/2896168 Original change's description: > Vulkan: Disable BufferVk suballocation > > There are still unresolved bugs. > > Bug: angleproject:5719 > Bug: chromium:1209197 > Change-Id: I6a971c421d0ae266404d1ecbf8741a9747a4e809 > Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2897545 > Reviewed-by: Cody Northrop <cnorthrop@google.com> > Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> > Commit-Queue: Tim Van Patten <timvp@google.com> Bug: angleproject:5719 Bug: chromium:1209197 Change-Id: I5c24b5f6476eab98ed5a7b90b3d1796ffc7ca106 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2896169 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Shahbaz Youssefi 8bd3d7d5 2021-05-17T13:45:33 Vulkan: Fix a bug releasing DynamicBuffer-owned buffer There was one instance of BufferVk releasing a buffer it had allocated from a DynamicBuffer. This shouldn't have happened as the DynamicBuffer owns the buffers. Bug: angleproject:5720 Change-Id: I435512f4bb099130126bf3efb48a238fcd9f3ddb Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2896168 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Mohan Maiya <m.maiya@samsung.com> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Shahbaz Youssefi 76181384 2021-05-14T15:31:24 Vulkan: Disable BufferVk suballocation There are still unresolved bugs. Bug: angleproject:5719 Bug: chromium:1209197 Change-Id: I6a971c421d0ae266404d1ecbf8741a9747a4e809 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2897545 Reviewed-by: Cody Northrop <cnorthrop@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Tim Van Patten <timvp@google.com>
Shahbaz Youssefi e354ff1a 2021-03-05T04:07:21 Vulkan: Allow DynamicBuffer suballocation in BufferVk When allocations are made from DynamicBuffer, they suballocate from a possibly larger BufferHelper. In BufferVk, the offset of the suballocation was discarded, which limited the use of DynamicBuffer to a pool of small buffers. This change applies any such offset that may arise from suballocations everywhere, and makes BufferVk use a larger buffer size when the GL_DYNAMIC_* buffer usage hints are provided. Bug: angleproject:5719 Change-Id: I3df3317f7acff1b1b06a5e3e2bb707616a7d0512 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2738650 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Mohan Maiya 2d5df9d9 2021-05-01T12:50:55 Vulkan: Don't assume host visibility for external buffers When importing external buffers, Vulkan ICDs could choose to import the memory into a memoryType that doesn't support the VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT property. Account for this possibility. Bug: angleproject:5073 Bug: angleproject:5909 Change-Id: Ied063b38fa48d0c8508c4aaca9214cc526f393ad Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2783669 Commit-Queue: Mohan Maiya <m.maiya@samsung.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Mohan Maiya cc3e7b5d 2021-04-26T14:26:29 Vulkan: Handle GL_MAP_PERSISTENT_BIT_EXT for external buffer When user specifies GL_MAP_PERSISTENT_BIT_EXT bit for an external buffer but we are unable to import it into a memoryType that supports host visibility, error out with GL_INVALID_OPERATION error. Bug: angleproject:5073 Bug: angleproject:5909 Change-Id: I03e5477266dfb705bfb0a1bce5ca003049ef4c7a Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2862560 Commit-Queue: Mohan Maiya <m.maiya@samsung.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Mohan Maiya fc0c8d18 2021-04-27T16:58:50 Vulkan: Honor mapRangeImpl and unmapImpl abstraction All BufferVk methods need to honor the abstraction provided by mapRangeImpl and unmapImpl. Do not map BufferVk::mBuffer directly, this is needed for when we support device local buffers that cannot be CPU mapped. Bug: angleproject:5909 Change-Id: I520e5cc0994560a3784b8978e349550211dc2cde Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2862559 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Mohan Maiya <m.maiya@samsung.com>
Mohan Maiya 7fe44a53 2021-03-20T09:39:09 Vulkan: Don't acquire new BufferHelper for external buffers EXT_external_buffer spec - This extension allows the data store for an immutable buffer to be sourced from an external EGLClientBuffer, allowing sharing of EGL client buffers across APIs, across processes, and across different processing cores such as the GPU, CPU, and DSP. The intent is for a single backing memory to be reused across various processes and processors. Ensure that a glBuffer backed by external memory does not orphan the memory when glBuffer APIs like glBufferSubData or glMapBufferRangeEXT modify the glBuffer. Bug: angleproject:4380 Bug: angleproject:5073 Tests: ExternalBufferTestES31.*DoesNotCauseOrphaning*Vulkan Change-Id: I4e88f80d93ee1ba1208378121412926351d10af8 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2776192 Commit-Queue: Mohan Maiya <m.maiya@samsung.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Mohan Maiya 331640e5 2021-03-09T14:36:19 Vulkan: Pass in the correct size to acquireBufferHelper When BufferVk::acquireAndUpdate calls into acquireBufferHelper to allocate a new buffer helper we were passing in the update size instead of the full buffer size. Modified acquireAndUpdate's parameter to better reflect intent. Bug: angleproject:5689 Change-Id: Ic4fbc015651491ec028d747da5d45670264b93fa Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2746066 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Mohan Maiya <m.maiya@samsung.com>
Mohan Maiya c054008f 2021-03-06T13:33:11 Vulkan: Check buffer usage before unmapping Buffers with dynamic usage will have frequent CPU updates. Don't CPU unmap such buffers after every update. Commits b5af8bde13 and 58c35d421 took care of performing an unmap when we release the buffer either to the renderer or mBufferFreeList. Bug: angleproject:5689 Change-Id: Ib6b8f6a7d0cb36583140e67bf164e074af098b8b Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2741688 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Mohan Maiya <m.maiya@samsung.com>
Shahbaz Youssefi e366e2c3 2021-02-27T01:00:02 Vulkan: Keep dynamic buffer's free list trimmed ContextVk's staging buffer never gets a chance to free its free buffer list. During application load time, a large amount of memory may be allocated from this buffer to stage texture updates and they would remain throughout the life of the application. This change ensures that the free buffer list doesn't grow unbounded. In the Manhattan trace, this saves >1GB of memory on Linux. There are now three policies for vk::DynamicBuffer: - Always reuse buffers: This is useful for dynamic buffers that make frequent small allocations, such as default uniforms, driver uniforms, default vertex attributes and UBO updates. - Never reuse buffers: This is for situations where the buffer is unlikely to be used after some initial usage, such as texture data upload or vertex format emulation (as the conversion result is cached, so it's never redone). - Limited reuse of buffers: For the staging buffer in the context which is shared by all immutable texture data uploads, it's useful to keep a limited number of buffers (1 in this change) to support future texture streaming while allowing a large number of buffers allocated in a burst to be discarded. Bug: angleproject:5690 Change-Id: Ic39ce61e6beb3165dbce4b668e1d3984a2b35986 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2725499 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Shahbaz Youssefi d7037aa2 2021-02-11T14:35:30 Vulkan: noop glMemoryBarrier(CLIENT_MAPPED_BUFFER_BARRIER_BIT_EXT) CLIENT_MAPPED_BUFFER_BARRIER_BIT_EXT requires a memory barrier: shader buffer write -> host read. According to the spec, the data is only available after a call to glFinish or wait on sync: > The application must call MemoryBarrier with the > CLIENT_MAPPED_BUFFER_BARRIER_BIT_EXT set and then call FenceSync with > SYNC_GPU_COMMANDS_COMPLETE (or Finish). Then the CPU will see the > writes after the sync is complete. When a buffer is written to by the GPU, ANGLE calls onHostVisibleBufferWrite(), which ensures a "memory write -> host read" barrier is issued at the end of the command buffer. Additionally, persistently mapped buffers use VK_MEMORY_PROPERTY_HOST_COHERENT_BIT, so there's no need for a call to vkInvalidateMappedMemoryRanges. As a result, there's nothing necessary in ANGLE to do for this barrier bit. Note that should persistenly mapped buffers start using non-coherent memory, this barrier should imply a call to vkInvalidateMappedMemoryRanges for the persistently mapped buffers. Bug: angleproject:5070 Change-Id: Iaeae019dadfa659a47d2dac41c0c09f1c15e584b Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2689380 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Mohan Maiya <m.maiya@samsung.com> Reviewed-by: Charlie Lao <cclao@google.com>
Charlie Lao 0c5a55a5 2020-12-17T14:52:59 Vulkan: MapBufferRange should avoid wait if INVALIDATE_BUFFER is set If glMapBufferRange is called with GL_MAP_INVALIDATE_BUFFER_BIT bit set, caller indicates that it don't care about the previous content. If the buffer is busy, instead of wait for GPU to finish and then map the buffer, we should just allocate a new memory and return it. brawl_stars is hitting this case. With this CL, the frame time is cutting to half on the pixel device. Bug: b/175905404 Change-Id: If1220f07ebf53dd28fe6a4732eaba84e2e57598e Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2597784 Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Shahbaz Youssefi 2ffff6d0 2020-11-12T10:56:06 Vulkan: Support image buffers This change does not support reinterpreted formats yet. Additionally, despite lack of support for RGB32 formats, EXT_texture_buffer is exposed by this extension. Those formats don't support the STORAGE_TEXEL_BUFFER feature on any known hardware. Bug: angleproject:3573 Change-Id: I85f45eb23f6a0aa533488bb98d9f226d59af4d76 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2534395 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Mohan Maiya f197ebac 2020-11-16T15:16:56 Vulkan: Add EXT_external_buffer support Addition of buffer support for external memory Also adds new end2end tests for these usecases * SubData update * map/unmap buffer * dispatch compute with external buffer Bug: angleproject:5073 Test: ExternalBufferTestES31.*Vulkan Change-Id: Ib3cccaca77b76830effe49d3731782552e7424ec Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2525105 Commit-Queue: Mohan Maiya <m.maiya@samsung.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 9e7f08fc 2020-11-06T16:55:51 Vulkan: Fix incorrect reordering of barriers Take the following situation, a simple copy from image to buffer: ANGLE_TRY(contextVk->onBufferTransferWrite(buffer)); ANGLE_TRY(contextVk->onImageTransferRead(aspectFlags, image)); CommandBuffer &commandBuffer = contextVk->getOutsideRenderPassCommandBuffer(); commandBuffer.copyImageToBuffer(imageHandle, layout, bufferHandle, 1, regions); Both `onBufferTransferWrite` and `onImageTransferRead` may flush either the outsideRP or insideRP command buffers. If buffer is not previously used, but image is used: - onBufferTransferWrite: buffer usage is recorded in outsideRP1 - onImageTransferREad: outsiderRP1 is flushed, outsideRP2 is started - copyImageToBuffer: recorded on outsideRP2, but buffer usage not recorded there - A following command that uses the buffer and requires barrier doesn't close outsideRP2 as it believes it was not used there Bug: angleproject:5319 Change-Id: Ib8994083fbc21969a538cda3784adee57b089415 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2523388 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com>
Mohan Maiya a2d8bbb5 2020-09-18T18:18:34 Vulkan: Add GL_EXT_buffer_storage extension support Addition of support for immutable storage to buffer objects. Also adds new end2end tests for these usecases * Basic BufferStorage * SubData update * map/unmap buffer Bug: angleproject:5056 Tests: angle_end2end_tests --gtest_filter=BufferStorageTestES3*Vulkan Change-Id: Iba74b372ad033711927b63c6a04cec0eeb4db699 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2419952 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Mohan Maiya <m.maiya@samsung.com>
Jamie Madill 68a5baeb 2020-09-23T22:13:03 Revert "Vulkan: Implement a SharedResourceUse pool" This reverts commit de335c16855f11d1f0a6f0b37bee30c8a09a6c1d. Reason for revert: Might actually regress CPU overhead perf. Unsure but it's possible the reported perf improvement was due to variance. Original change's description: > Vulkan: Implement a SharedResourceUse pool > > When adding a Resource to the ResourceUseList of ContextVk > we constructed a new SharedResourceUse object for tracking > and update of the Resource's Serial. We would then delete > it after releasing the resource. This incurs repeated > memory operation costs. > > Instead we now allocate a pool of SharedResourceUse objects > and acquire and release from this pool as needed. > > VTune profile of the Manhattan 30 offscreen benchmark > shows the CPU occupancy of bufferRead decrease from an > average of 0.9% -> 0.6% and imageRead decreases from > an average of 0.4% -> 0.3%. The bottleneck for both > these methods is the retain() method that leverages > the new SharedResourceUse pool. > > Bug: angleproject:4950 > Change-Id: Ib4f67c6f101d4b2de118014546e6cc14ad108703 > Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2396597 > Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> > Reviewed-by: Jamie Madill <jmadill@chromium.org> > Commit-Queue: Mohan Maiya <m.maiya@samsung.com> TBR=syoussefi@chromium.org,jmadill@chromium.org,m.maiya@samsung.com # Not skipping CQ checks because original CL landed > 1 day ago. Bug: angleproject:4950 Change-Id: I40081551c3db67d6e55182fea40119946ed16ac3 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2426479 Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Mohan Maiya de335c16 2020-09-14T12:04:20 Vulkan: Implement a SharedResourceUse pool When adding a Resource to the ResourceUseList of ContextVk we constructed a new SharedResourceUse object for tracking and update of the Resource's Serial. We would then delete it after releasing the resource. This incurs repeated memory operation costs. Instead we now allocate a pool of SharedResourceUse objects and acquire and release from this pool as needed. VTune profile of the Manhattan 30 offscreen benchmark shows the CPU occupancy of bufferRead decrease from an average of 0.9% -> 0.6% and imageRead decreases from an average of 0.4% -> 0.3%. The bottleneck for both these methods is the retain() method that leverages the new SharedResourceUse pool. Bug: angleproject:4950 Change-Id: Ib4f67c6f101d4b2de118014546e6cc14ad108703 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2396597 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Mohan Maiya <m.maiya@samsung.com>
Shahbaz Youssefi 295d2ccd 2020-08-24T14:46:31 Vulkan: Generate perf warnings on suboptimal paths Using KHR_debug features, this change creates a performance-warning-generation macro and employs it in a handful of locations to provide useful feedback to application developers. The warnings added in this change are not exhaustive. Bug: angleproject:3461 Bug: angleproject:4900 Change-Id: Id62435d170d90c5be9c1c5cab2d6779ccb58345e Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2372628 Reviewed-by: Geoff Lang <geofflang@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 027f0c38 2020-08-24T15:55:55 Vulkan: Remove Host->device availability barrier. vkQueueSubmit already performs this operation, so this barrier was unnecessary. The only place this is necessary is when the GPU is expected to receive updates from the CPU post-submit. ContextVk::synchronizeCpuGpuTime is the only such use-case in ANGLE. Bug: angleproject:4897 Change-Id: I7297fbd65d3faabd949dddb6bcaa181053a83193 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2372631 Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 4909d08c 2020-08-19T12:21:44 Vulkan: Rename mStagingBufferStorage to mStagingBuffer Rename only to keep it consistency. Bug: b/164511310 Change-Id: I7b00c48010b76bff0b292e6e75b9aff154cdecc0 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2364727 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Jamie Madill eb85c021 2020-08-05T15:07:15 Vulkan: Refactor Context CommandBuffer query. getOutsideRenderPassCommandBuffer returns the command buffer directly since it's now stateless and cannot throw an error. All the RenderPass begin/end and flushing are done by the dependency functions (buffer/ image read/write). Bug: angleproject:4911 Change-Id: I5e7806be9d0e1b5e358524bd485298d660fac942 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2339544 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com>
Jamie Madill 23daea2f 2020-08-06T10:40:00 Vulkan: Rename CommandBuffer get method. This method will no longer end the RenderPass in a following CL. Renaming it in a split CL makes the review diff simple. Bug: angleproject:4911 Change-Id: Id48257884dccb7c86f7de2cc9ca95e651fb68df7 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2340788 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com>
Jamie Madill f9dd2c15 2020-08-02T18:03:16 Vulkan: Accumulate Buffer barriers. Uses an unordered_map in the CommandBufferHelper to track buffer reads and writes. Buffer barriers are tracked specially in the CommandBufferHelper class as a barrier we execute immediately when we execute the commands into the primary. So when we run into an incompatible buffer access we must start a new command buffer. The rules for an incompatible access are: - when we are reading a buffer, any prior write in the same command buffer is incompatible. - when we are writing a buffer, any prior read or write in the same command buffer is incopatible. Also adds a regression test using a new performance counter. Bug: angleproject:4429 Change-Id: I393a4ed87314f955eb998940b877ba76ea15a7b8 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2334091 Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Charlie Lao de309a42 2020-07-21T17:19:17 Vulkan: Make staging buffer per context Right now staging buffers are per BufferVk. This will make it per ContextVk so that it can be shared among all objects that needs a staging buffer. Bug: b/161846868 Change-Id: I9c436acdacaf429a43cbdfa216927df0796f7a28 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2310962 Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com> Reviewed-by: Ian Elliott <ianelliott@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Manh Nguyen dc9743fb 2020-07-14T11:33:29 Add buffer serialization capability Serializes buffers' states stored on CPU. Gets buffers contents on GPU by mapping buffers to CPU's address space, then copy their data. Unmap buffers after finish. Since this feature is for tests only, it is only implemented for the Vulkan backend. Adds buffer serialization to serializeContext method so that capture replay regresssion testing now compares the states of buffers too. Bug: angleproject:4817 Change-Id: Ic9b529701014d5ba8420023a021cd5ea381bd9a1 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2295950 Commit-Queue: Manh Nguyen <nguyenmh@google.com> Reviewed-by: Cody Northrop <cnorthrop@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Mohan Maiya 62ff54eb 2020-05-12T13:27:21 Vulkan: Featurize shadow buffers Shadow buffers help reduce the latency of glMap* operations at the cost of CPU overhead. It might not be desirable to incur such an overhead for all usecases. Featurize it but enable it by default. Bug: angleproject:4339 Change-Id: I6374618bf99677eef55fd50a139fb86f5ea70791 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2278102 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Mohan Maiya <m.maiya@samsung.com>
Tobin Ehlis b50541b2 2020-01-14T09:07:03 Vulkan:Adding key perf trace markers Adding trace markers in performance-critical functions. Primary areas of interest are command buffer processing and cleanup and memory mapping. Bug: b/156403378 Change-Id: Icba53024771711d79f7eee7085bf4dae0e033e63 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2002689 Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Tobin Ehlis <tobine@google.com> Commit-Queue: Tobin Ehlis <tobine@google.com>
Mohan Maiya cf8422c2 2020-05-19T10:14:02 Vulkan: Acquire a new BufferHelper from the pool based on a threshold We acquire a new BufferHelper from the pool when the app updates the data of the entire buffer. In scenarios where the app updates say, 60% of the buffer it would still be benificial to acquire a new buffer and copy over the remaining 40% of data from the old buffer to the new one. This reduces the transfer workload from 60% to 40% of buffer size. Currently the threshold is set to 50% of buffer size. Bug: angleproject:4380 Change-Id: I12576c585230e771d4c1a4352fab93dd3db2ecef Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2204655 Commit-Queue: Mohan Maiya <m.maiya@samsung.com> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Charlie Lao 41f7bcce 2020-04-30T16:09:36 Vulkan: Add missing cache flush DynamicBuffer are not cache coherent, thus requires flush. Also adds a few assertion to ensure implementation matches expectation. Bug: b/155432713 Change-Id: Iaf28786168a3bb5d746b43e030f882c4b6d005ad Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2174269 Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com> Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Charlie Lao <cclao@google.com>
Charlie Lao df31624e 2020-04-30T13:28:24 Vulkan: Reduce the onBufferRead/onBufferWrite API verbosity a bit This adds helper functions to handle common use case for onBufferRead and onBufferWrite to reduce the API verbosity a little bit. Also fix the transform feedback bug that we are passing in wrong access/stage flags when it is emulated by vertex shader. Bug: b/155122200 Change-Id: Id2549ca00cad184a90c6230dc3665aaff44dda08 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2174265 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao f07d0072 2020-04-27T16:51:05 Vulkan: use fine grain stage for buffer barriers We are using VK_PIPELINE_STAGE_ALL_COMMANDS_BIT for mGlobalMemoryBarrierStages, which is used for both src and dst. This will cause a full pipeline stall whenever a buffer object introduces a barrier. This CL will let the caller pass in the specific stage it will be used for, allowing us to track write and read stage dependencies separately and request the corresponding barriers. Bug: b/155122200 Change-Id: I8b8bd291a03b77d07cfbcbe7c3cda2d3771588b9 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2169014 Commit-Queue: Charlie Lao <cclao@google.com> Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Brandon Schade fa03eb9d 2020-02-05T15:25:52 Vulkan: Use DynamicBuffer for BufferVk When there is glBufferData API call, if the current VkBuffer is in use, we copy to a staging buffer to be gpu copied later. Instead of doing this second copy, write directly to a new buffer that will be used for subsequent gpu operations. BufferVk now has a DynamicBuffer to handle the logic of acquiring a new/free buffer to be used. Bug: angleproject:4380 Change-Id: I207f334013ae944090eb48c26c692a09e8815f74 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2040513 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Mohan Maiya <m.maiya@samsung.com>
Hyunchang Kim 6e0d718a 2020-03-31T18:41:57 Vulkan: Implement device memory sub-allocation Use AMD Vulkan Memory Allocator for device memory sub-allocation. We now have a mempool from which all glBuffer memory is allocated. The CPU overhead involved in repeated IOCTL calls to the kernel is reduced significantly. Bug: angleproject:2162 Change-Id: Id7681ffe2ac3d2853141ebe34c7df7b7fdd0d55e Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2124519 Reviewed-by: Tobin Ehlis <tobine@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Mohan Maiya <m.maiya@samsung.com>
Mohan Maiya 745e0712 2020-03-21T17:46:05 Vulkan: Enable CPU only buffers for PBOs Add support for a CPU only buffer for PBOs that serve as the destination for all host operations like MapBuffer*. This removes the latency caused by waiting for the in-flight GPU commands to be complete before handing over the buffer to the app. This change removes a ~6ms wait/sleep on the first call to MapBuffer* in each frame of Manhattan Bug: angleproject:4339 Tests: angle_end2end_tests --gtest_filter=BufferDataTest*Vulkan Change-Id: I52016b160af8a670cc30f01c05e48f699521310f Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2116874 Commit-Queue: Mohan Maiya <m.maiya@samsung.com> Reviewed-by: Tobin Ehlis <tobine@google.com>
Hyunchang Kim d30da072 2020-03-31T15:01:14 Vulkan: Request host uncached memory for some glBuffer objects Uncached memory is an optimal memory type for resources with write-only access from the CPU since it avoids polluting CPU caches with data the CPU will never use. Bug: angleproject:2162 Change-Id: I33d0d91830979990bcdcca3bd9eedde0345fb5a6 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2131880 Commit-Queue: Mohan Maiya <m.maiya@samsung.com> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Mohan Maiya 7daf31d8 2020-03-18T09:19:52 Vulkan: Use device local memory for conversion buffers that can be converted with the GPU When converting a vertex buffer by using GPU, the conversion buffer doesn't need to be host mappable. Hence the conversion buffer can be allocated on device local memory for faster GPU access times. Bug: angleproject:3534 Change-Id: I2efabec20186992479920bddd3abd36f9c13babc Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2108706 Commit-Queue: Mohan Maiya <m.maiya@samsung.com> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Mohan Maiya 78a85f2c 2020-03-16T10:28:59 Vulkan: Request device local memory for glBuffer with GL_STATIC* usage glBuffer objects with GL_STATIC_* usage patterns will now request the storage to be allocated in device local memory. For glBuffer objects with GL_DYNAMIC_* usage patterns we request a host cached memory. Bug: angleproject:4480 Change-Id: I7ca968f5ddfb59e4df3ecd07ae65df2bbf734190 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2102958 Commit-Queue: Mohan Maiya <m.maiya@samsung.com> Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com>
kmx.io     mail     discord kmxgit v0.4.0