src/libANGLE/renderer/vulkan/BufferVk.h


Log

Author Commit Date CI Message
Shahbaz Youssefi 60aaf4a0 2024-03-14T12:58:56 Vulkan: Move renderer to namespace vk This class is agnostic of EGL. This change moves it to namespace vk for use with the OpenCL implementation Bug: angleproject:8564 Change-Id: I57f7807d6af8b3d5d7f8efbaf8b5d537a930f881 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5371324 Reviewed-by: Austin Annestrand <a.annestrand@samsung.com> Reviewed-by: Geoff Lang <geofflang@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Amirali Abdolrashidi e1d2e88a 2023-09-20T11:53:15 Check pending garbage after some buffer releases * Embedded BufferHelper::releaseBufferAndDescriptorSetCache() inside a new ContextVk method: releaseBufferAllocation() * After releasing the buffer, there is a check for excess pending garbage. If the tracked pending garbage size is larger than the threshold, the context will be flushed. * Unskipped the test "BufferDataInLoopManyTimes", which was failing on Android devices. Bug: b/280304441 Change-Id: Ib34319f3291dd2200fc1a92e30645f9d1da8e2b9 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4879086 Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com> Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Charlie Lao 0561884e 2023-04-26T17:26:42 Vulkan: Dirty VertexArray binding bit if buffer storage change In crrev.com/c/3669603, we did optimization for black_desert_mobile that when vertex array is unbound, we remove vertex array from buffer's observer list to reduce overhead of observer notifications when buffer is been modified. To compensate for the lost notification, when vertex array is bound, we always assume every buffer that is bound to vertex array has been dirtied, for the simplicity at that time. This CL further the optimization of that CL. In this CL, I moved the dirty bit set into backend and improves vulkan backend by checking buffer's serial number and only dirty the binding if the serial has changed. Given this, now we can also remove all the non-current vertex array from buffer's observer list (previously it is heuristic based with a hard coded observer count limit). This and the previous CL improves asphalt_9 by ~1%. Bug: b/277644512 Change-Id: Ibc3f8e3df9fe70c6879e0b2bca86d8487a9dba73 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4481241 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Yuxin Hu <yuxinhu@google.com> Commit-Queue: Charlie Lao <cclao@google.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 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 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>
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 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>
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 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 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>
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>
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>
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 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 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>
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 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 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>
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>
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>
Jamie Madill 6c158164 2020-05-28T15:19:51 Vulkan: Fix XFB invalid accesses in buffer OOM. This uses the "null" buffer in the Renderer to bind an empty buffer handle so ANGLE can maintain a consistent state. Bug: chromium:1086532 Change-Id: I1912a1d1cb64433a285fcfced80a675619690a0b Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2219140 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Courtney Goeltzenleuchter <courtneygo@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>
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>
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>
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 01c0d6bd 2020-01-12T13:41:31 Vulkan: Use dynamic buffers for staged updates Dynamic buffers are used to perform staged updates to BufferVk objects instead of recreating staging buffers for each update. Bug: angleproject:4292 Change-Id: I0f64c821c97e0e6014e9df1d4f99e2f495838025 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2001461 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
James Dong 020abb8b 2019-07-24T11:33:49 Vulkan: invalidate translation buffers for SSBOs Translation buffers weren't being marked dirty after running a compute shader in which they are bound as SSBOs. This change invalidates all SSBOs after a draw or compute call. Bug: angleproject:3739 Change-Id: I66b56df7e619b55afc7e3da6b5613b6d050e06bb Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1717144 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: James Dong <dongja@google.com>
Shahbaz Youssefi f92fc916 2019-07-15T22:39:23 Vulkan: Compute shader support A DispatchHelper class is created as the equivalent of FramebufferHelper as a command graph resource. There's currently a single dispatcher and all dispatch calls are recorded on that. Context dirty bits are set up in such a way that graphics and compute workloads are independently handled, so that issuing a dispatch call wouldn't cause a framebuffer's render pass to rebind resources. Bug: angleproject:3562 Change-Id: Ib96db48297074d99b04324e44b067cfbfd43e333 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1688504 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Shahbaz Youssefi 55efe37c 2019-07-03T11:52:21 Vulkan: Cleanup buffer dependencies onWrite now sets the dependency to make sure the order of setting dependency and adding memory barrier is correct. onReadByBuffer is added to handle buffer-to-buffer dependency and barrier setting correctly without causing a graph loop. onExternalWrite is added so that BufferVk doesn't have to track write access flags. Additionally, setting write dependencies now include both read and write flags. This is in preparation for SSBO support where the buffer can be used to read data in addition to write. Bug: angleproject:3561 Change-Id: I2028186ea14459cd159cf79f6d640df54538fc62 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1687119 Reviewed-by: Tim Van Patten <timvp@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi b1c8dbf3 2019-06-14T23:57:26 Vulkan: Correct synchronization for buffer readback When mapping buffer memory, a flush is performed if the buffer has pending operations followed by a finishToSerial to make sure the buffer is no longer in use by the GPU. This also implements GLES 3.0 buffer mapping flags: GL_MAP_INVALIDATE_RANGE_BIT: No-op. Vulkan's vkMapMemory doesn't have such a feature. GL_MAP_INVALIDATE_BUFFER_BIT: Same GL_MAP_FLUSH_EXPLICIT_BIT: Vulkan automatically flushes host memory writes on vkQueueSubmit, so this is no-op as well. GL_MAP_UNSYNCHRONIZED_BIT: The flush+finishToSerial call is skipped in this case. Bug: angleproject:3213 Change-Id: I6bdb460dffbb57170649f4c9678afbfae331926c Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1661252 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com>
Jamie Madill 44063c80 2019-06-04T15:20:30 Vulkan: Store array buffer conversions in BufferVk. The intent of this CL is to call convertVertexBuffer*PU only when we have new data to convert. If the app unbinds and rebinds a vertex buffer without changing the data we can now retrieve the cached vertex buffer info from the BufferVk class. Previously we would always reconvert the data on a rebind. This was slowing down applications and benchmarks. To achieve this we add a conversion cache to BufferVk. Each cache entry stores a key based on the vertex info. Also we store a ring buffer for each cache entry and a flag to indicate if the entry is dirty. The cache is dirtied on a bufffer data update or a map call. Improves performance in the T-Rex benchmark. Bug: angleproject:3495 Change-Id: Ia999c9187510748ba95bc98362eb332e1990d270 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1638903 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com>
Geoff Lang ee244c77 2019-05-06T10:30:18 Vulkan: Move command graph and garbage to ContextVk. To support multithreading, contexts should manage their own command graphs and garbage. This allows safe access to vulkan resources such as command pools without thread synchronization. BUG=angleproject:2464 Change-Id: I930149bc9f0793028761ee05ab50b8c0a4dec98a Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1516515 Commit-Queue: Geoff Lang <geofflang@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi 216f73d0 2019-04-12T13:32:30 Vulkan: add uniform buffer object support Support for layout qualifiers in interface blocks are added. All interface blocks are adjusted to either be in std140 or std430. In the Vulkan backend, a new descriptor set is added for UBOs. A dirty bit is added for UBO updating and pipeline layouts and descriptor bindings are updated. Bug: angleproject:3199, angleproject:3220 Change-Id: I271fc34ac2e1e8b76dee75e54a7cff0fe15fe4ee Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1565061 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Jamie Madill 1f750d1e 2019-01-16T13:27:16 Even more inlining and micro-optimization. Improves perf by about 3-4% on the Vulkan VBO state change test. Bug: angleproject:3014 Change-Id: If4415e503cd883cf7de6387bf1ebbca0e5fc994e Reviewed-on: https://chromium-review.googlesource.com/c/1393907 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
Shahbaz Youssefi 4abdf74f 2018-11-28T14:41:10 Vulkan: Add dynamic index buffers to graph With DynamicBuffer outputting BufferHelper objects, these objects can participate in the command graph, i.e. record commands. This means they need appropriate dependencies in the graph as well as pipeline barriers. There are a few users of DynamicBuffer for which this change should be applied to. This change covers index buffers. This commit includes a fix to BufferHelper::copyFromBuffer for WaW hazards. It also includes a fix for a missing pipeline barrier after BufferVk::copyToBuffer. Bug: angleproject:2958 Change-Id: I3e61af56936580b2da20c28c45defece552d9a39 Reviewed-on: https://chromium-review.googlesource.com/c/1352732 Reviewed-by: Tobin Ehlis <tobine@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Jamie Madill 8dc27f99 2018-11-29T11:45:44 Use packed enum for DrawElementsType. The packing and unpacking take a few extra instructions. But it completely obviates the need for any switches in the validation code. Speed is slightly faster or the similar depending on the back-end. Also add gl_angle_ext.xml to GL entry point generator inputs. This was missing and would cause the code generation to miss certain changes. Bug: angleproject:2985 Change-Id: I1ea41a71db71135000166ead8305ec42d22ff7b3 Reviewed-on: https://chromium-review.googlesource.com/c/1351729 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Jamie Madill ae108bd1 2018-10-18T15:00:38 Use angle::Result in front-end (Part 5) Refactors gl::Buffer and implementation. Bug: angleproject:2491 Change-Id: Ic6860dac2faf33067965e7117ea8e98dc6a8dc7a Reviewed-on: https://chromium-review.googlesource.com/c/1283310 Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Jamie Madill 2d03ff4a 2018-09-27T15:04:26 Vulkan: Make Buffer/Image be CommandGraphResources. Don't make TextureVk/RenderbufferVk/SurfaceVk/BufferVk own the manipulation of the command graph. Instead put the operations close to the buffers and images used to render. This will lead towards implementing implicit barriers on the command graph resources. Bug: angleproject:2828 Change-Id: I07b742b6792c60285b280d6454f90e963d667e0e Reviewed-on: https://chromium-review.googlesource.com/1246983 Reviewed-by: Frank Henigman <fjhenigman@chromium.org> Reviewed-by: Geoff Lang <geofflang@chromium.org> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Jamie Madill 50e6eaae 2018-09-27T08:24:32 Vulkan: Move LineLoopHelper graph work into BufferVk. Bug: angleproject:2828 Change-Id: Ie6bcdd10e2de415615db2bfb0b6fa17c392455b0 Reviewed-on: https://chromium-review.googlesource.com/1235655 Reviewed-by: Geoff Lang <geofflang@chromium.org> Reviewed-by: Frank Henigman <fjhenigman@chromium.org> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Tobin Ehlis f5aad063 2018-09-19T14:39:00 Avoid flush/invalidate of host-coherent memory For DynamicBuffer avoid calling vkFlushMappedMemoryRanges() or vkInvalidateMappedMemoryRanges() if the underlying memory is host- coherent. These calls are not required for host-coherent memory and may negatively impact performance. When currently allocating HOST_VISIBLE memory it's possible to also get HOST_COHERENT memory even though it's not explicitly requested. Because of this, the change updates the memory allocaiton interfaces through the stack to pass back the actual allocated memory properties so that it can be checked to see if it's host-coherent. Bug: angleproject:2804 Change-Id: Ife95c4b98115b16d16c087dd72dba7d9661fdb46 Reviewed-on: https://chromium-review.googlesource.com/1234276 Commit-Queue: Tobin Ehlis <tobine@google.com> Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
Frank Henigman e452382a 2018-07-19T16:10:53 Vulkan: convert/align vertex data from buffers When we get a buffer with vertex data in an unsupported format or alignment, correct that as we copy it to a DynamicBuffer, then use the copy. Enable tests. BUG=angleproject:2405 Change-Id: I2132abea4d936f6b53d9209be7f99a0e2d8de219 Reviewed-on: https://chromium-review.googlesource.com/1141277 Commit-Queue: Frank Henigman <fjhenigman@chromium.org> Reviewed-by: Geoff Lang <geofflang@chromium.org>
Jamie Madill 21061026 2018-07-12T23:56:30 Vulkan: Use angle::Result error handling. Introduces a vk::Context class to contain an error handler and Renderer pointer. This abtracts the common code path for ContextVk + DisplayVk. Removes vk::Error in favor of the POD angle::Result class. There are a few remaining usages of gl::Error that will have to be cleaned up when we can change the front-end APIs. Bug: angleproject:2713 Change-Id: I5e68f223d595c6c561b59d6a85759e5738ed43c6 Reviewed-on: https://chromium-review.googlesource.com/1128924 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Frank Henigman <fjhenigman@chromium.org>
Luc Ferron a72ebeba 2018-06-28T11:16:58 Vulkan: Fix issue in DynamicBuffer - We weren't keeping track of mSize correctly, causing some very specific index buffer bindings to fail. The size returned when allocating the buffer can be a bit different than the size requested, and that extra space between mSize and the allocated size was not meant to be used, causing errors in the validation layers. Bug: angleproject:2580 Change-Id: I47eb7b8de6f4f657de14385b77ba6a459add599b Reviewed-on: https://chromium-review.googlesource.com/1118607 Reviewed-by: Geoff Lang <geofflang@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Luc Ferron <lucferron@chromium.org>
Luc Ferron 6ed167a9 2018-06-13T13:45:55 Vulkan: Implement conversion to uint16 for drawElements with ubytes Bug: angleproject:2646 Bug: angleproject:2659 Change-Id: If3c7a2b77d6acd18c8ca2522a427a43e10ed6db2 Reviewed-on: https://chromium-review.googlesource.com/1099420 Commit-Queue: Luc Ferron <lucferron@chromium.org> Reviewed-by: Geoff Lang <geofflang@chromium.org>
Jamie Madill 6c7ab7fe 2018-03-31T14:19:15 Vulkan: Reorganize helper classes. This renames ResourceVk to vk::CommandGraphResource, which should help clarify its usage. This also moves LineLoopHandler, ImageHelper, and the DynamicBuffer and DynamicCommandPool classes into a new vk_helpers module. This file contains helper classes that manage other resources. Also this makes DynamicBuffer and DynamicDescriptorPool no longer inherit from CommandGraphResource. In the future, only Impl objects will be allowed to be graph resources. Bug: angleproject:2318 Change-Id: I0fa23da2ac853d90f3c822547a4a314f247cc757 Reviewed-on: https://chromium-review.googlesource.com/985200 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Frank Henigman <fjhenigman@chromium.org>
Jamie Madill 0946393d 2018-04-04T05:26:59 Move Buffer Subject/Observer to front end. This makes BufferImpl into an Observer Subject. It also refactors the Vertex Array updates for the D3D11 backend use more of a dirty bit coding style. This change makes it so Buffer contents changes trigger front-end dirty bits from the back-end, which may be undesirable. Bug: angleproject:2389 Change-Id: Iac8ce1171284a86851c18cd1373ddf24fcefe40b Reviewed-on: https://chromium-review.googlesource.com/979812 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Luc Ferron 879f90d2 2018-03-01T11:45:20 Vulkan: Avoid recopying the data every time we draw line loops Use the Observer pattern to get notified when the BufferVk we've copied our data from is changing. We will only recopy the data if anything has changed, but otherwise we'll keep drawing with the same index buffer we've created previously. Bug: angleproject:2335 Change-Id: Ib65677b4d5ec90c46a5e3b975fffd1fddeed59e7 Reviewed-on: https://chromium-review.googlesource.com/948622 Commit-Queue: Luc Ferron <lucferron@chromium.org> Reviewed-by: Geoff Lang <geofflang@chromium.org>
Jamie Madill 3c424b48 2018-01-19T12:35:09 Vulkan: Add vk_cache_utils.h. This file contains the Pipeline and RenderPass cache utils. Also renames renderervk_utils.h to vk_utils.h and the format utils file. Refactoring change only. Bug: angleproject:2163 Change-Id: I5113a9a2c6f0b0960d38e6c2d8e391fa2d9f5f6a Reviewed-on: https://chromium-review.googlesource.com/876505 Reviewed-by: Frank Henigman <fjhenigman@chromium.org> Reviewed-by: Corentin Wallez <cwallez@chromium.org> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Corentin Wallez 336129f6 2017-10-17T15:55:40 Use a packed enum for buffer targets. BUG=angleproject:2169 Change-Id: I4e08973d0e16404b7b8ee2f119e29ac502e28669 Reviewed-on: https://chromium-review.googlesource.com/723865 Commit-Queue: Corentin Wallez <cwallez@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Jamie Madill 9776035d 2017-11-09T13:08:29 Vulkan: Implement Buffer updates. This allows the app to update Buffer data while the data is in use by the GPU. For instance, uploading new vertex attribute data after a draw call. It introduces a StagingBuffer helper class, similar to StagingImage. These classes are somewhat temporary and could be redesigned. BUG=angleproject:2200 Change-Id: If8634b1411779b16c2bd22cce18a5f37ed958d1c Reviewed-on: https://chromium-review.googlesource.com/756959 Reviewed-by: Frank Henigman <fjhenigman@chromium.org> Reviewed-by: Corentin Wallez <cwallez@chromium.org> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Jamie Madill 8724e254 2017-10-28T10:44:40 Vulkan: Fix re-creating buffer storage. BUG=angleproject:2200 Change-Id: Id60e857517cce9c0bfa272e4e6a399f236e395f7 Reviewed-on: https://chromium-review.googlesource.com/741548 Reviewed-by: Geoff Lang <geofflang@chromium.org> Reviewed-by: Corentin Wallez <cwallez@chromium.org> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Jamie Madill ba2eaea2 2017-10-13T14:09:34 Refactor vk::Buffer memory allocation. Add the code that finds the right memory information into a shared location. This will allow it to be reused with other points in the code. BUG=angleproject:2167 Change-Id: I72d0522e134666d0a00921cb5ef6bc093473afdf Reviewed-on: https://chromium-review.googlesource.com/717189 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Geoff Lang <geofflang@chromium.org>
Corentin Wallez 2e568cfb 2017-09-18T17:05:22 Add generator for packed GL enums. For testing this also converts two unimportant GLenums, gl::BufferUsage and gl::CullModeFace. BUG=angleproject:2169 Change-Id: If1e86a97d0fed3fd567303aca6506ec579503076 Reviewed-on: https://chromium-review.googlesource.com/688000 Commit-Queue: Corentin Wallez <cwallez@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Jamie Madill 33510107 2017-09-20T10:39:18 Pass gl::Context to more Buffer methods. This will allow us to pull out the Renderer from the Context in more places in Buffer11, for state update. Impacts a few method calls in a few places. BUG=angleproject:2151 Change-Id: I1360caea65a94d3de4cd9f52d1b74b10439b02b3 Reviewed-on: https://chromium-review.googlesource.com/673136 Reviewed-by: Geoff Lang <geofflang@chromium.org> Reviewed-by: Frank Henigman <fjhenigman@chromium.org> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Jamie Madill c564c070 2017-06-01T12:45:42 Pass gl::Context to impl methods instead of ContextImpl. In some cases we might have to call back into the GL layer, passing the Context, and if we just have a ContextImpl pointer this isn't possible. It also removes the need for SafeGetImpl. BUG=angleproject:2044 Change-Id: I6363e84b25648c992c25779d4c43f795aa2866d6 Reviewed-on: https://chromium-review.googlesource.com/516835 Reviewed-by: Corentin Wallez <cwallez@chromium.org> Reviewed-by: Geoff Lang <geofflang@chromium.org> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Jamie Madill 876429b7 2017-04-20T15:46:24 Update gl2.h and update entry points. Some method signatures were updated. Types like GLclampf and GLvoid were replaced with other equivalents. BUG=angleproject:1309 Change-Id: I05e8e2072c5a063d87ad96a855b907424661e680 Reviewed-on: https://chromium-review.googlesource.com/475011 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Geoff Lang <geofflang@chromium.org>
Jamie Madill 4c26fc2f 2017-02-24T11:04:10 Vulkan: Initial command queueing implementation. This removes the sychronous operation of the command buffers. It also introduces a serial type for assigning ids to queue operations. This gives us the ability to manage lifetimes of resources and track when they're no longer in use on the device. BUG=angleproject:1898 Change-Id: I91a4836d3098f1d7bd06cd389d88601a3a4826ab Reviewed-on: https://chromium-review.googlesource.com/428352 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Geoff Lang <geofflang@chromium.org>
Jamie Madill 5deea723 2017-02-16T10:44:46 Vulkan: Don't store device handles in wrapped objects. BUG=angleproject:1684 Change-Id: I0ec11ec79f2e9893600a8ffd8cdbfc6040fb6f70 Reviewed-on: https://chromium-review.googlesource.com/426402 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Jamie Madill 5f56ddb9 2017-01-13T17:29:55 Buffer: Pass Context to all impl methods. This allows us to retrieve Device handles for Vulkan, and could allow us to avoid storing some pointers for other back-ends. BUG=angleproject:1684 Change-Id: Iccd5b97cf1c3a332d62a38ad0fcf21c352270439 Reviewed-on: https://chromium-review.googlesource.com/426400 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Corentin Wallez <cwallez@chromium.org> Reviewed-by: Geoff Lang <geofflang@chromium.org>
Jamie Madill df68a6f0 2017-01-13T17:29:53 Vulkan: Implement a simple graphics pipeline. BUG=angleproject:1580 Change-Id: Iceaed896db22dc9eefa3f1bee7d6142fcfb20368 Reviewed-on: https://chromium-review.googlesource.com/412267 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Jamie Madill b8353b01 2017-01-25T12:57:21 Vulkan: Simple buffer creation. This is necessary to initialize vertex arrays. BUG=angleproject:1579 Change-Id: Ic5a232d5cdfaa75b41241901de842e62ff3b173f Reviewed-on: https://chromium-review.googlesource.com/406645 Commit-Queue: Jamie Madill <jmadill@chromium.org> Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Jamie Madill 8f775607 2016-11-03T16:45:34 Introduce a gl::BufferState class. This state can share vital pieces of information with the impl. The most elementary state is the buffer size, which then the impl doesn't need to replicate. BUG=angleproject:1579 Change-Id: I341393c64a6e49de65c1d53b1bad2fa143209862 Reviewed-on: https://chromium-review.googlesource.com/406644 Reviewed-by: Geoff Lang <geofflang@chromium.org> Reviewed-by: Corentin Wallez <cwallez@chromium.org> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Jamie Madill 29639857 2016-09-02T15:00:09 D3D11: Work around Intel uniform buffers bug. When copying from a staging buffer to a uniform buffer, the first upload would be incorrect. Work around this by trying to upload directly to a uniform buffer on the first BufferSubData call. BUG=chromium:593024 Change-Id: I0df3a1422b962bf3ece5d445f435df01e3544b67 Reviewed-on: https://chromium-review.googlesource.com/368774 Reviewed-by: Geoff Lang <geofflang@chromium.org> Reviewed-by: Corentin Wallez <cwallez@chromium.org> Commit-Queue: Jamie Madill <jmadill@chromium.org>
Jamie Madill 9e54b5af 2016-05-25T12:57:39 Add Vulkan stubs. Currently enabled for Windows by default. BUG=angleproject:1319 Change-Id: I87921c579bee466465fb1e3f629bb3a40fdff659 Reviewed-on: https://chromium-review.googlesource.com/328730 Reviewed-by: Corentin Wallez <cwallez@chromium.org> Commit-Queue: Jamie Madill <jmadill@chromium.org>