|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|