|
02292814
|
2023-06-01T14:46:05
|
|
Vulkan: Optimize the usage of FastMap in DescriptorSetDescBuilder
While looking at disassemble of
DescriptorSetDescBuilder::updateOneShaderBuffer() function, I noticed
that there are a lot of CPU cycles spent in FastMap::operator[]. What
happend here is that we are increasing size one by one as we build
descriptorSet, and that hit `if (mData.size() <= key)` case and we end
up resize the underline FastVector, and that resize also initialize the
element with zeros, which immediately overwrite by actual data. Since we
actually know the eventual size of
DescriptorSetDescBuilder::mDesc/mHandles/mDynamicOffsets, we could just
switch to angle::FastVector which will avoid this check size and grow
every time we write to it. This CL switches the use of FastMap in
DescriptorSetDescBuilder to FastVector. The only trick we need to watch
out is that previously the new elements are always zero filled and now
it does not. So we need to make sure we write every field of structure.
This CL also renames WriteDescriptorDescBuilder to WriteDescriptorDescs
since when it is read only we are passing it as const reference already,
there is no added advantage to have two classes.
Bug: b/282194402
Change-Id: I06a063cc51585fc17fbf0d5aa916b9aa0ab88dd4
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4581881
Reviewed-by: Roman Lavrov <romanl@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
2e209516
|
2023-06-26T11:58:50
|
|
Move state dirty bits definitions out of the class
This is in preparation for a follow up change that splits the state
class.
Bug: angleproject:8224
Change-Id: Ic9b253583e40fcc93ff37605b6b6e1deb55a6e55
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4631843
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
|
ec1f18db
|
2023-06-21T10:16:51
|
|
Vulkan: Remove ShaderVariableType and flatten info map
With the conversion of the interface variable info map keys to SPIR-V
ids, there is no longer a benefit to bucket resources by their type.
This change removes this bucketing and flattens the map.
Bug: angleproject:7220
Change-Id: If83cb02ca9e91f72dddb2deb7313fee40f9f06c3
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4632577
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
bbcf54bc
|
2023-06-16T16:02:08
|
|
Vulkan: Refactor uniform/block binding duplication code
Previously, resource binding assignment was done as such:
```
for each shader stage
assign bindings to textures
assign bindings to blocks
assign bindings to images
etc
```
To deduplicate bindings when the same resource was used in multiple
stages, a map was used, keyed by the resource's name, to detect when an
already visited resource is encountered in a future stage. This was
both inefficient and unnecessarily complicated.
With this change, resource binding assignment is done as such:
```
for each texture
assign one binding to all shader stages
for each block
assign one binding to all shader stages
for each image
assign one binding to all shader stages
etc
```
The aforementioned map is removed.
Because the resource bindings are now changed, the rest of the code
(which sets up the pipeline layout, updates descriptor sets, sets
dynamic buffer offsets, etc) are all updated to follow the above
pattern. As a result, nested loops are avoided and duplicate entries in
the variable map are never visited.
Bug: angleproject:7220
Change-Id: Iaff7b5f8b2bada8ac5078d21e5c790bf0d27aca7
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4622011
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
e21ecd1b
|
2023-05-26T14:06:46
|
|
Vulkan: Add dirty bit processing for uniform buffer change
When app calls glBufferData for the uniform buffer, we may end up
reallocate the storage. This will set DIRTY_BIT_UNIFORM_BUFFER_BINDINGS
on the context, but the exact uniform block index gets lost along the
way. This CL sets mDirtyBits on the program for the corresponding block
index and then changed vulkan backend to utilize the program's
mDirtyBits and only update the buffer if it is dirty, instead of always
update all uniform buffers even if only one of the buffer is dirty. In
order to make this work, this CL also adds the reverse tracking from
buffer binding to uniform blocks. Previously we already have the
tracking of which buffer binding index is used for which buffer block
index. This CL adds mUniformBlockBindingMasks which is an array of
BitSets. Each array element tracks all the uniform block index that is
using this buffer binding index (you can have the same buffer bound to
multiple uniform block index). Then when a buffer binding index is
dirty, that BitSet gets added into program's uniform block dirty bits.
This CL and previous CL improves GfxBench gl_driver2_off score 1.8%
(from average 6797 to average 6919) on pixel 7 pro.
Bug: b/282194402
Change-Id: Ic5002643a5297907276fc9b20ca7d21af9bdc4fe
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4553136
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Roman Lavrov <romanl@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
2501903e
|
2023-05-31T11:59:36
|
|
Vulkan: Merge UpdateShader***Buffers into updateShaderBuffers
Both UpdateShaderUniformBuffers() and
DescriptorSetDescBuilder::updateShaderBuffers() walks the list of
uniform blocks (or storage blocks). Some of the logic are the same and
we are paying that overhead twice. In this CL,
UpdateShaderStorageBuffers, UpdateShaderUniformBuffers and
UpdateShaderAtomicCounterBuffers functions are merged into
DescriptorSetDescBuilder::updateShaderBuffers and
DescriptorSetDescBuilder::updateAtomicCounters. In order to handle the
usage that same buffer used by multiple shader stages, a new variant of
bufferRead() function is added that takes "const gl::ShaderBitSet"
instead of single PipelineStage. This also paves way for next CL so
that we can call updateOneShaderBuffer individually.
Bug: b/282194402
Change-Id: I09d045d6295827b60bdb4c05df9333fe593fa40e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4574288
Reviewed-by: Roman Lavrov <romanl@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
b0e9bbd7
|
2023-05-31T14:23:40
|
|
Vulkan: Split features for dynamic state
When a driver bug with dynamic state is encountered, it is hard to debug
which dynamic state exactly is causing an issue, due to the current
granularity of disabling all entire state from an extension. With this
change, every dynamic state gets its own ANGLE feature, and can be
toggled as necessary.
Disabling the supportsExtendedDynamicState* features implicitly
disables all dependent features.
Bug: b/285124778
Bug: b/275210062
Bug: fuchsia:107106
Bug: angleproject:5906
Change-Id: Ic291279872df2d0eb58618ff364ab118bdcc4a9f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4577553
Reviewed-by: Cody Northrop <cnorthrop@google.com>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
ec7e0778
|
2023-05-26T22:11:49
|
|
Vulkan: Track the emulated texture buffer in command buffer
... instead of the original texture buffer, because the emulated one is
the one that is actually being used. This removes the necessity to
issue a hacky barrier after the emulation is done.
Bug: angleproject:8128
Change-Id: Ibc812894204cc1b2c6147817674de44e9c7ba2f4
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4571701
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Roman Lavrov <romanl@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
01f629e3
|
2023-05-26T10:23:20
|
|
Vulkan: Remove the loop when calling updateShaderBuffers
Right now there is a loop of getLinkedShaderStages when calling
mShaderBuffersDescriptorDesc.updateShaderBuffers. The shaderType
variable is only used to check if block is active or not, and get
info.binding. They can be retrieved without loop of shaderType. This CL
removes the loop so that we call
DescriptorSetDescBuilder::updateShaderBuffers only once. Similar thing
is applied to atomic counter buffer and images.
Bug: b/282194402
Change-Id: I03f3b4a391e773dfc162877802a2f940311866b8
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4554625
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
297687c6
|
2023-05-18T17:27:54
|
|
Vulkan: Reduce CPU overhead for uniform buffer change
One of the common usage pattern is change uniform buffers and draw.
Right now every uniform buffer change goes into ShaderResource dirty
code path that rebuilds entire ShaderResource cache key and descriptor
set etc. This CL keeps SHaderResource dirty code path, and will be used
when program changes or framebuffer changes. But uniform buffer change
will go down its own code path that only update uniform buffer related
state.
This CL along with prior two CLs reduced asphalt_9 average frame time
(with multi context hacked away) from 5.375 ms to 5.2594 ms (reduced
2.15%).
Bug: b/282194402
Change-Id: Ibae2895663918ddc10bf13bc559f1483f94d2e11
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4528314
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Roman Lavrov <romanl@google.com>
|
|
|
9445fbbe
|
2023-05-16T10:43:55
|
|
Vulkan: Move mWriteDescriptors out of DescriptorSetDescBuilder
DescriptorSetDescBuilder has two data structures: mWriteDescriptors,
which keeps track of "layout" of descriptorSet, and mDescriptorInfos,
which is the actual cache key for descriptorSet. mDescriptorInfos will
be updated every time buffer or image changes. But mWriteDescriptors is
immutable with buffer/image, it is static per program executable (with
exception of InputAttachment). Right now whenever there is a buffer or
image change, we call into DescriptorSetDescBuilder and update both
mWriteDescriptors and mDescriptorInfos. This CL moves mWriteDescriptors
out of DescriptorSetDescBuilder, and stores it in ProgramExecutableVk.
To deal with InputAttachment variation, ContextVk makes a copy of
mWriteDescriptors when program is bound, and then update inputAttachment
with framebuffer information. This not only removes unnecessary update
of mWriteDescriptors, but also removes the requirement that
mShaderBuffersDescriptorDesc has to reset and rebuild as a whole
(because mWriteDescriptors keeps mCurrentInfoIndex which gets
incremented as we build). This allows us to do further optimization in
future to do piece meal update of mDescriptorInfos with only the changed
data.
Bug: b/282194402
Change-Id: I443c7c3b85b7a2e2e93c68d40ea102533c43f76a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4540280
Reviewed-by: Roman Lavrov <romanl@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
2c836045
|
2023-05-18T12:00:41
|
|
Vulkan: Remove buffer/image tracking from DescriptorSetDescBuilder
Right now DescriptorSetDescBuilder keeps an array of images and buffers
as we build DescriptorSet cache key. Later on if we have a cache miss
and allocated a new cache entry, we walk the array and tag the images
and buffers with newSharedCacheKey. If we have a cache hit, the tracked
images/buffers are unused and then cleared. This means the effort of
keep track of these buffers are wasted when we have cache hit, which we
expect to be most likely. This was initially implemented this way simply
because of convenience, but there is really not a need to add another
tracker for them, as they are readily available from context state
anyway. This CL remove the tracking of images/buffers from
DescriptorSetDescBuilder and replaced with context API to tag images and
buffers with newSharedCacheKeywhen when we have a cache miss.
Bug: b/282194402
Change-Id: I355c2fbabdfc573ce71c0a4281788c942d260271
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4539290
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Roman Lavrov <romanl@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
934a25bc
|
2023-05-22T00:00:00
|
|
Vulkan: Implement EXT_depth_clamp
Bug: angleproject:8047
Change-Id: I73244f5dcd6eeeb1889214ee3a611e4ecabbfe7e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4558744
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
|
|
5ab2fa96
|
2023-05-12T08:38:19
|
|
Vulkan: Move texture QFOTs to syncState()
... (and getAttachmentRenderTarget() which is syncState()-like
for deferred clear) so that QFOTs are not actually scheduled until
first use. SurfaceFlinger optimistically creates EGL images and
textures for AHBs in case it does need them in the future.
However, the images and textures may go unused. Prior to this
change, ANGLE would create pending QFOT barriers while importing
AHBs into EGL images and GL textures. However, SurfaceFlinger may
not be doing any "real work" (other than repeatedly creating and
destroying EGL images and GL textures) which would result in the
command buffers containing the QFOTs being flushed. This can
result in a large build up of unreleased memory (as the
VkDeviceMemory would still be kept alive by the reference from
the unflushed QFOT command buffer) and lead to the low memory
killer nuking processes.
Bug: b/282075554
Test: cts -m CtsOpenGLTestCases
-t android.opengl.cts.GLSurfaceViewTest
Test: adb shell dumpsys SurfaceFlinger
Test: angle_end2end_tests
--gtest_filter=ImageTestES3.AHBImportReleaseStress/ES3_Vulkan
Change-Id: I7776abb2c6f834e96aa3926c26e77c53352ee561
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4527437
Commit-Queue: Jason Macnak <natsu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
086b6c20
|
2023-05-04T15:55:31
|
|
Vulkan: Simplify TransformFeedback buffer tracking
Right now the buffers that used by transform feedback is tracked by
mCurrentTransformFeedbackBuffers, which is angle::FlatUnorderedSet.
With the QueueSerial numbers, this can be much simplified. This CL
removes mCurrentTransformFeedbackBuffers. It adds a new QueueSerial
variable called mCurrentTransformFeedbackQueueSerial, and is inavlid if
no active transform feedback. Then check if a buffer is used by
transform feedback is as simple as check if it is written by
mCurrentTransformFeedbackQueueSerial. Since buffers are already tracked
by queue serial, so there is no new tracking needed. It is simply a
check if the buffer contains mCurrentTransformFeedbackQueueSerial or
not.
Bug: b/280889890
Change-Id: I54bdc4a0cfc7194a12d2aa0abdc67a3211949024
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4507978
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
903d9fdf
|
2023-01-19T15:37:45
|
|
Vulkan: Implement ExternalFence for use in SyncHelperNativeFence
`ExternalFence` allows concurrent usage in `CommandQueue` and
`SyncHelperNativeFence` classes eliminating need of additional
`vkQueueSubmit()` call.
Waiting in `CommandQueue` on `QueueSerial` or `ResourceUse` will ensure
corresponding state of the native FD (because `CommandQueue` will wait
on the same FD instead of some other fence).
After this change there will be only single `vkQueueSubmit()` call
from the `SyncHelperNativeFence::initializeWithFd()` method.
This CL and the follow-up is sufficient to fix the bugs below.
Bug: angleproject:8115
Bug: angleproject:8117
Test: angle_end2end_tests --gtest_filter=EGLSyncTest.AndroidNativeFence_ExternalFenceWaitVVLBug*
Change-Id: Ic562ecc71a95203454a1dc438589a13bcf3bff7f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4392879
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
72f9add4
|
2023-05-03T15:30:33
|
|
Vulkan: Initialize mLastSubmittedQueueSerial to valid value
Currently, ContextVk::mLastFlushedQueueSerial and
ContextVk::mLastSubmittedQueueSerial are invalid after Context
initialization. Although, invalid QueueSerial will always test as
submitted and finished, this produce a edge case. In case of
SyncHelper::mUse, we can not longer assert that mUse.valid() after
submitSyncIfDeferred() call, because invalid mUse is now a valid case...
This CL initializes both members to valid value, that will also always
test as submitted and finished. This removes the edge case, and allow
using assert in SyncHelper to check if everything works as expected.
Bug: b/277644512
Change-Id: I6be71596ab7dca1026764756fba7b21b81524413
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4503485
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
|
|
|
e24f4519
|
2023-01-19T02:30:39
|
|
Vulkan: Add externalFence into submitCommands()
Currently one-off fence in the `queueSubmitOneOff()` is used only in
`SyncHelperNativeFence::initializeWithFd()` to submit external fence.
Other `queueSubmitOneOff()` calls may use `QueueSerial` instead of a
fence.
Providing `fence` into `queueSubmitOneOff()` prevents tracking that
submission with `QueueSerial`. Therefore using `mUse` to collecting
`mFenceWithFd` as garbage will not work as intended.
This CL removes `fence` from `queueSubmitOneOff()` and adds
optional `externalFence` into `submitCommands()` instead.
Providing `externalFence` will cause additional `vkQueueSubmit()` call:
- first submission will submit everything as usual except using
the `externalFence`.
- second, will only submit internal `CommandQueue` fence for
`QueueSerial` tracking.
As the result of this CL, call to `initializeWithFd()` will always
produce two (2) `vkQueueSubmit()` calls. Previously it may be one (1) or
two (2) submissions. Future CL will reduce submission count to one (1).
If add additional submission into `queueSubmitOneOff()` instead of
`submitCommands()`, then maximum number of submissions will be
three (3).
Bug: angleproject:8117
Change-Id: I6f1ec12682aaab71bfc871e665fec2659df96b26
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4392877
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
|
|
|
b052a5bf
|
2023-03-31T00:00:00
|
|
Vulkan: Implement polygon mode extensions
* NV_polygon_mode
* ANGLE_polygon_mode
Bug: angleproject:1791
Bug: angleproject:8132
Change-Id: I2beffdad0c1569546020b78a9c6d9b8ea87c2100
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4498687
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
|
|
|
73f9cf00
|
2023-03-31T00:00:00
|
|
GL: Implement polygon mode extensions
* Implemented polygon mode extensions
on the OpenGL backend
* Supported capture and serialization
of the new commands and state
* Added PolygonModeTest end2end tests
Bug: angleproject:1791
Bug: angleproject:8132
Change-Id: I3bc08546a02f110dd739950129bee25ccc507bf6
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4492683
Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
90539b10
|
2023-04-24T16:36:01
|
|
Vulkan: Clean up some of trace events
CommandBuffer::begin/end/reset events are too fine grain. The trace
event retireFinishedCommandsLocked already covers reset.
Also made flushImpl generate event only if we did submit, if we end up
early out, that is not interesting.
Also add event for fenceWait, since that is quite important for
performance investigation, sometimes an indication of bad
synchronization.
Bug: b/277644512
Change-Id: I7d2f6d0716a83bf3b88a9e590ddc042b038b347a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4471747
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
b875f47b
|
2023-04-24T11:11:03
|
|
Vulkan: Make mLastSubmittedQueueSerial reflect what it means
Right now we always update ContextVk::mLastSubmittedQueueSerial and
ContextVk::mLastFlushedQueueSerial when context becomes current, even
though it does not make any submission. It was done it this way mainly
for simplification (i.e, you will always see both queueSerial's index
the same). But this also causes a performance cost when a
mLastSubmittedQueueSerial is used to tag a resource. For example, if you
insert a EGLSync right after makeCurrent, that EGLSync may get a queue
serial number bigger than it should be, which will translate to longer
sync wait time. This CL changes these two queue serial to exact what the
name suggests, that it will only update if we made a "flush" or "submit"
call.
Bug: b/277644512
Change-Id: Ibe4c78985a3fe0726836d620202e5276894a8e7c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4458532
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
ec04c40d
|
2023-04-24T23:12:09
|
|
Vulkan: Fix regression not calling mRenderer->notifyDeviceLost
Change:
Vulkan: Fix freeing not completed Secondary Command Buffers.
https://chromium-review.googlesource.com/c/angle/angle/+/4334579
.. accidentally removed `mRenderer->notifyDeviceLost();` line from
`ContextVk::handleDeviceLost()` method. This CL fixes that regression.
Bug: angleproject:6100
Change-Id: Iba3c9df71399821ac1b05109e873abfe5dc02bad
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4470307
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
e27759f9
|
2023-04-20T00:00:00
|
|
D3D11: Ignore sample mask and A2C for single-sampled rendering
Also fixed alpha-to-coverage for single-sampled
rendering and simplified sample coverage code
in the Vulkan backend.
Fixed: angleproject:8102
Change-Id: Ieea03dfdc13c6105ddf916dca6d0fea593eb3a62
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4455508
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
|
|
|
77d86c4a
|
2023-04-20T11:21:59
|
|
Vulkan: Set shading rate dynamic state unconditionally
Since this state is dynamic, it must be set before use.
Bug: angleproject:8108
Change-Id: I3ceeae95cdfad3388c35dd9e629e1424617f48b0
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4455148
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Yuxin Hu <yuxinhu@google.com>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
fa9172a3
|
2023-03-27T09:49:33
|
|
Reland "Vulkan: Use midRenderPass clear if RP has started but inactive"
This is a reland of commit 98151770adfd990c533991da27615b4879494307
Original change's description:
> Vulkan: Use midRenderPass clear if RP has started but inactive
>
> This CL extends prior CL's optimization so that if clear is issued right
> after blitFramebuffer call (this could make sense if blit and clear are
> on different buffer), we can keep the started render pass and do the
> midRenderPass clear instead of endRenderPass and start another
> renderPass.
>
> Bug: b/273808966
> Change-Id: Ia2504e8e260867a6f797d42cd4c8a72f187280ef
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4374145
> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Bug: b/273808966
Change-Id: I5c8c85c173f021a7753ef579f83d9ceb24147a7c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4442911
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
2f19bb74
|
2023-03-16T16:03:29
|
|
Reland "Vulkan: Reactivate already started render pass when possible"
This is a reland of commit ad9537af7f2bb5e22bc73f4e833fd3789adaa217
Original change's description:
> Vulkan: Reactivate already started render pass when possible
>
> In some usage case (such as lineage_mobile), we are seeing in the middle
> of render pass, app switch to another fbo just to issue a glClear()
> call, which the clear call itself gets deferred. Application then switch
> back to the original frame buffer. Before this CL, the render pass gets
> recreated due to frame buffer binding change, even though the clear gets
> deferred and new render pass and the previous render pass are
> essentially the same. This CL detects this situation and reactivate the
> current render pass instead of creating a new one. With this CL,
> lineage_m app trace reduces frame time from 3.86ms to 3.7ms, and only
> one render pass is used instead of two.
>
> This CL also allows the render pass started by BlitFramebuffer reused by
> subsequent draw calls. Asphalt_9 is hitting this use pattern and this CL
> reduces frame time by 0.1245 ms (from 5.6203 ms to 5.4958 on pixel 7
> pro)
>
> Bug: b/273808966
> Change-Id: I48c2671cbef3ff9d6cf59caae88c37c77828ee07
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4348713
> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
> Commit-Queue: Charlie Lao <cclao@google.com>
Bug: b/273808966
Change-Id: Ice9062122ae320b1a0108ff981bc65bd13b2ada0
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4406888
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
459f0fad
|
2023-04-06T13:42:49
|
|
Vulkan: Force submit when switch to system framebuffer draw
Given recent finding on unnecessary wait for acquire image semaphore,
since the semaphore wait is per submission, any GPU will have this same
performance problem if we only do command submit per frame. This CL
forces submission when we switch draw framebuffer to system default
framebuffer, so that the semaphore wait will not block user's fbo
rendering.
Bug: b/275624771
Change-Id: Id6b941870ef296393c13d0daaf81a41b6c042b9a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4406882
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
d58fbf04
|
2023-04-05T12:32:09
|
|
Vulkan: Wait for surface ANI semaphore only if image is used
Right now there is a bug that surface's ANI semaphore is added to
context when WindowSurfaceVk::getAttachmentRenderTarget get called,
which gets called from FramebufferVk::syncState, which is before we end
the previous render pass, due to the endRenderpass usually is deferred
until next renderPass starts. This caused ANI semaphore gets added to
the previous render pass's submission, which does not use surface, and
thus a bubble in GPU execution pipeline where the user FBO rendering
gets unnecessarily blocked until ANI semaphore is signaled. This lowers
GPU utilization and thus GPU frequency gets dropped and frame time
increased. This CL stores ANI semaphore to ImageHelper object and when
barrier is generated, the ANI semaphore is moved to CommandBuffer. When
CommandBuffer gets flushed and submitted, it gets added to the
waitSemaphores vector and submitted to vulkan. Since all use of swap
chain image must go through barrier code first (you need at least change
layout), this ensures ANI semaphore gets waited in exact and robust way.
Only the submission that references the swap chain image will be waited.
With this CL, professional_baseball_spirits reduces frame time from 3.8
ms to 2.7 ms, achieving parity with native GLES on pixel 7 pro.
Bug: b/275624771
Change-Id: Ifa6cacf9e3bc147bfde54eb7def2fca48c50aca0
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4400011
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
65ed3050
|
2023-04-04T11:57:38
|
|
Vulkan: Let recordWriteBarrier use CommandBufferHelper
This is preparation for next CL. It changes
OutsideRenderPassCommandBuffer argument to
OutsideRenderPassCommandBufferHelper for recordWriteBarrier() and
recordReadBarrier() calls, so that it has access to the helper object
(will be used in next CL). It passes CommandsState to executeBarriers()
instead of PrimaryCommandBuffer. No actual functionality change is
expected.
Bug: b/275624771
Change-Id: Ia06a0398a127539b0b642005803a498cb2a9d7f1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4400407
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
20f875f8
|
2023-04-05T09:47:46
|
|
Vulkan: Add commandQueueWaitSemaphoresTotal perf counter
This counts total number of wait semaphores we submitted. This will be
used to write test to ensure that we insert wait semaphores properly in
future CLs.
Bug: b/275624771
Change-Id: I5b8e209500ff553617f6b30c2f8b4626d29c0e6a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4400823
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
8b79410b
|
2023-04-02T22:25:12
|
|
Vulkan: Treat readonly SSBOs as readonly!
Instead of assuming SSBOs are always written to, this change adds
plumbing for the backend to know when an SSBO is declared readonly and
marks the buffer readonly accordingly.
With this change, BufferVk can optimize uploads and copies to and from
the buffer with the knowledge that it can be safely mapped on the CPU
for read while it's being used by the GPU.
Bug: b/276002151
Change-Id: I75342148c07949a83436054a738395bbd88caec5
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4392720
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
41f0a321
|
2023-04-03T21:58:43
|
|
Revert "Vulkan: Reactivate already started render pass when possible"
This reverts commit ad9537af7f2bb5e22bc73f4e833fd3789adaa217.
Reason for revert: Suspected cause for flakiness. anglebug.com/8118
Original change's description:
> Vulkan: Reactivate already started render pass when possible
>
> In some usage case (such as lineage_mobile), we are seeing in the middle
> of render pass, app switch to another fbo just to issue a glClear()
> call, which the clear call itself gets deferred. Application then switch
> back to the original frame buffer. Before this CL, the render pass gets
> recreated due to frame buffer binding change, even though the clear gets
> deferred and new render pass and the previous render pass are
> essentially the same. This CL detects this situation and reactivate the
> current render pass instead of creating a new one. With this CL,
> lineage_m app trace reduces frame time from 3.86ms to 3.7ms, and only
> one render pass is used instead of two.
>
> This CL also allows the render pass started by BlitFramebuffer reused by
> subsequent draw calls. Asphalt_9 is hitting this use pattern and this CL
> reduces frame time by 0.1245 ms (from 5.6203 ms to 5.4958 on pixel 7
> pro)
>
> Bug: b/273808966
> Change-Id: I48c2671cbef3ff9d6cf59caae88c37c77828ee07
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4348713
> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
> Commit-Queue: Charlie Lao <cclao@google.com>
Bug: b/273808966
Change-Id: I81cc2dcacb52466808b2ccf5819feda466c39fc5
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4396502
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
3aea3cfd
|
2023-04-03T16:38:29
|
|
Vulkan: Workaround depth bias constant factor on ANV
Bug: b/249380591
Change-Id: Iaeda7faf5eb40e0e2086674d3e63bf5bc9911ab4
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4392893
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
c5e9de23
|
2023-04-03T15:14:03
|
|
Revert "Vulkan: Use midRenderPass clear if RP has started but inactive"
This reverts commit 98151770adfd990c533991da27615b4879494307.
Reason for revert: Suspected cause for flakiness. anglebug.com/8118
Original change's description:
> Vulkan: Use midRenderPass clear if RP has started but inactive
>
> This CL extends prior CL's optimization so that if clear is issued right
> after blitFramebuffer call (this could make sense if blit and clear are
> on different buffer), we can keep the started render pass and do the
> midRenderPass clear instead of endRenderPass and start another
> renderPass.
>
> Bug: b/273808966
> Change-Id: Ia2504e8e260867a6f797d42cd4c8a72f187280ef
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4374145
> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Bug: b/273808966
Change-Id: I7a11635a6eceafb6f4fb3a0d95f6627ee98321c0
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4393497
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
b24b5568
|
2023-03-27T00:00:00
|
|
Vulkan: Skip sample coverage for single sample rendering
A new test sets sample coverage to zero and checks
that it is applied only to multisampled rendering.
Bug: angleproject:8102
Change-Id: I1a5649869e9b7ecf0543108fb99095bfaf6fd858
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4379839
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
|
|
|
98151770
|
2023-03-27T09:49:33
|
|
Vulkan: Use midRenderPass clear if RP has started but inactive
This CL extends prior CL's optimization so that if clear is issued right
after blitFramebuffer call (this could make sense if blit and clear are
on different buffer), we can keep the started render pass and do the
midRenderPass clear instead of endRenderPass and start another
renderPass.
Bug: b/273808966
Change-Id: Ia2504e8e260867a6f797d42cd4c8a72f187280ef
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4374145
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
ad9537af
|
2023-03-16T16:03:29
|
|
Vulkan: Reactivate already started render pass when possible
In some usage case (such as lineage_mobile), we are seeing in the middle
of render pass, app switch to another fbo just to issue a glClear()
call, which the clear call itself gets deferred. Application then switch
back to the original frame buffer. Before this CL, the render pass gets
recreated due to frame buffer binding change, even though the clear gets
deferred and new render pass and the previous render pass are
essentially the same. This CL detects this situation and reactivate the
current render pass instead of creating a new one. With this CL,
lineage_m app trace reduces frame time from 3.86ms to 3.7ms, and only
one render pass is used instead of two.
This CL also allows the render pass started by BlitFramebuffer reused by
subsequent draw calls. Asphalt_9 is hitting this use pattern and this CL
reduces frame time by 0.1245 ms (from 5.6203 ms to 5.4958 on pixel 7
pro)
Bug: b/273808966
Change-Id: I48c2671cbef3ff9d6cf59caae88c37c77828ee07
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4348713
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
97897d92
|
2023-03-27T16:02:57
|
|
Vulkan: Work around driver bug with dynamic primitive restart
This CL forces the state to be static on buggy drivers.
Bug: b/275210062
Change-Id: Ia3391ecb19c3c9d19c05a83e11da8c718513a4e2
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4374104
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@google.com>
|
|
c6ec59dc
|
2023-03-27T11:15:48
|
|
Explicitly pass the extended dirty bits to syncState.
Add a the extended dirty bits and bit mask to syncState instead of
calling gl::State::getAndResetExtendedDirtyBits when encountering
DIRTY_BIT_EXTENDED. It disallowed us from masking the extended dirty
bits and feels like an anti-pattern to modify the extended dirty bits
in gl::State from the backend.
This is a refactor only.
Bug: chromium:1410191
Change-Id: I66fdec3eb57e3426cf0fda9ccb759700eafdda14
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4374100
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
e27e7c6a
|
2023-03-17T19:43:54
|
|
Vulkan: Retire Command Buffers before destroying the Pools.
"VulkanSecondaryCommandBuffer"s may be still in "CommandQueue" when
"ContextVk" destroys the Command Pools (asyncCommandBufferReset = true).
Fixed by calling "retireFinishedCommandsLocked()" when appropriate.
Normally, it is only required to retire Vulkan Secondary Buffers.
However, some drivers may have bug and also require to reset
Primary Buffers, that have Secondaries recorded, before destroying the
Secondaries Pools.
Bug: angleproject:6811
Bug: angleproject:6100
Change-Id: I891547c95cfbdfab44398980f939596af56ab57b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4350269
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
9524c639
|
2023-01-17T18:47:47
|
|
Vulkan: Fix Secondary Command Buffers with asyncCommandQueue.
This change fixes following errors (asyncCommandQueue = true):
1. "vkEndCommandBuffer()" called from "asyncCommandQueue" thread.
Call stack:
vkEndCommandBuffer()
VulkanSecondaryCommandBuffer::end()
OutsideRenderPassCommandBufferHelper::flushToPrimary()
CommandQueue::flushOutsideRPCommands()
CommandProcessor::processTask()
Fixed by calling "vkEndCommandBuffer()" from the Context thread
in the new "OutsideRenderPassCommandBufferHelper::detachCommandPool()"
method.
2. "vkAllocateCommandBuffers()/vkBeginCommandBuffer()" called from
"asyncCommandQueue" thread.
Call stack:
vkAllocateCommandBuffers()/vkBeginCommandBuffer()
VulkanSecondaryCommandBuffer::initialize()
<*>CommandBufferHelper::initializeCommandBuffer()
<*>CommandBufferHelper::reset()
<*>CommandBufferHelper::flushToPrimary()
CommandQueue::flush<*>Commands()
CommandProcessor::processTask()
Fixed by calling "vkAllocateCommandBuffers()/vkBeginCommandBuffer()"
from the Context thread in the new
"<*>CommandBufferHelper::attachCommandPool()" method.
3. "SecondaryCommandPool::collect()" called from "asyncCommandQueue"
thread without synchronization.
Call stack:
SecondaryCommandPool::collect()
rx::vk::RecycleCommandBufferHelper()
CommandBufferRecycler<>::recycleCommandBufferHelper)
RendererVk::recycle<*>CommandBufferHelper()
CommandProcessor::processTask()
No need for this call, because "SecondaryCommandPool" is already
detached.
Notes:
This CL not only fixes errors, but also optimizes CommandBufferHelper
recycling. Before, there was no recycling plus unnecessary
"VulkanSecondaryCommandBuffer" allocation/freeing.
Further optimization may add multiple "VkCommandPool"s to the
"SecondaryCommandPool" to allow resetting buffers in the async thread.
Bug: angleproject:6811
Bug: angleproject:6100
Change-Id: I7004c27a112e916c5c973b43b137193017d6aa3d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4342189
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
|
|
f2c5ce4e
|
2023-03-16T17:44:56
|
|
Re-enable mutable texture upload for one context
It was observed that in some apps, mutable textures are uploaded in a
context, but that context's outside RP command buffer is not flushed
at all, resulting in invalid (noise) or incorrect textures.
* Added isEligibleForMutableTextureFlush() to be used to determine
whether onMutableTextureUpload() should be called.
* Restricted the use of mutable texture upload to single-context
share groups.
* When the number of contexts becomes greater than one, the original
context's outside render pass command buffer is flushed.
* Added related tests.
* Added a test to make sure that textures can be uploaded in one
thread, and used for draw calls in another, with the help of a
sync object.
* Added a test to make sure that textures can be uploaded in the
main thread, and used in a new thread.
* Added a test in which a new context is created after mutable
mipmap textures are defined.
Bug: b/264143971
Change-Id: I66c0d8b04d39bb7244e5752aac0e46a0192f012e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4349156
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
e809e7bd
|
2023-03-13T00:00:00
|
|
Reland "Implement EXT_depth_clamp"
This is a reland of commit f8c1418319ac2aef4b3101e322005b1d0f73120f
Host GPU bugs are observable in iOS Simulator
Original change's description:
> Implement EXT_depth_clamp
>
> * Added depthClamp to the RasterizerState
> * Added DepthWriteTest end2end tests covering
> both clipped and clamped depth writes
>
> Capture
> * Updated serialized rasterizer state
> * Updated CaptureMidExecutionSetup
>
> OpenGL
> * Requires GL 3.2 or ARB_depth_clamp
> on desktop contexts
> * Maps to EXT_depth_clamp on ES
>
> D3D11
> * Maps to the opposite of
> D3D11_RASTERIZER_DESC.DepthClipEnable
> * The new tests uncover several edge cases where
> a workaround is needed to implement unextended
> OpenGL semantics on top of D3D
>
> Metal
> * Maps to the setDepthClipMode command
>
> Bug: angleproject:8047
> Bug: angleproject:8077
> Change-Id: I1b3448e5b84443e4be18af9bc22d2f8495ac8267
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4347753
> Reviewed-by: Geoff Lang <geofflang@chromium.org>
> Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
Bug: angleproject:8047
Bug: angleproject:8077
Change-Id: I8c5f8304276c97c51b2c3382cd2764592ee0c3fe
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4349938
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
|
|
4a77b0f5
|
2023-03-18T00:16:24
|
|
Revert "Implement EXT_depth_clamp"
This reverts commit f8c1418319ac2aef4b3101e322005b1d0f73120f.
Reason for revert: This change breaks angle_end2end_tests on Metal backend: https://ci.chromium.org/ui/p/chromium/builders/ci/ios-angle-intel/26035/overview
Original change's description:
> Implement EXT_depth_clamp
>
> * Added depthClamp to the RasterizerState
> * Added DepthWriteTest end2end tests covering
> both clipped and clamped depth writes
>
> Capture
> * Updated serialized rasterizer state
> * Updated CaptureMidExecutionSetup
>
> OpenGL
> * Requires GL 3.2 or ARB_depth_clamp
> on desktop contexts
> * Maps to EXT_depth_clamp on ES
>
> D3D11
> * Maps to the opposite of
> D3D11_RASTERIZER_DESC.DepthClipEnable
> * The new tests uncover several edge cases where
> a workaround is needed to implement unextended
> OpenGL semantics on top of D3D
>
> Metal
> * Maps to the setDepthClipMode command
>
> Bug: angleproject:8047
> Bug: angleproject:8077
> Change-Id: I1b3448e5b84443e4be18af9bc22d2f8495ac8267
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4347753
> Reviewed-by: Geoff Lang <geofflang@chromium.org>
> Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
Bug: angleproject:8047
Bug: angleproject:8077
Change-Id: I829add68c006c72b7b4acf03aee3efa8a9a16fac
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4350876
Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Yuxin Hu <yuxinhu@google.com>
|
|
|
7d1a401b
|
2023-01-17T18:45:55
|
|
Vulkan: Fix freeing not completed Secondary Command Buffers.
Problem:
- Protected Context flushes its commands to the Protected
Primary Command Buffer;
- Unprotected Context flushes its commands to the Unprotected
Primary Command Buffer;
- Context with different "egl::ContextPriority" may flush commands
into different Primary Command Buffers.
- Secondary Command Buffers from all Contexts end-up in the single
"CommandBufferRecycler::mSecondaryCommandBuffersToReset" list;
- One of the Contexts submits its Primary Command Buffer, and attaches
current "mSecondaryCommandBuffersToReset" list to the "CommandBatch";
- Secondary Command Buffers of other Contexts may be collected and
later freed by "SecondaryCommandPool" without submitting/completion
corresponding Primary Command Buffers.
Fix:
- Moving "mSecondaryCommandBuffersToReset" to the new
"SecondaryCommandBufferCollector" class.
- Separate "SecondaryCommandBufferCollector" instance is stored
in the "CommandQueue" for each current Primary Command Buffer.
Additionally fixes "asyncCommandQueue" related problem:
"releaseCommandBuffersToReset()" may get outdated results if flush is
not yet executed in the "asyncCommandQueue" thread.
Bug: angleproject:6100
Change-Id: I7df161ac1f999fb34d4eccaebb603c58ecb1ac11
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4334579
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
|
|
|
9b6368cc
|
2023-03-14T14:48:30
|
|
Vulkan: Fix freeing Secondary Command Buffers from wrong thread.
Problem:
- Secondary Command Buffers are freed in the "CommandQueue" class.
- This may happen from any Context thread that calls
"checkCompletedCommands()" or "finish<*>()" methods.
- As the result, one Command Buffer may be freed from one thread, while
other Command Buffer from the same "VkCommandPool" is
allocated/reset/recorded in the other thread.
Vulkan spec demands external "VkCommandPool" synchronization for any
modifications (begin/end/reset/free/cmd) on its "VkCommandBuffer"s.
Fix:
- Added new "rx::vk::SecondaryCommandPool" class that replaces the
"rx::vk::CommandPool" wrapper.
- This class has "collect()" method for storing "VkCommandBuffer"s.
Collected buffers are freed from the correct thread on the next
"allocate()" call.
This CL only fixes the problem, keeping Secondary Command Buffer memory
management as is (allocate/free single buffer without reuse).
In the future CLs this behavior may be changed (reuse buffers,
reset/free entire pools).
Bug: angleproject:6100
Change-Id: If938416c4df4fe55f0cfb418b6759721ac53098b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4334577
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
f8c14183
|
2023-03-13T00:00:00
|
|
Implement EXT_depth_clamp
* Added depthClamp to the RasterizerState
* Added DepthWriteTest end2end tests covering
both clipped and clamped depth writes
Capture
* Updated serialized rasterizer state
* Updated CaptureMidExecutionSetup
OpenGL
* Requires GL 3.2 or ARB_depth_clamp
on desktop contexts
* Maps to EXT_depth_clamp on ES
D3D11
* Maps to the opposite of
D3D11_RASTERIZER_DESC.DepthClipEnable
* The new tests uncover several edge cases where
a workaround is needed to implement unextended
OpenGL semantics on top of D3D
Metal
* Maps to the setDepthClipMode command
Bug: angleproject:8047
Bug: angleproject:8077
Change-Id: I1b3448e5b84443e4be18af9bc22d2f8495ac8267
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4347753
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
|
|
|
4edccb15
|
2023-01-17T16:17:35
|
|
Vulkan: Fixed Context Priority mixing problems.
Problem details:
- Each "egl::ContextPriority" may have separate "VkQueue".
- "CommandQueue" only has two "PrimaryCommandBuffer"s for normal
and protected content.
- Commands from multiple "ContextVk" may be written
to a single "PrimaryCommandBuffer".
- That "PrimaryCommandBuffer" may be randomly submitted
to different "VkQueue"s.
- As the result - Commands from a single "ContextVk" may be submitted
to multiple "VkQueue"s.
Fix details:
- Created separate "PrimaryCommandBuffer" (lazily allocated)
for each "egl::ContextPriority".
- Commands with different priorities can't be mixed
in a single "PrimaryCommandBuffer".
- Therefore - Commands from a single "ContextVk" will be submitted
to a single "VkQueue".
- No difference for applications that use single "egl::ContextPriority"
for all Contexts.
Notes:
Another problem when resource is used in multiple Contexts with
different "VkQueue" (Priority).
One solution is to use Semaphores.
Another is to enfore same Priority for all Contexts in a Share Group
and Default Priority when using EGLImage.
This solution was submitted in the previous CL:
Vulkan: Enforce ContextPriority in ShareGroup and with EGLImage
Below test fails on G996B without this CL.
Bug: angleproject:8039
Test: angle_end2end_tests --gtest_filter=MultithreadingTestES3.ContextPriorityMixing*
Change-Id: Iaa57826ca55956944f922813fcfac42f1a764dbb
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4194183
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
eb1cb31d
|
2023-02-21T14:09:49
|
|
Vulkan: Remove code left after introduce of "vk::SharedGarbage"
This logic calls "flushImpl()" each time some "ImageVk" is orphaned,
regardless if it used in the RenderPass or not. Such undesired flushes
negatively affect CPU and GPU performance.
This flush was added in the very old commit:
e755a5374f7eb24da579fdc9862b01e3c3c04721
Vulkan: Add a new garbage type gated by fences.
Flush was necessary to grab a proper Fence.
However, after commit:
f10bf6bf55a78669bff7bb5cdd3ae0954a87661e
Vulkan: Implement multi-threaded GL.
Fence was replaced by "vk::SharedGarbage" and "vk::SharedResourceUse".
But "flushImpl()" was not removed along with misleading comment, that
it is necessary "to make sure the fence has been submitted".
This CL removes this leftover code. Any regressions should be fixed in
a better way.
Bug: angleproject:2464
Change-Id: I640bb2b9519c15a47adf30e0de845a3125ceab42
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4272834
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
|
a1bf828d
|
2023-02-13T21:30:38
|
|
Vulkan: Rename "RendererVk::waitFor*ToBeSubmitted()" methods.
Following "RendererVk" methods are a little bit confusing:
- submitCommands()
- hasResourceUseSubmitted()
- hasQueueSerialSubmitted()
- waitForResourceUseToBeSubmitted()
- waitForQueueSerialToBeSubmitted()
Because after "RendererVk::submitCommands(..., submitQueueSerial)" call
"hasQueueSerialSubmitted(submitQueueSerial)" will always return "true".
And it is not clear why need to call "waitForResourceUseToBeSubmitted()"
method, if it already "Submitted". It is even more: it is technically
illegal to call "waitFor*ToBeSubmitted()" if "has*Submitted" is "false".
This refactoring suggests adding "ToDevice" to the methods names:
- waitForResourceUseToBeSubmittedToDevice()
- waitForQueueSerialToBeSubmittedToDevice()
So that:
- "Submitted" - will mean to the RendererVk (and maybe Device)
- "SubmittedToDevice" - definitely submitted to the Device.
Bug: b/267348918
Change-Id: I12323be3ddc0cbcff4667e52a37089b187b63fe8
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4245423
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
|
|
|
b194c21a
|
2023-02-24T15:41:00
|
|
Vulkan: Enforce ContextPriority in ShareGroup and with EGLImage
This CL enforces single Context Priority for all Contexts in a Share
Group. This is necessary until Vulkan Semaphores will be used to
automatically synchronize Resource access between Contexts.
Contexts Priority updated when new Contexts is added to the Share Group.
New Priority will be the highest among all ever existed Contexts
(except if Priority is locked).
When Contexts Priority changes, all flushed commands are submitted to
the old VkQueue and semaphore is inserted into the new VkQueue.
Currently opened RenderPasses and commands will not be flushed.
When EGLImage is used in a Context, all Contexts in that Share Group
locked (forever) to the Default Priority (Medium). This is done to
simplify the implementation and because of the current limitations
(lack of mutex protection across Context Share Groups).
Notes:
- the EGL_CONTEXT_PRIORITY_LEVEL_IMG will report initial priority.
- below tests fail on G996B without this CL.
Bug: angleproject:8039
Test: angle_end2end_tests --gtest_filter=MultithreadingTestES3.RenderThenSampleDifferentContextPriority*
Test: angle_end2end_tests --gtest_filter=MultithreadingTestES3.RenderThenSampleInNewContextWithDifferentPriority*
Test: angle_end2end_tests --gtest_filter=MultithreadingTestES3.RenderThenSampleDifferentContextPriorityUsingEGLImage*
Change-Id: Ia6a2f0084d39168a58fd7ec33edc90ece9cead05
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4289750
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
|
|
|
244e1931
|
2023-01-17T19:22:10
|
|
Vulkan: Fix use of pending Outside RenderPass CommandBuffer.
Regression from this commit:
730c127102b540ce2c4ec086b037c8b732706e26
"Vulkan: Submit queue more often for texture data"
Bug: angleproject:6354
Test: angle_end2end_tests --gtest_filter=*SubmittingOutsideCommandBufferAssertIsOpen*
Change-Id: I5f72f499cd7153c94c8e5f8a3415df2182726c8e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4296802
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
b0d99f72
|
2023-02-22T13:48:16
|
|
Move the memory tracking classes to new files
* Moved the classes, functions, and constants related to memory
tracking to MemoryTracking.h and MemoryTracking.cpp. Main classes
include the following:
* MemoryAllocationTracker
* MemoryReport
* MemoryAllocationType
* MemoryAllocationInfo
* MemoryLogSeverity
* New static function added in RendererVk to get the Vulkan object
type name (GetVulkanObjectTypeName()).
Bug: b/262029018
Change-Id: I619001e3c24114c4fe7bf024498338bce146fced
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4284639
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
1174582a
|
2023-03-06T00:00:00
|
|
GL: Implement EXT_clip_control
The extension is trivially exposed
if the current context supports it.
* Added packed clip control enums
* Removed unused state query code
* Aligned symbol names with the specs
Bug: angleproject:8066
Change-Id: I9d106f39800658ecc75f4525ee93cb534dc49f9e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4306770
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
7eb6869a
|
2022-08-30T16:28:08
|
|
Vulkan: Change ResourceAccess::Write to ResourceAccess::ReadWrite
AS a preparation for the next CL which will optimize for WriteOnly
access, this CL changes Write to ReadWrite and adds WriteOnly access
(but not used yet). Mechanical changes only and no function difference
is expected.
Bug: b/243711628
Change-Id: I509d6045ae87635e24076b646af42f35d88d52cf
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3866672
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
fee173f9
|
2023-01-17T18:45:41
|
|
Vulkan: Fix freeing Command Buffers with wrong Pool.
Problem:
- Multiple Contexts flushes it's commands to the Primary Command buffer;
- Secondary Command Buffers from all Contexts end-up in the single
"CommandBufferRecycler::mSecondaryCommandBuffersToReset" list;
- One of the Contexts submits all these commands, and attaches
it's "VkCommandPool" to the "CommandBatch".
- This "VkCommandPool" will be used to free "VkCommandBuffer"s
from all Contexts and pools.
Fix:
- Attaching "VkCommandPool" to each "VulkanSecondaryCommandBuffer"
instance.
- "vkFreeCommandBuffers()" is called from the new
"VulkanSecondaryCommandBuffer::free()" method.
Bug: angleproject:6100
Change-Id: Ic4d66d8b0f71e5ff06047004ed21428d6dce385b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4300870
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
24eb3fcf
|
2023-01-17T19:26:49
|
|
Vulkan: Condition in "collectGarbage()" replaced with "ASSERT".
Very minor optimization.
Most places already check for empty garbage before calling
"RendererVK::collectGarbage()".
Added missing check into "ContextVk::submitCommands()".
Bug: None
Change-Id: Ie2660b4cc413e17c4b6ba39c0711745e9f48d70d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4300052
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
7189e4cf
|
2023-02-23T11:03:40
|
|
vulkan: fix depth buffer renderpass loadOp issue.
when change the depth compare function, Renderpass need to
change the mAcess flag accordingly.
Bug: b/269929460
Change-Id: I83826c1b07c6d22600d6cd039e7d8bfd0b5b39c3
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4284624
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Hailin Zhang <hailinzhang@google.com>
|
|
|
057a92bf
|
2023-02-20T14:45:36
|
|
Vulkan: Fix invalid assert in ContextVk::onSurfaceUnMakeCurrent
Old assert checked "mHasWaitSemaphoresPendingSubmission". However this
will be true even after "mWaitSemaphores" are flushed to the Renderer.
Correct assert is to check that everything is flushed, but may be
pending submission.
Bug: angleproject:8017
Change-Id: I831ece236fb0cecb8520315ebaa5207f90d3dfc6
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4270931
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
05e62f39
|
2023-02-16T23:16:46
|
|
Vulkan: Don't close render pass if rebind to same fbo
In the Vulkan backend, the render pass can occasionally (and
transiently) be in a state of "open but inactive". This is when the
render pass is closed, but has the potential for future modifications
(for example to add a resolve attachment). Under many circumstances, it
is expected that an open render pass cannot be in such a state.
This assumption can be broken in this scenario:
- Open render pass, draw, etc
- Change framebuffer binding
- Change framebuffer binding back to original
- Masked Clear
When ContextVk is synced before clear, it sees that the framebuffer
binding is changed (though it hasn't really), and it closes the render
passes and sets the render pass dirty bit. If a draw were to follow, a
new render pass would have started (unnecessarily). However, in the
case of a masked clear, UtilsVk notices that the render pass is started,
assumes it must be active, and continues recording to it. While the
operation itself succeeds, the assumption that the render pass is active
is false (and fails assertion).
This change makes sure that framebuffer binding change is no-oped if the
framebuffer is the same one that has opened the current render pass. If
any application does unnecessary binding changes and back, it will be
optimized by this change as well.
Bug: chromium:1411210
Change-Id: I37a3a9f2eaa1a81a1b3393840b9458ec71a87377
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4261215
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
c402ea1c
|
2023-02-15T12:01:38
|
|
Vulkan: Rename hasUnfinishedUse to hasResourceUseFinished
Most usage of hasUnfinishedUse is for !hasUnfinishedUse, and there was
feedback that negative API is not preferred. This CL changes it to
positive API name. Similarly renamed hasUnsubmittedUse to
hasResourceUseSubmitted.
Bug: b/267348918
Change-Id: Idb10b0f998ec50116ffb6aada19a98a516e87824
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4257105
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
ceb49b1c
|
2023-01-17T19:21:43
|
|
Vulkan: Fix crashes when Surface is not current.
It is possible to destroy Surface while some resources are still
in use (by CPU/GPU):
1. Make Surface current.
2. Draw something.
3. Make other Surface current (same Context).
4. (optional - if test Surface is Window Surface) Draw something.
5. Delete Surface.
6. UnMake the Context from current.
7. Different crashes possible depending on Surface type and what
is done in step 2.
Bug: angleproject:8017
Test: angle_end2end_tests --gtest_filter="EGLSurfaceTest.DestroyNotCurrent*Surface*"
Change-Id: I3102aa237075b301b3222b420415753c83ba192a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4227073
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
aa1f7e19
|
2023-02-08T21:05:35
|
|
Vulkan: Fix CommandQueue Wait Semaphores asyncCommandQueue race.
Recently implemented fix has a problem:
When using "asyncCommandQueue", wait semaphores flush performed in
the context thread, while submit in the async thread. Both operations
protected by the mutex, so there is no data race or other UB.
It is a potential performance problem: submit operation may attach
wait semaphores prematurely, before corresponding commands flushed into
the primary command buffer.
Fix adds "CustomTask::FlushWaitSemaphores" to ensure wait semaphores and
commands flushed in order.
Bug: angleproject:7995
Change-Id: I7d3cfad867c59d3cd0a5c0bb3f81ae8d98238362
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4231844
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
|
|
|
8b9bd182
|
2023-02-08T16:17:10
|
|
Vulkan: Refactoring to use ProtectionType enum instead of bool
This is a second stage of refactoring that was started here:
Vulkan: Minor CommandQueue implementation refactoring.
0210b46d35b51ea04bddafb48ba406a87c39e58e
Enumeration renamed: CommandContent -> ProtectionType.
Currently interfaces of ContextVk/RendererVk/CommandQueue use
"hasProtectedContent" boolean. Internally CommandQueue uses
"vk::ProtectionType" enumeration to separate states related to
Unprotected/Protected commands. This CL replaces boolean with
enumeration for consistency.
Bug: angleproject:7995
Change-Id: Ibb98cce661358d464be7c6a8367a1297d7093b1c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4232114
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
|
|
|
b6cc5754
|
2023-01-17T16:17:22
|
|
Vulkan: Fixed Wait Semaphores problems.
This feature fixes 2 problems.
1. Swapchain Image Acquire Semaphore added to wait list AFTER
rendering commands:
- Make Window Surface current.
- Clear Window Surface (Image is Acquired).
- Perform rendering to the Window Surface.
- Change to other Surface (for example: PbufferSurface) using
the same Context.
- Unmake Context from current to ensure commands are submitted.
- Rendering commands to the Window Surface will be submitted
without Acquire Semaphore.
2. Context from other thread may submit command of another Context
without proper Wait Semaphores:
- Make Window Surface current in the first context.
- Clear Window Surface (Image is Acquired).
- Perform rendering to the Window Surface.
- Call "glBeginQuery()/glEndQuery()" (or other commands) - this will
flush command to the Primary Command Buffer without submitting.
- In other Thread and Context make some Surface current
(for example: PbufferSurface).
- Clear that surface with scissor and unmake Context from current
to ensure commands are submitted.
- Rendering commands to the Window Surface from the first Context
will be submitted without Acquire Semaphore.
- Problem will happen even if add Wait Semaphore BEFORE writing
rendering commands.
Bug: angleproject:7995
Test: angle_end2end_tests --gtest_filter="EGLSurfaceTest.WaitSemaphoreAddedAfterCommands*"
Test: angle_end2end_tests --gtest_filter="EGLSurfaceTest.CommandsSubmittedWithoutWaitSemaphore*"
Change-Id: I28174ff98fdd09b4117962fc0810cfeeb2a4d1f1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4194182
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
0ee67145
|
2023-02-06T18:08:26
|
|
Vulkan: Fix bug with ContextVk::mWaitSemaphores processing.
Regression:
2e5ca217ca134a7ae4e241e2f7e4cfa637305af7
Vulkan: Let each current context has its own QueueSerial.
Problem details:
- Call to finishImpl()/flushImpl() will skip mWaitSemaphores processing
when there are no pending commands.
- finishImpl() will call clearAllGarbage() that will clear
all mCurrentGarbage.
- However, some mWaitSemaphores may be in the mCurrentGarbage
(Semaphore created in SyncHelperNativeFence::serverWait()).
Bug: angleproject:8007
Test: angle_end2end_tests --gtest_filter="EGLSyncTest.AndroidNativeFence_VkSemaphoreDestroyBug*"
Change-Id: Ia51663eae739b505ca00437cea4ae71526dedbfb
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4225392
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
|
|
|
ef056a06
|
2023-01-20T14:15:48
|
|
Vulkan: Use SubmitPolicy::AllowDeferred whenever possible.
Using of SubmitPolicy::EnsureSubmitted is not necessary, because there
are finishQueueSerial() call immediately after that.
Changing to AllowDeferred avoids extra waiting call (NO-OP)
and saves some CPU cycles.
Bug: angleproject:8001
Change-Id: Id618253a4b59d006975044eb437ac60468199a98
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4194187
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
fa0681d1
|
2023-01-17T17:43:48
|
|
Vulkan: Per Context Serial cleanup.
Comment in the "OutsideRenderPassCommandBufferHelper::reset()" is
misleading. New "mQueueSerial" is always generated after
"RendererVk::flushOutsideRPCommands()". This change removes comment
and invalidates "mQueueSerial" to catch possible errors.
Call "generateOutsideRenderPassCommandsQueueSerial()" in the
"ContextVk::flushImpl()" only when needed. This call is necessary only
with empty submission with only "signalSemaphore" and NO OutsideRP
commands are written inside the "flushImpl()"
(mIsAnyHostVisibleBufferWritten or mGpuEventsEnabled).
Bug: b/267806287
Change-Id: Ibc547f97a6b38f70ad3d5901eca7b659b93014c0
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4218363
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
3e5b36e4
|
2023-02-03T14:23:10
|
|
Vulkan: ContextVk::finishImpl only wait for context's serial
ContextVk::finishImpl() right now calling mRenderer->finish() which wait
for everything to finish, including other unrelated context's
submission. This CL changes it to only wait for this context's
mSubmittedResourceUse.
Bug: b/267806287
Change-Id: I0f31d561395da4fed7b9c93fd2adb9e5d8a16222
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4220016
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
b96f3abd
|
2023-02-03T13:12:29
|
|
Vulkan: Make Context::mLastSubmittedSerial to QueueSerial
Right now Context::mLastSubmittedSerial and mLastFlushedSerial are all
Serial type instead of QueueSerial. Most places we do need QueueSerial.
This CL changes them to QueueSerial type. This simplifies and improves
code readability. No actual functional change is expected with this CL.
Bug: b/267806287
Change-Id: Ib00cae2637ee9ed95e5fc00060c63017b04e26c5
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4219944
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
06720c9b
|
2023-01-25T11:46:16
|
|
Add binding to DescriptorInfoDesc.
Otherwise we're hitting the cache falsely https://anglebug.com/7974#c1
(repro in test added in this CL)
UpdatePreCacheActiveTextures now gets the binding using the same calls
as updateFullActiveTextures, updateExecutableActiveTexturesForShader
There might be a better way to do this but it's more complicated.
Filed https://anglebug.com/7974 to track.
Test credit of Shahbaz Youssefi syoussefi@chromium.org
Bug: b/242887117
Bug: angleproject:7974
Change-Id: I481147336437ee4bdce040a3ae81f168e5dffe29
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4104121
Commit-Queue: Roman Lavrov <romanl@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
226fd666
|
2023-01-20T10:26:34
|
|
Vulkan: Make CommandProcessor::checkCompletedCommands immediate check
This checkCompletedCommands() method is trying to do immediate
mLastCompletedSerials update. For async command submission, there is no
point to insert a token for CommandProcessor::checkCompletedCommands
since it is not waiting for all queued commands to be submitted. And
even worse, for async submission, it is also not doing immedidate queue
serial update. For example, SyncHelper::getStatus() we do call
checkCompletedCommands to ensure the queue serials are up to date, but
with async submisison, this has no immediate effect, which may cause
test like FenceNVTest.BasicOperations/ES3_Vulkan_AsyncCommandQueue to
fail because queue serial is not kept up to date even though we did wait
for fence to finish. This CL removes CustomTask::CheckCompletedCommands
token and just calls mCommandQueue.checkCompletedCommands() immediately.
This CL only affects asynchronous command submission code path.
Bug: b/266220198
Bug: angleproject:7884
Change-Id: I3226bc9b337b516e28695008295358d00103eeb9
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4174876
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
ef0fe638
|
2023-01-16T00:00:00
|
|
Implement EXT_polygon_offset_clamp
* Added polygonOffsetClamp to the RasterizerState
* Adjusted State::setPolygonOffsetParams
* Added PolygonOffsetClampTest end2end tests
* Added StateChangeTestES3.PolygonOffsetClamp test
* Suppressed the affected dEQP test as it has a bug
Capture
* Updated serialized rasterizer state
* Updated CaptureMidExecutionSetup
OpenGL
* Rely on the EXT extension defined both
for desktop and ES contexts
* On desktops, might as well use the ARB extension
or GL 4.6 once ANGLE supports them
D3D11
* Requires FL10_0 or higher
* Maps to D3D11_RASTERIZER_DESC.DepthBiasClamp
* Drive-by cleanup of extensions init code
Vulkan
* Requires depthBiasClamp physical device feature
* Maps to the depthBiasClamp parameter
of the vkCmdSetDepthBias command
Metal
* Maps to the clamp parameter
of the setDepthBias command
Bug: angleproject:7957
Change-Id: If6b28df4084f0a81db29f75fb434e75d394c8730
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4169945
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
|
|
|
00b94fda
|
2023-01-17T11:12:14
|
|
Vulkan: CommandProcessor::WaitForWorkComplete only if needed
When async command queue enabled, there is another queue (mTask) in
CommandProcessor object. When we wait for a queueSerial to finish, right
now we always flush everything from CommandProcessor (i.e, wait until
mTask is empty), even though the work in mTask is unrelated to this
queueSerial that waiting for. With the work of previous CLs, now we can
actually wait for mTask to empty only if there is still pending
submission of queueSerial.
This CL also renames ComandProcessor::ensureNoPendingWork to
waitForQueueSerialToBeSubmitted to reflect what it does (it does not
wait for GPU to finish).
Bug: b/261098465
Change-Id: I0114dadd86a84f75bf8b71735f0adc0dbb9b6bf2
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4174873
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
90b6d511
|
2023-01-13T10:06:12
|
|
Vulkan: Add support for AHB usage FRONT_BUFFER flag
AHB usage flags have been updated to include front buffer usage.
AHBs tagged with this flag need to be handled similar to single-buffered
window surfaces especially w.r.t glFlush semantics. Account for the
new usage flag when deferring flushes.
Bug: angleproject:7956
Test: Android VTS GraphicsFrontBufferTests.*
Change-Id: I79440d8447ac569c3d785de191815d2d2f3f069f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4167063
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
|
|
|
410d8ba5
|
2022-12-21T13:27:00
|
|
Vulkan: Cleanup ContextVk::hasStartedRenderPass APIs
ContextVk has a few hasStartedRenderPass APIs which interpret "start"
inconsistently. A RenderPassCommands' life should be notStarted,
started, requestEnd, and end (which is equivalent to notStarted). When
someone calls onRenderPassFinished on a started renderpass, it does not
immediate endRenderPass, but it will set DIRTY_BIT_RENDER_PASS dirty bit
so that next draw call will trigger endRenderPass and start a new
renderPass. We do not have a name for this state, which adds some
confusion. This CL renames the stage between start and
onRenderPassFinished to be "active" renderpass, when you have
mRenderPassCommandBuffer pointer being valid and you can actively adding
draw commands into the renderPass. For this purpose, I haves renamed
hasStartedRenderPass to hasActiveRenderPass. This CL also simplifies
hasStartedRenderPass implementation to only check
mRenderPassCommandBuffer and turned mRenderPassCommands.started as
assertion. This CL also changes hasStartedRenderPassWithQueueSerial to
actually check mRenderPassCommands.started instead of being "active", so
that name reflects what it is actually checking. This CL also changed
hasStartedRenderPassWithCommands to hasActiveRenderPassWithCommands to
make name and implementation consistent. One added benefit of this is
that after this CL we now allow load/store optimization on a started but
inactive renderPass as well (for example glInvalidateFramebuffer call
after glFenceSync call, or invalidate after FBO blit as demonstrated by
MultisampleResolveTest.ResolveD32FSamples tests).
Bug: angleproject:7903
Bug: angleproject:7551
Change-Id: I8c8ec4c0d54b9ad0a9e373108dfce6b151c8fe0e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4119693
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
5ac2d2e7
|
2023-01-11T04:51:42
|
|
Vulkan: Wait for job before destroying render passes
This was the case for render pass cache clear, but was missing from
destroy.
Bug: angleproject:7369
Bug: angleproject:7944
Change-Id: I7d0921507364db7ab570df13147bcdec351bd578
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4153136
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Roman Lavrov <romanl@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
493f3f31
|
2022-11-11T17:01:40
|
|
Reland "Vulkan: Only allocate default attribute if needed"
This is a reland of commit 85c98a92bb763452133bd7b4580d80625bb2c75d
Original change's description:
> Vulkan: Only allocate default attribute if needed
>
> mDirtyDefaultAttribsMask has all bits set when starts.
> ContextVk::handleDirtyGraphicsDefaultAttribs() is looping all dirty bits
> and try to allocate buffer for it, which means we are looping 16
> times when app starts. This CL changes to allocate a buffer only if used
> by program.
>
> Bug: b/258862506
> Change-Id: I2f0a75d1fe141c9ac3101088fdc4ce4f60b0c4ee
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4024544
> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
> Reviewed-by: Yuxin Hu <yuxinhu@google.com>
> Commit-Queue: Charlie Lao <cclao@google.com>
Bug: b/258862506
Bug: angleproject:7866
Change-Id: Iad0b6a6ce5ec42e48461a199773eb8dc9976265e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4144938
Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
26e28089
|
2023-01-04T15:15:46
|
|
Vulkan: Improve RPCommandHelper::isImageWithLayoutTransition()
RenderPassCommandBufferHelper::isImageWithLayoutTransition() was added
in crrev.com/c/3366014 to detect if there is a barrier inserted for the
renderPass. If yes, we have to endRenderPass before compute shader,
since compute dispatch goes into outsideRenderPassCommands, which writes
into primary command buffer before renderPassCommands. Otherwise the
compute dispatch will be using the image before the actual layout
transition occurs, which is wrong. But to detect if the image has a
layout/barrier transition in the renderPass, it maintains an
angle::FlatUnorderedSet. With recent change for per active context queue
serial, we can use the queue serial to detect this. This CL adds a
queueSerial for image layout/barrier change and compares it with
RenderPassCommands' queueSerial to decide if the renderPass has a
layout/barrier for the image.
This CL also did some minor clean ups: Removed unused API
ContextVk::getActiveImages(). Removed writtenByCommandBuffer() check in
CommandBufferHelperCommon::bufferWrite() before calling
setWriteQueueSerial, since the check is more expensive than set. Added
setQueueSerial call in OutsideRenderPassCommandBufferHelper::imageWrite
to be consistent with imageRead. (This might be fixing a bug here).
Replaces a few retainResource(image) to image->setQueueSerial for
consistency.
Bug: b/264472911
Change-Id: I74badd6b8a35f86640e42d330a1a709ccfb961c3
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4136948
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
2662f28f
|
2022-12-30T17:26:22
|
|
Vulkan: Fix imageRead from RP and outsideRP simultaneously
When a texture is been sampled from both fragment shader and compute
shader, you will have the same VkImageLayout. We will not try to end
renderPass, which means you end up running into similar situations with
OutsideRenderPassCommandBufferHelper::bufferRead where an image is
already read accessed by a started renderPass and now read accessed by
an outsideRenderPassCommands. Since renderPass has greater queueSerial,
we should not tag it with outsideRenderPassCommands' queueSerial.
This CL also adds two tests, one for color texture and another for
depth texture (which is car_chase uses). Both exposes the same bug.
Bug: angleproject:7916
Change-Id: I840ca8947caeb7a96c4c9ccb7c9eca2476837c9c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4133548
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
5f1ab1d1
|
2023-01-03T11:48:51
|
|
Fix Deferred Flush Bug On Android Hardware Buffer
When does app read from Android Hardware Buffer
is outside of ANGLE's control. If we defer glFlush,
it is possible that when the app is reading from
AHB, the commands have not been flushed and executed,
causing app to read unexpected data. This change
adds a check to not defer glFlush when the Framebuffer
draw attachment is Android Hardware Buffer.
Bug: b/262886794
Change-Id: Ie0606f71b1a4f4f20511b7327e7ffb8c096ac727
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4126700
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Yuxin Hu <yuxinhu@google.com>
|
|
|
6c41793f
|
2022-12-20T15:20:50
|
|
Vulkan: Use read/write depth/stencil layouts
This allows an application to have depth in read-only feedback loop
while stencil is being written to for example.
Bug: angleproject:7899
Bug: b/192477489
Change-Id: Ic2e11d32da7c7e3a7f3cd86dbafc5c56a0dbbfd7
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4116730
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
295f6830
|
2022-12-21T10:56:03
|
|
Vulkan: bufferRead should accommodate deferred endRenderPass
ContextVk::onSyncObjectInit() will request end of current renderPass but
deferred (in this case, mRenderPassCommandBuffer is nullptr but
mRenderPassCommands->started() still returns true). The next draw call
will actually end current renderPass and starts a new renderPass. But if
next call is glCopyBufferSubData, it will not actually trigger
endRenderPass. This CL modifies
OutsideRenderPassCommandBufferHelper::bufferRead logic to accommodate
this deferred endRenderPass scenario by checking
mRenderPassCommands->started() instead of hasStartedRenderPass so that
the answer to "if this buffer been used by current renderPass or not"
will return correct result.
Bug: angleproject:7903
Change-Id: Ie5c9977ccf083e7d355a2cd8fd08e9077049ee9a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4119692
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
626b10c1
|
2022-12-20T20:22:19
|
|
Vulkan: Add read/write depth/stencil layouts
This CL only adds the layouts in the list, but does not use them. The
layouts are renamed for consistency in this change.
Bug: angleproject:7899
Bug: b/192477489
Change-Id: I47986c7252d32626e9f26c6670c0a4e3496fe0c8
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4116736
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
301ed545
|
2022-12-20T20:16:22
|
|
Vulkan: Pass context to layout getters
In preparation for a change that optionally uses read/write
depth/stencil layouts. Context is used to test for the
supportsMixedReadWriteDepthStencilLayouts feature to know whether those
layouts are supported or that a fallback must be chosen.
Bug: angleproject:7899
Bug: b/192477489
Change-Id: I1453dc9d060453a3806ad0f261b94368fe01fb29
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4116735
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
d6dea33b
|
2022-12-19T13:39:34
|
|
Vulkan: Remove CommandQueue::mGarbageQueue
With recent work of per active context queue serial, mGarbageQueue
behaves almost identical to normal mSharedGarbage now. This CL removed
mGarbageQueue and added garbage into Remove mSharedGarbage instead.
Bug: b/263166501
Change-Id: I6bce47b4535283e7bd0f0c8823b9629cc25f9d94
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4117712
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
cd540095
|
2022-12-12T13:13:14
|
|
Vulkan: Add memory log at allocation error
* Added logging memory allocation information in handleError() in the
event of an error from ANGLE_VK_TRY.
* Used for the handleError() in ContextVk.
* Updated the name and message of the function to log allocations.
* checkForCurrentMemoryAllocations()
* Added logging memory heap stats, including budget and usage.
* logMemoryHeapStats()
* In the renderer, added the feature flag indicating whether the
platform supports the memory budget extension.
* Uses VK_EXT_memory_budget.
* Added the enum class MemoryLogSeverity, which is used to select
the severity level of the memory log.
* Added logging pending memory allocation information.
* logPendingMemoryAllocation()
* If the last unsuccessful memory allocation was unsuccessful, its
information will be added to the log.
Bug: b/262029018
Change-Id: I97343c1553936aed23d763f3e0c00d495f9ee810
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4089531
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Kaiyi Li <kaiyili@google.com>
|
|
|
6769ef2b
|
2022-12-16T15:34:21
|
|
Vulkan: Bug fix in setupIndexedDraw
Reset ContextVk::mCurrentIndexBufferOffset to 0 after a call to
ContextVk::convertIndexBufferCPU(...) irrespective of whether
the buffer binding is dirty.
Bug: angleproject:7896
Test: DrawElementsTest.DrawElementsWithDifferentIndexBufferOffsets*
Change-Id: I70a63b7e432aaa9f8c647e56bd162312143abd65
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4113446
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
|
|
|
5c8c0347
|
2022-12-15T15:46:38
|
|
Vulkan: Remove ContextVk::retainResource and retainImage()
Clean up some retain* APIs. retainImge and retainReadOnlyResource and
retainResource are doing exact same thing, they are consolidated into
just retainResource. ContextVk::retainResource is removed since mUse
can now safely copied from DescriptorSetHelperPool object which tracks
mUse.
Bug: b/262047600
Change-Id: I56ea08696e870826bd94ccb79dd621f35923bc6a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4114500
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
376d309c
|
2022-12-15T09:43:00
|
|
Vulkan: Remove unnecessary usesBuffer() check
There are places that we call setQueueSerial after usesBuffer() check.
This was useful when we had the ResourceList where it is more expensive
to set serial. But now setQueueSerial is cheap (actually is cheaper than
usesBuffer check), so there is no need to do this check any more. This
CL removes the check to further reduce the CPU overhead. Because of
this, mUsedBufferCount will not be accurate, so this CL also removes the
tracking of mUsedBufferCount (was only for informational purpose
anyway).
This CL also removes commandBufferQueueSerial.valid() check in
Resource::usedByCommandBuffer() and turns it into assertion. Some places
in contextVk will ensure we only call it on started renderpass so that
other places that calls usedByCommandBuffer will not need to eat the if
check.
Bug: b/262047600
Change-Id: I6b8004b6aa5b567fa94c0eb56801054f818838b1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4112145
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
cd367796
|
2022-12-12T15:10:09
|
|
Vulkan: Add assert to ensure never setQueueSerial backwards
This CL add an assertion in ResourceUse::SetQueueSerial to ensure that
we never set a serial smaller than what it already has. If that happens,
we could potentially destroy it while GPU still accessing it. With this
assertion, it exposed a bug that when a buffer is read accessed by a
renderpassCommands and then read accessed by outsideRenderPassCommands,
we were incorrectly setting the queueSerial with outsideRP's serial,
overwriting the queueSerial already set by renderPassCommands. To fix
this, this CL detects this case and keeps the queueSerial set by
renderPassCommands.
Bug: b/262047600
Change-Id: I51b17ab4a93bccd0d0b079784af96cef9d79f16f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4099804
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
a703eea4
|
2022-12-09T15:55:03
|
|
Vulkan: Remove Serial::valid() check
QueueSerial right now checks if serial is valid or not in various
comparison. This CL removes valid() method from class Serial and rely on
the fact that default constructor always constructs kZeroSerial and
kZeroSerial is always smaller than any serial, i.e, always appears as
flushed, submitted and completed. This removes one branch from critical
code path where we try to detect if a buffer/image is used by a
renderpass or not etc.
Bug: b/262047600
Change-Id: Ic76fe1409d9911dc7eb86107c9a930d8bb5eaa05
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4089848
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
77c95de4
|
2022-11-16T21:12:28
|
|
Vulkan: Threaded monolithic pipeline creation
With this change, once a pipeline is created out of libraries, a task is
scheduled (if necessary) to asynchronously create a corresponding
monolithic pipeline. Once the task is complete, the linked pipeline
handle is replaced by the monolithic one, gaining back any performance
that might have been lost due to the use of libraries.
Bug: angleproject:7369
Change-Id: I525fb1e09f8bedc61b9dbef19f9cce7026ff9c53
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4031151
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
89cd8583
|
2022-12-12T11:23:59
|
|
Vulkan: Clean up Resource class
Resource::retainCommands() API name no longer make sense. This CL
removes retainCommands and retainReadOnly and retainReadWrite APIs and
replaced with setQueueSerial and setWriteQueueSerial call directly.
This CL also merges some of single inline functions to minimize the
file, sine the class is small anyway.
Bug: b/262048658
Change-Id: I9d16b82c79b27f3285311393601705a4ee7f6d8a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4098005
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
a1be7188
|
2022-12-12T16:11:34
|
|
Vulkan: Keep referenced pipeline libraries alive
As required by the spec, it's not enough to keep the linked pipeline
alive. With this change, the serials of the invidual libraries are
updated every time the serial of a linked pipeline is updated.
Bug: angleproject:7369
Change-Id: Iedc98a427d988d00b4e8745964d9827fdf51ea7f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4098744
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
f3ebb2ca
|
2022-12-08T17:02:12
|
|
Vulkan: Better mUse tracking for DynamicallyGrowingPool<Pool>
This is used only from DynamicallyGrowingPool<Pool>::onEntryFreed to set
the its tracking QueueSerial. There is better way to do this now with
per context serial. We can simply merge the QueryHelper's mUse into the
pool instead of setting pool's use to the current queueSerial. The
benefit of doing that is to possibly allow pool gets reuse/freed earlier
(i.e., more accurate tracking). This CL switches it to more accurate
tracking and removes mCurrentSerial from Context.
This CL also removes unused DynamicSemaphorePool class.
Bug: b/262054987
Change-Id: Iac3e2495cc0e3623ba63e9da7f32ad6e9c223467
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4089847
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
684ff60b
|
2022-06-21T10:52:31
|
|
Vulkan: Add shared ring buffer cmd alloc feature
* Added RingBufferAllocator.cpp with implementation.
* Main classes:
* RingBufferAllocator (fast allocation with bulk deallocation)
* SharedRingBufferAllocator (wrapper to help with shared use and
multiple threads)
* Implemented "angle_enable_vulkan_shared_ring_buffer_cmd_alloc"
feature. (Disabled by default)
* Details (from the original CL)
* The angle::PoolAllocator replaced with
angle::RingBufferAllocator.
* Before, there was separate angle::PoolAllocator per each
CommandBufferHelper. Now, a single angle::RingBufferAllocator
is shared between multiple CommandBufferHelper objects.
* Commands data from multiple CommandBufferHelpers is
tightly packed without fragmentation.
* Significantly less memory overhead, observed with enabled
async queue.
* Moved the parts of the code related to the allocators into the
classes in the new AllocatorHelperPool and AllocatorHelperRing files
for better management. The allocator can be switched by changing the
following BUILD flag:
`angle_enable_vulkan_shared_ring_buffer_cmd_alloc`
* It is connected to the following macro:
ANGLE_ENABLE_VULKAN_SHARED_RING_BUFFER_CMD_ALLOC
* The two main allocator classes in each file are aliased as:
* SecondaryCommandBlockAllocator (in CommandBufferHelper objects)
* SecondaryCommandBlockPool (in SecondaryCommandBuffer)
* Also added placeholder functions for VulkanSecondaryCommandBuffer.
* Added descriptions regarding the two allocators.
* renderer/vulkan/doc/Allocators.md
Credit: Original CL authored by Igor Nazarov <i.nazarov@samsung.com>
Bug: angleproject:6401
Bug: b/256666069
Change-Id: I0f24793eef6334bf4ff8e327b9665338807dad37
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3715968
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
6830b7d3
|
2022-11-23T11:51:28
|
|
Vulkan: Use finishQueueSerial for queueSubmitOneOff
Right now for oneoff submission we are creating a fence and pass in the
fence and then wait for fence outside the normal wait code path. This
creates a problem that the command buffer and garbage clean up code does
not gets run and may end up hitting assertion. This might be necessary
before because complication with ResourceList. With recent work that
removes ResourceList, this can be much simpler now. This CL removes the
fence creation and wait in the oneoff submission code path (except the
external fence) and switch to finishQueueSerial call.
Bug: b/255414841
Change-Id: I2b16c187becbda9c2397685c7212abac994e8dc2
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4053261
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
1219f55a
|
2022-12-07T16:19:37
|
|
Vulkan: Remove Resource::isCurrentlyInUse
Due to header file include order, this function can not directly
made inline. This CL removes the function and replace it with
renderer->getUnfinishedUse() to reduce one extra function call of one
line function.
Bug: b/262048658
Change-Id: Ied33b63d0ec88336a5ce42cf7726f16b2b883b86
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4089623
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|