|
ad6c3d74
|
2025-02-19T22:45:29
|
|
Vulkan: Fix RP resolve layouts w.r.t shared present mode
This is partially a regression after the previous change:
Vulkan: Fix present optimization w.r.t shared present mode
Before the above change, swapchain image was still optimized for present
even when using shared present mode. However, because
SetBitField(mAttachmentOps[packedAttachmentIndex].finalResolveLayout
line was using `getCurrentImageLayout()` (lucky coincidence) it was
setting correct SharedPresent layout into `finalResolveLayout`.
The `initialLayout` and reference `layout` was still
`VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL`, but for some reason VVL was
not producing any errors.
This change adds setting `finalResolveLayout` for the resolve
attachment, which in turn propagates
`VK_IMAGE_LAYOUT_SHARED_PRESENT_KHR` to all renderpass layouts as well
as to the dynamic rendering info.
Test: angle_end2end_tests --gtest_filter=EGLSingleBufferTest.SharedPresentLayoutWithMSAA/*
Bug: angleproject:42262606
Change-Id: I49a121f1d43a078890b0dc32e0574a79e3565270
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6281569
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
|
|
65343c4c
|
2025-02-27T11:23:04
|
|
Vulkan: Improve ConvertImageLayoutToVkImageLayout()
This CL removes supportsMixedReadWriteDepthStencilLayouts feature flag.
This feature flag was introduced when ANGLE only requires vulkan 1.0.
But now we require vulkan 1.1 and this is part of vulkan 1.1 core spec.
So it is no longer needed and wasting CPU cycles to check this every
time ConvertImageLayoutToVkImageLayout() is called.
With supportsMixedReadWriteDepthStencilLayouts removed, convert from
ImageLayout to VkImageLayout no longer needs renderer parameter. The
layout information in kImageMemoryBarrierData is never modified by
renderer at run time. So the renerer arguments has been removed in a lot
of places, avoids another pointer de-reference.
Bug: b/384839847
Change-Id: I5a89a890c0c0a1f99d2fdc1b2a85baf7de5c28bf
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6310839
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
055123f8
|
2025-02-27T10:45:56
|
|
Vulkan: Don't maintain SharedCacheKeyManager for BufferBlock
Dynamic descriptor type uses the underlying BufferBlock in the
descriptorSet. There could be many BufferHelper objects sub-allocated
from the same BufferBlock. And each BufferHelper could combine with
other buffers to form a descriptorSet. This means the combination for
BufferBlock could potentially be very large, in thousands with some app
traces like seeing in honkai_star_rail. The overhead of maintaining
mDescriptorSetCacheManager for BufferBlock could be too big. In this CL
I have chosen to not maintain mDescriptorSetCacheManager in the
BufferBlock. The only downside is that when BufferBlock gets destroyed,
we will not able to immediately destroy all cached descriptorSets that
it is part of. They will still gets evicted later on if needed (see
evictStaleDescriptorSets for detail). After this CL, running with all
app traces we have, the max vector size of
SharedCacheKeyManager::mEmptySlotBits is no more than 2, versus ~70s
before the CL.
Bug: b/384839847
Bug: b/293297177
Bug: b/237686097
Change-Id: I7c7c91cd0aeacba4145575ac4270b713bf38b742
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6310837
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
9202e05a
|
2025-02-21T18:42:42
|
|
Vulkan: Invalidate the SharedCacheKey when cache gets evicted
When descriptorSet cache gets evicted, right now we have a bug that the
sharedCacheKey does not gets invalidated. This caused
SharedCacheKeyManager always think the sharedCacheKey is valid and the
mEmptySlotBits never gets cleared, which leads to mEmptySlotBits growth
over time, and increases CPU overhead when walking mEmptySlotBits
vector. This CL adds an assertion to ensure that all valid
sharedCacheKeys has a corresponding entry in the cache, which means
without this CL, some traces and dEQP tests are hitting the assertion.
This CL also fixes the bug.
Bug: b/384839847
Change-Id: If013443144aceb5d62f67f619074ef831e73653b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6292988
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
03bdf1ca
|
2025-02-18T16:37:49
|
|
Vulkan: Use correct actual FormatID for MSAA swapchain image
Implementation of "overrideSurfaceFormatRGB8ToRGBA8" feature missed
updating actual FormatID for the MSAA swapchain image. This bug makes
possible to initialize RGBA8 swapchain image and RGB8 MSAA image.
However, on practice MSAA is still RGBA8 because RGB8 renderable is
generally emulated on Android.
VUID-vkCmdResolveImage-srcImage-01386: srcImage and dstImage must have
been created with the same image format.
This fix is cosmetic and is not expected to fix any real bugs
(because RGB8 is generally emulated with RGBA8).
Bug: angleproject:42265147
Change-Id: Ief4b74ac31e93a655f5088b7927e970585255f25
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6275968
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
|
|
|
8f8b41e3
|
2025-02-14T17:54:51
|
|
Vulkan: Optimize for multiple TexSubImage calls in the same level
Based on app traces, some apps make glTexSubImage call for the same
level multiple times in a row. One extreme example is lumino_city, which
it creates a 2D texture with nullptr data, and then calls
glTexSubImage2D many times back to back for each row of the texture to
update the data. Because we uses std::vector to store the per level
update struct (SubresourceUpdate), it means we copy these data
structures every time it grows 2x, until it hit the max size 1081. The
other common case we get into is app update some area of the texture
(like google map and gacha_life) which also end up with a few
texSubImage calls back to back. The other more common case is we staged
a clear first and then glTexSubImage which end up with vector size of 2.
This CL changes to use std::deque instead of std::vector to store the
staged update for a given level, which allows it to grow without extra
penalty.
Bug: b/293297177
Change-Id: Iabbc143074ad9d6fcf47abbddee09ecf7f78d1a7
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6271964
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
c96844d9
|
2025-02-14T10:26:25
|
|
Vulkan: More vector storage fix
BufferPool::mBufferBlocks reserves 32 entry storage based on data
gathered from trace.
BufferPool::mEmptyBufferBlocks switched to queue since we almost never
walk the entire list unless it gets destroyed.
Renderer::CollectGarbage is changed to take only one object. The only
time it get called with more than one object is from
ImageHelper::releaseImage(), which in this CL we now creates and pass
GarbageObjects to Renderer::collectGarbage directly. This also allows me
to delete recursive CollectGarbage() and DestroyGarbage() functions
(which is doing emplace_back quite often, even though only two entries).
PipelineHelper::mTransitions is updated to reserve storage for 8 entries
based on trace data.
Bug: b/293297177
Change-Id: I3e4552939a780dd26f9b7b8a67deee0d52d4f9bc
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6270518
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
3d29a799
|
2025-02-11T10:05:35
|
|
Vulkan: Reserve enough storage for ImageHelper::mSubresourceUpdates
Most app specify textures from level 0 to level N, which works against
std::vector storage grow scheme (which grows in size of 1,2,4,8,16).
This CL simply reserve space for 12 mipmap levels to accommodate for
most used texture sizes.
Bug: b/293297177
Change-Id: I44818ed7ee436c73ab7ff146972f122ae9f08f33
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6253673
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
9e86d8c0
|
2025-02-05T16:31:22
|
|
Vulkan: Fix VVL due to memory map range
VVL: VUID-VkMappedMemoryRange-size-01390
* Updated BufferBlock::map() so the device memory uses the actually
allocated buffer size.
* To flush and invalidate a mapped memory range (non-coherent), the
memory size is now aligned with nonCoherentAtomSize from the physical
device limits.
* Added an assert to make sure that the mapped size is within the
allocated buffer size range.
* Unskipped ExternalBufferTestES31 cases for Pixel6, except one case
which seems to take a long time and result in timeout.
* BufferDoesNotLeakAHB
Bug: angleproject:394685081
Change-Id: Iddfb45997fed53c5ee99938d9bb57b670550b9a6
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6238059
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
d252425d
|
2025-02-06T14:51:36
|
|
Vulkan: Check source image usage flags in copy paths
... instead of the format feature flags. If the source of the copy is
has external format (allowed with glCopy[Sub]TextureCHROMIUM), the
format feature checks are unable to query the format features. However,
the image usage flags already have the required information (whether the
image can be copied from, sampled from, etc).
Bug: chromium:383056998
Change-Id: I2ba8820751eb526ef497a8be724193276fd46160
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6238265
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
0026006d
|
2025-02-10T12:03:40
|
|
Vulkan: Fix missing barrier between dispatch calls
When storage images are used, ANGLE accidentally did not mark the images
as being written to, so subsequent barriers were not produced when
necessary.
Bug: angleproject:352610491
Bug: b/394611669
Change-Id: Idd3e6aa6b90212605594240a533ebaec66850ea9
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6249459
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
ffb7575c
|
2025-02-07T10:25:22
|
|
Vulkan: Reserve reasonable amount storage for GarbageObjects
Based on data collected from app traces, set the initial storage enough
to accommodate most of the usage cases.
For ContextVk::mCurrentGarbage, the problem is that after the
collectGarbage call, it lose the capacity value, so next time it end up
with 0 and slowly grow the capacity again. This CL always keeps the
capacity after the collectGarbage call.
Bug: b/293297177
Change-Id: I70deccd879311aebe6ea3bbf4ecf5c54a74ef584
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6244922
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
3dcd143c
|
2025-02-06T15:06:02
|
|
Vulkan: Reduce GL_EXT_texture_storage_compression related overhead
Most of apps not using fixed rate compression extension, but we are
getting into all these logic that checking for vulkan driver's support
of compression rate. This CL adds a check in TextureVk::initImage(), so
that it only goes down that logic if
mState.getSurfaceCompressionFixedRate() is not
GL_SURFACE_COMPRESSION_FIXED_RATE_NONE_EXT. This means for all existing
app traces we have, we should not go down these logic any more.
This CL also made TextureVk::getFormatSupportedCompressionRatesImpl()
and ImageHelper::getCompressionFixedRate() out of TextureVk and
ImageHelper class given they are not accessing the data member at all.
Bug: b/293297177
Bug: angleproject:352364583
Change-Id: Ib5eebf54172f194d7c65c2d2d751326b7923403f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6239523
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
9c82e55a
|
2025-01-16T17:47:41
|
|
Vulkan: Make VkEvent for Buffer work with more general usage
Before this CL, BufferHelper::mCurrentWriteAccess and
mCurrentReadAccess, mCurrentWriteStages, mCurrentReadStages still track
all accesses, regardless if it is tracked by RfCountedEvent or via
PipelineBarrier. This is okay for very limited usage case, but becomes
fragile when expand the event for general usage case. The problem is
that you can not correctly tell which bits in mCurrentReadAccess is for
pipelineBarrier and which is for Event, since event and pipeline barrier
could have the same VkAccessFlags. Similarly problem exist for
mCurrentWriteAccess. The reliable way is actually track pipeline barrier
access and VkEvent access completely separately. This CL changes
mCurrentWriteAccess, mCurrentWriteStages, mCurrentReadAccess and
mCurrentReadStage to only contain bits that not tracked by VkEvent. For
this reason, RefCountedEventWithAccessFlags wrapper class is added to
wrap mCurrentWriteEvent and its associated VkAccessFlags.
Bug: angleproject:360274928
Change-Id: I057484f0c3baa2739d56c3a75889eb88a647a65a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6210683
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
29e20d52
|
2025-01-29T15:58:04
|
|
Vulkan: Use single VkEvent to track depth/stencil and color attachment
Right now ANGLE uses two VkCmdSetEvent calls to synchronize color and
depth attachments in a render pass, one for color attachment and another
for depth/stencil attachment. This is inefficient. ARM engineers
confirmed combining both into one event with a combined stage mask
(VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT |
kAllDepthStencilPipelineStageFlags) should not negatively impact
performance. This CL merges depth/stencil related events into color
attachment. The benefit of this is that for most render passes, you will
see one less VkEvent which translates to reduced overhead.
Bug: b/393150736
Change-Id: I0808b4dfd0b91efaaa2af649fef8bb02abbb3039
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6187980
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
1df10f8a
|
2025-01-29T14:50:21
|
|
Unsuppress VUID-VkImageViewCreateInfo-pNext-01585
* Updated ImageHelper::DeriveCreateInfoPNext() to check the usage flags
as well.
* If the image uses the storage bit, the format list should not be
added to it as pNext. Otherwise, if the count is not zero, it
expects the format used in its image view to be one of the stated
formats and will result in a VVL if this is not the case.
Bug: angleproject:42264452
Change-Id: I789ec5a9751366029929c4c25a942056df13b9ff
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6216381
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
9d934912
|
2025-01-09T11:31:42
|
|
Vulkan: Use VkEvent to track transform feedback buffer write
This CL adds event tracking into BufferHelper class: mCurrentWriteEvent
is used to track the write event and mCurrentReadEvents is used to track
all different reads from the buffer. Since you can have multiple
different reads accumulate over time, read events are an array of
EventStage and the actual VkAccessFlags per event is tracked in
mCurrentReadEventsAccessFlags. Note that this is specifically designed
to allow pipelineBarrier and eventBarrier to co-exist. If
mCurrentReadStages contains more bits than mCurrentReadEvents, the
remaining bits will be using pipelineBarrier. Similarly if
mCurrentWriteStages contains more bits than mCurrentWriteEvent, the
remaining bits will be using pipelineBarrier. A heuristic tracking is
also added to track the buffer writes over a period of time. Right now
we will opt buffer into VkEvent if the buffer ever written by transform
feedback in the heuristic tracking window. This could be expanded in
future if we found more usage pattern that would be benefit from using
VkEvent.
Also note that DrawIndirect and VertexInput will be using the same
VkEvent to track. It still will be using different VkAccessFlags since
the access flags comes from buffer instead of event.
Bug: angleproject:360274928
Change-Id: I027ffed8a0fbff7f280f42cf70564b8a3f243d69
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6085490
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
03019646
|
2025-01-29T10:36:38
|
|
Vulkan: Fix invalidate of emulated format followed by more draws
If invalidating a color image with emulated channels, a clear is
automatically staged so the emulated channels don't contain invalid data
later. This is problematic with deferred clears; the clear marks the
framebuffer attachment as dirty, and the next command causes
`FramebufferVk::syncState` to pick the clear up as a deferred clear.
This is normally correct, except if the following command is another
draw call; in that case, the render pass does not close, yet the clear
is cached in `mDeferredClears`. When the render pass later closes, it
undoes the invalidate and attempts to remove the clear from the image...
but it does not exist there anymore (it's in `mDeferredClears`). Next
usage of the image then clears it, undoing the draws after invalidate.
In this case, the simplest approach is to close the render pass right
away here. Note that it is not possible to make
`FramebufferVk::syncState` avoid picking up the clear in
`mDeferredClears`, not apply the clear, _and_ keep the render pass open;
because future uses of the image (like with |glReadPixels|) will not
trigger `FramebufferVk::syncState` and the clear won't be done.
Bug: angleproject:353167428
Change-Id: Ie677bd12d9f11953cdcd5e4c374b59c4f63e7456
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6214331
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
f231d94b
|
2025-01-13T14:58:16
|
|
Vulkan: Add kBufferMemoryBarrierData to mirror image
Right now we only maintain a mapping from EventStage (which is a value
of VkPipelineStageFlags) to VkPipelineStageFlags for images. For next CL
we need to indicate if use VkEvent is preferred or not for a given
PipelineStage access. This CL expands kPipelineStageFlagBitMap (and
renamed to kBufferMemoryBarrierData) to contain both the
VkPipelineStages and EventStage to indicate if VkEvent should be used or
not, similar to kImageMemoryBarrierData but a lot simpler. Right now it
all set to EventStage::InvalidEnum which means will use pipelineBarrier.
This will change in next CL.
This CL also does some clean up:
A few BufferHelper related functions changed argument from ErrorContext*
to Context*, mainly because of BufferHelper::release() now takes
Context* as argument so that we can recycle events within context's
share group without lock.
ImageLayoutToMemoryBarrierDataMap is added to replace
angle::PackedEnumMap<ImageLayout, ImageMemoryBarrierData>
kEventStageAndPipelineStageFlagsMap is removed.
InitializeEventAndPipelineStagesMap is now using kImageMemoryBarrierData
directly to construct mEventStageToPipelineStageFlagsMap. As result of
this, EventAndPipelineBarrierHaveMatchingStageFlags is also removed
since InitializeEventStageToVkPipelineStageFlagsMap already ensures
this.
Bug: angleproject:360274928
Change-Id: Idb74f3e4120ca9a04b8eccb7ed034aa769024bf9
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6172763
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
95635ef0
|
2025-01-23T16:30:41
|
|
CL/VK: Implementation of Compute Pipeline Cache.
Implemented ComputePipelineCache, hash map from OpenCL and
OpenGL compute state vectors to compiled pipelines. Implemented
ComputePipelineDesc, a tightly packed description of the current
compute state.
Compute Pipeline State includes the specialization constants,
Pipeline Options (Protected, Robust).
Updated-by: Austin Annestrand <a.annestrand@samsung.com>
Bug: angleproject:391672281
Change-Id: I88944dc169d194d1b2c75747769d7346b041fa75
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6191437
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Austin Annestrand <a.annestrand@samsung.com>
|
|
|
0f75fc3d
|
2025-01-20T14:10:41
|
|
Vulkan: Transition foreign images to the FOREIGN queue on submit
Vulkan's interaction with AHB and dmabuf images is through the FOREIGN
queue family. When ANGLE uses these images, it must take ownership of
the images by doing a queue family ownership transfer (QFOT) away from
the FOREIGN queue family and into the graphics queue family used by the
Vulkan backend.
Prior to this change, ANGLE would do the QFOT away from FOREIGN once
such a foreign image is imported into an EGL image. Afterwards, usage
in ANGLE works correctly. What ANGLE did not handle is when a foreign
entity wants to use these images _after_ ANGLE has used them.
For the above to work correctly, ANGLE must do a QFOT back into FOREIGN
before the image can be used by the foreign entity. Unfortunately,
EGL does not provide a clear point for this hand-off to happen. ANGLE
has no choice then to proactively transition the images back into
FOREIGN at some point "just in case".
For some native drivers, this hand-off to FOREIGN can be quite frequent.
For example, on Android for most vendors there is no actual layout
transition between graphics and FOREIGN queue families (the actual data
layout is the same), so a cache flush/invalidate at strategic points
(such as the end of the command buffer) is sufficient as equivalent to
transition to FOREIGN (and another at the beginning of the command
buffer as equivalent to transition from FOREIGN).
As a layer over Vulkan's formalism, ANGLE is less lucky; it has to
enumerate exactly which image is being transitioned to and away from
FOREIGN. Transitions away from FOREIGN are in principle easy. As long
as the image is marked as being in the FOREIGN queue family, it will
automatically transition to the graphics queue family on first use.
In this change, when a foreign image is transitioned out of the FOREIGN
queue, it's added to a list of images to be transitioned back to FOREIGN
at submit time. Once submission is done, the image may or may not
actually be used by a foreign entity, but ANGLE cannot know that. The
next time the image is used in ANGLE, it is transitioned out of FOREIGN.
Verifying correctness with multi-threading is tricky, and relies on GL's
requirement that access in one context is followed by a synchronization
and rebind in another context before it can be used there. This means
that the image's transition to FOREIGN (at the end of one submission)
naturally happens before the transition back from FOREIGN (at the
beginning of the next submission). Because the set of images to
transition is tracked in the context, submissions in other contexts
don't interfere with the above logic.
The situation can be more complicated with one-off submissions, but
fortunately, no such usage of foreign images is present.
Another wrinkle is simultaneous usage of the image as read-only in two
contexts. According to GL, this is not a hazard and requires no
synchronization. However this is broken in ANGLE even for non-foreign
images (see http://anglebug.com/42266349), because as what _seems_ like
read-only usage of the image from GL's point of view (like sampling from
the image), there are associated write operations from Vulkan's point of
view (image layout transitions and QFOT). This change does not attempt
to address this corner case.
Bug: angleproject:42263241
Bug: angleproject:42262454
Bug: angleproject:390443243
Bug: chromium:382527242
Change-Id: Idd4ef1fecfa3fccf1a4063f1bddb08d28b85386b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6184604
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
c3f9109e
|
2025-01-09T17:22:41
|
|
Vulkan: Change EventMaps from struct to class
For better encapsulation, this CL turns struct EventMaps to class
RefCountedEventArray.
Bug: angleproject:360274928
Change-Id: Ie28996fdb95d5a830399e6fa6cd5602f403e8725
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6164698
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
c7ad15e3
|
2025-01-23T13:37:28
|
|
Vulkan: de-duplicate ImageHelper::barrierImpl and barrierImplOneOff
barrierImpl is renamed to recordBarrierImpl barrierImplOneOff renamed to
recordBarrierOneOffImpl barrierImpl contains all the common logic
between recordBarrierImpl and recordBarrierOneOffImpl.
Bug: angleproject:390443243
Change-Id: I01ce9ea3f1f0acb30fe0efcdd20bd1caaa248a7c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6195570
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
fbd230f5
|
2025-01-23T12:59:06
|
|
Vulkan: Split ErrorContext into ErrorContext and Context
ErrorContext continue to be context for error handling. vk::Context is
added to serve as common base class for ContextVk and CLContextVk.
Bug: angleproject:390443243
Change-Id: Ifac0b1d2d714ce610693ce60a35459c6c9cddf1a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6191438
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
c1214ec2
|
2025-01-22T14:22:56
|
|
Vulkan: Rename Context to ErrorContext
In preparation for adding another Context (derived by GL and CL
contexts), which includes logic that pertains to command recording (such
as barrier tracking).
Bug: angleproject:390443243
Change-Id: Idf495b62e63fb9aa901a2f16447fdaf3c2acd90b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6191248
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
92cc4e02
|
2025-01-22T16:07:00
|
|
Vulkan: Fix incorrect initial RP layout for shared present
Renderpass was using `ImageLayout::ColorWrite` as initial layout for the
SharedPresent image. Vulkan validation did not detect errors because of
limitations (or bug?): once command buffer with barrier is submitted,
layers no longer track the current layout, and therefore skip the check.
In other words, it seems like VVL only track layout transitions within
a command buffer.
Transition to `ImageLayout::SharedPresent` currently performed using
one-off command buffer, which is always immediately submitted. This is
the reason why VVL was ignoring the error for so long.
Bug was discovered in `EGLSingleBufferTest.AcquireImageFromSwapImpl`
during local testing, where one-off command buffer was replaced with
outside RP commands. Other tests were still working fine, because they
are using `glClear()` in the very first flush - no renderpass in the
first submission, and so VVL can't track the layout once it is used in a
renderpass in the second submission.
Bug: angleproject:42262606
Change-Id: I19404b5be706e54e53890c2fec9cb4796296c698
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6182598
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
|
|
|
40267ddc
|
2025-01-14T12:51:00
|
|
Vulkan: Add bufferWrite for multiple shader stages
This is mostly a clean up CL. When a buffer is used in multiple shader
stages, it was inserting barrier multiple times by calling bufferWrite
in a loop. This creates unnecessary barrier against one shader stage to
another shader stage. This CL adds a multiple shader stages version of
bufferWrite that takes "const gl::ShaderBitSet &writeShaderStages" as an
argument, in consistency to bufferRead. Otherwise this creates a problem
in future CLs where we use VkEvent to track the write and you end up
with WAW of the VkEvent that has not submitted.
Bug: angleproject:360274928
Bug: angleproject:42262235
Change-Id: I923dc9df39318d337f67f4fa0f6a68f336df24f7
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6180948
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
1d25be59
|
2025-01-09T11:09:22
|
|
Vulkan: Pass Context instead of Renderer to BufferHelper APIs
This is preparation CL for later CL. In later CL we need to access
context argument in BufferHelper's barrier related functions. release()
also preferred to have context argument so that the events can be
recycled within share group. Because of this, a lot of functions has to
propagate back to pass context as argument instead of renderer.
Bug: angleproject:360274928
Change-Id: I13e930666eeeefbcff7b542d0e3126f3b07ce286
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6164686
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
d8a95bf7
|
2024-12-19T17:35:05
|
|
Vulkan: Protect OneOff commands recording with pool mutex
Bug: angleproject:384940864
Change-Id: I518c54ae4b0fc5da0e58d330f8c531bc8d65529e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6108843
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
a5016e31
|
2025-01-17T17:50:27
|
|
Vulkan: Fix typos found by gerrit spellchecker
Bug: angleproject:360274928
Change-Id: Idbffd7a4609f28d161bd0a11ace817856dcd750c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6182930
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Auto-Submit: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
aa6a9fae
|
2025-01-16T17:18:59
|
|
Vulkan: Selectively enable input attachment usage bit
Add VK_IMAGE_USAGE_INPUT_ATTACHMENT_BIT iff
supportsShaderFramebufferFetchDepthStencil feature is enabled.
Also, add noncoherent qualifier in a few FramebufferFetchTest
Bug: angleproject:352364582
Change-Id: I09c54a8d738b5cb4cbcf2716cdbff0c0ec9e31cf
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6181497
Commit-Queue: mohan maiya <m.maiya@samsung.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
ac7a85f4
|
2025-01-10T17:24:48
|
|
Vulkan: Replace copy image view with same read view in setStorage
1.Introduce a share flag in ImageViewHelper.
2.Update the share flag when copy view is same as read image view.
3.Only return read view when copy view is same read one.
Bug: angleproject:387392704
Change-Id: I6a3a9ca043ba16cdeb430cce53d40197618a0d44
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6147667
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
c75bd915
|
2024-12-10T23:01:44
|
|
Vulkan: Remove asyncCommandQueue
It's been years and it never showed an advantage. In the meantime,
performance without this feature seems close to native drivers (i.e. the
feature has lost its appeal) and it's frequently a source of
complication and bugs.
Bug: angleproject:42262955
Bug: angleproject:42265241
Bug: angleproject:42265934
Bug: angleproject:42265368
Bug: angleproject:42265738
Bug: angleproject:42266015
Bug: angleproject:377503738
Bug: angleproject:42265678
Bug: angleproject:173004081
Change-Id: Id8d7588fdbc397c28c1dd18aafa1f64cbe77806f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6084760
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: mohan maiya <m.maiya@samsung.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
d8f6df3e
|
2024-12-09T09:20:40
|
|
Vulkan: Fix assertion in RefCountedEvent::releaseImpl
RefCountedEvent uses non-atomic uint32_t for reference counting, so it
is not thread safe. To ensure we do not use it in a thread unsafe way,
there is an assertion I added in RefCountedEvent::releaseImpl that the
release call is not come from async command queue thread (all release
calls are expected come from context thread which should be protected by
context share group lock). A while ago dynamic rendering is implemented.
With dynamic rendering you can't do final layout change in render pass.
So the final layout change to Present is added to primary command buffer
at the end of RenderPassCommandBufferHelper::flushToPrimary(). And if
async command queue is enabled, that flushToPrimary is called from async
command queue thread, which triggers the assertion I added in
RefCountedEvent::releaseImpl(). This CL releases mCurrentRefCountedEvent
for this specific situation (present image + dynamic rendering +
asyncCommandQueue) so that we do not hit the assertion. The only
downside is that it will force to use pipelineBarrier for this specific
situation. But no one ships with asyncCommandQueue enabled, so there is
no real concern here as well.
Bug: angleproject:382580875
Change-Id: I042e3906db7f5bb7acb299997f8fc7e21b8350b6
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6072350
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
09578c42
|
2024-11-27T19:39:09
|
|
Vulkan: Cleanup CommandPoolAccess implementation
This is a follow up for:
Add a new mutex in CommandQueue to protect Vulkan Command Pool
crrev.com/c/angle/angle/+/6020895
Change simplifies `CommandPoolAccess` implementation as well as removes
source of bugs when need to know/remember what method from
`CommandPoolAccess` to use in order to collect/destroy the primary
command buffer.
Additionally, `CommandBatch` converted into a class to avoid invalid
use. The "retire" word replaced with "release" in methods such as
`releaseFinishedCommands()`.
Bug: b/362604439
Change-Id: Iaa72c55458604e5ea8ea5a402e437129a5c9180a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6056019
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
|
|
|
7adbb3e8
|
2024-11-26T17:06:07
|
|
Vulkan: Remove explicit destroy calls
Since now SharedPtr will automatically call destroy(device) when last
reference goes away, there is no need for explicitly calling
destroy(device) any more.
Bug: angleproject:372268711
Change-Id: I208b17cf7e090babd51d6f337c20fdfd74c75b6b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6052886
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
d81834b6
|
2024-11-26T15:25:35
|
|
Vulkan: Store VkDevice in vk::SharedPtr
So that we don't need to have two versions of destroy() APIs. In
previous CLs I had to add another version of destroy() that does not
take device argument due to SharedPtr may calls destroy when last
reference count goes away. Because we do not have device information at
that time, destroy() API was added but mostly just doing assertion that
Vulkan object has been explicitly destroyed. With this CL, we now stores
device in the SharedPtr so that we no longer need two destroy() APIs.
The explicit destroy(device) call will be removed in the next CL.
Bug: angleproject:372268711
Change-Id: Idcacbc3a922e17ac3d0f6056466b8f3aa084b02e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6052096
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
f51170b3
|
2024-11-21T16:30:40
|
|
Enable GL_KHR_texture_compression_astc_hdr
Vulkan supports GL_KHR_texture_compression_astc_hdr,
so this extension can be enabled in Angle.
Bug: angleproject:379186304
Change-Id: I438a120c3f884a7eefcd883ad71abf68f81cb473
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6038457
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
01dee1cb
|
2024-10-14T15:04:28
|
|
Add implementation for GL_EXT_texture_storage_compression
Bug: angleproject:352364583
Change-Id: I3dab4c68d5d0206d681e165e991217bd3de8eeb6
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6011055
Auto-Submit: Neil Zhang <Neil.Zhang@arm.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
6c1021ec
|
2024-11-22T16:48:45
|
|
Vulkan: Switch DescriptorSetLayout to use AtomicSharedPtr
SharedPtr has better semantics and safer to use. This CL removes direct
exposure of RefCounted object and also allows me to delete
BindingPointer class in later CL.
Bug: angleproject:372268711
Change-Id: I08a0dff3efcf794be843a4a548b9f2609bb9a5e1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6044328
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
87d61997
|
2024-11-21T14:20:55
|
|
Vulkan: Switch ShaderModule to use SharedPtr
This CL gets rid of many vk::RefCounted<vk::ShaderModule> usage which is
risky due to it allows you to direct manipulate reference count. Switch
to vk::SharedPtr manages the reference counting automatically.
Bug: angleproject:372268711
Change-Id: I14f5c509bcbd9ea7d17101637e033652a68710a0
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6039117
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
2e25ea1e
|
2024-11-13T13:59:51
|
|
Add a new mutex in CommandQueue to protect Vulkan Command Pool
Before this change, the CommandQueue::mMutex protects both:
1. Members of CommandQueue class, e.g. mInFlightCommands.
2. Operations on the same command pool and command buffers allocated
from the same command pool.
If one thread accesses resources 1, the other thread is doing operations
in 2, they could be blocked by each other. For example, if thread 1
calls eglClientWaitSync() to check if certain commands finish execution
(accessed resources in 1.), while thread 2 calls
eglMakeCurrent() to flush commands (issue operations in 2.), thread 1
could be blocked by thread 2. This is against the egl spec where
eglClientWaitSync() should return immediately when timeout passed to
the call is 0.
To fix the problem, this change creates a new class CommandPoolAccess
that wraps operations in 2, and protects command pool and command buffer
operations with a new mutex mCmdPoolMutex. With this new mutex, thread 1
and thread 2 would take different locks and not blocked by each other.
Bug: b/362604439
Change-Id: Iccf0ae65809ccb0f593c5e318fde03e89e0c0fa3
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6020895
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Yuxin Hu <yuxinhu@google.com>
|
|
|
21d747de
|
2024-11-20T11:54:15
|
|
Vulkan: Use vk::SharedPtr for SharedDescriptorSetCacheKey
This CL switches SharedDescriptorSetCacheKey from using c++
std::shared_ptr to our internal version of vk::SharedPtr. Also get rid
of an extra pointer indirection that SharedDescriptorSetCacheKey is a
reference counted of actual cache key instead of std::unique_ptr of
cache key.
Bug: angleproject:372268711
Change-Id: Id9af5070d24f67711d6decc3a30a260b8d4062d9
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6036302
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
ce53aff0
|
2024-11-05T16:57:57
|
|
Vulkan: Add per descriptorSet LRU cache eviction
Before this CL, the descriptor set cache eviction is at the pool level.
Either the entire pool is deleted or not. It is also not LRU based.
This CL adds a per descriptor set cache eviction and reuse evicted
descriptorSet before allocating a new pool. This eviction is LRU based
so that it is more precise. The mCurrentFrameCount is passed into
various API so that it can make eviction decision based on the frame
number. In this CL, anything not been used in last 10 frames will be
evicted and recycled before allocate a new pool.
Since eviction is based on individual descriptor set, not by pool,
ProgramExecutableVk no longer needs to track the DescriptorSetPool
object. mDescriptorPools has been removed from ProgramExecutableVk
class.
As measured by crrev.com/c/5425496/133 This LRU linked list maintenance
does not add any measurable time difference, but reduces total
descriptorSet pool count by one third (from 75 down to 48).
running test name: "TracePerf", backend: "_vulkan", story:
"batman_telltale"
Before this CL:
cacheMissCount: 200, averageTime:23998 ns
cacheHitCount: 1075445, averageTime:626 ns
descriptorSetEvicted: 0, descriptorSetPoolCount:75
Average frame time 3.9262 ms
After this CL:
cacheMissCount: 200, averageTime:23207 ns
cacheHitCount: 1025415, averageTime:602 ns
descriptorSetEvicted: 102708, descriptorSetPoolCount:48
Average frame time 3.9074 ms
BYPASS_LARGE_CHANGE_WARNING
Bug: angleproject:372268711
Change-Id: I84daaf46f4557cbbfdb94c10c5386001105f5046
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5985112
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
987cc0de
|
2024-08-06T12:16:37
|
|
Vulkan: Add release utility for BufferViewHelper
Add a release helper that doesn't require ContextVk for
BufferViewHelper.
Bug: angleproject:378103913
Change-Id: Ib468d152501ecaec1dd71c9c6ed5527b73a1afa5
Signed-off-by: Gowtham Tammana <g.tammana@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6004686
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
f44427b5
|
2024-11-05T15:18:59
|
|
Vulkan: Fix MSAA glReadPixels into PBOs
The temporary image used to resolve the MSAA framebuffer during
glReadPixels did not have the SAMPLED usage bit. Additionally, the
image was supposed to be garbage collected afterwards but ImageHelper's
release() function was accidentally immediately destroy()ing it.
This was not an issue with blocking glReadPixels paths, because the
command buffer was immediately flushed and the GPU work was waited on
before the image was destroyed in RendererScoped's destructor.
Bug: b/377437834
Change-Id: I1dca47172d6f363277059a848fe9446ac2a872d4
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5995530
Commit-Queue: Charlie Lao <cclao@google.com>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
e2cd9082
|
2024-11-05T04:07:17
|
|
Vulkan: Bugfix in setCurrentImageLayout
Make sure to update mLastNonShaderReadOnlyLayout and
mCurrentShaderReadStageMask when updating the current layout.
Bug: angleproject:40644776
Change-Id: Ie8652099a0d4caca9f9aea5bac38256a513b08e7
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5992020
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
|
|
|
79b6c7ab
|
2023-10-09T13:29:07
|
|
CL/Vulkan: Add fillWithPattern interface
In CL, the buffer can be requested to filled with a pattern. Adding a
pattern fill helper routine that fills up the buffer from CPU side.
Bug: angleproject:42267074
Change-Id: I144e9b7c6f4d1263f21cabc2491c46e8951e604f
Signed-off-by: Gowtham Tammana <g.tammana@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5916157
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
|
6b9d3762
|
2024-08-22T15:29:00
|
|
Vulkan: Optimize full texture clears
Currently, a full texture clear (glClearTexImageEXT()) is treated as
a special case of a partial clear (glClearTexSubImageEXT() with image
dims as the input). However, it can be further optimized by treating
it as a clear update.
* For full clears from EXT_clear_texture, the clear update path is
taken.
* It leads to a more optimized path, including the usage of the
following APIs:
* vkCmdClearColorImage()
* vkCmdClearDepthStencilImage()
* It uses the following enum: ClearTextureMode
* If a partial clear uses the extents for the entire image, it is
treated as a full clear.
* Updated the method to determine if a texture is renderable in
clearSubImageImpl().
* Added perf counter: fullImageClears
* Added new unit tests
* Single 3D texture full clear (Clear3DSingleFull)
* 2D RGB SNORM clear (Clear2DRGB8Snorm)
* Added Vulkan perf counter test for 2D and 3D color image clear.
* Updated the related skipped tests on Pineapple.
Bug: angleproject:42266869
Bug: angleproject:375425839
Change-Id: I12ef3002dee190d7f8f43204f7d3f76e05d0b54f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5806207
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
d0a0fd1a
|
2024-10-17T14:50:51
|
|
Vulkan: Skip pool eviction when cache is disabled
When cache is disabled, every time a new descriptorSet is allocated and
bind to program, the previous descriptorSet will be added to the tail of
garbage list, and the new descriptorSet is retrieved from the head of
the garbage list, if its GPU usage has been completed. This means there
will never have a situation that significant amount of descriptorSets
are needed, therefore no need for pool eviction. One possible situation
is that at one point you need a lot of descriptorSets and then after a
while you only need small amount of descriptorSets. In that case we
could delete the excessive unused descriptorSets. But since they are all
allocated from a pool, as long as there is still one descriptorSet in
the pool is used, you still can't destroy the pool. This means eviction
is really not much useful when cache is disabled.
Bug: angleproject:372268711
Change-Id: Id77b181b64e122f576ee43d11c39dc75bd681dcf
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5941126
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
af73a7eb
|
2024-10-18T17:19:29
|
|
Vulkan: Add WeakPtr to mirror std::weak_ptr
This is a follow up from previous CL crrev.com/c/5938947. Because of
pool eviction is based on reference count, there is need to have a weak
pointer to the reference counted pool that does not add an extra
reference count. This CL adds WeakPtr that works similarly to
std::weak_ptr, and replaced direct RefCountedDescriptorPool pointer with
WeakPtr wrapper. This is safer than RefCountedDescriptorPool in a way
that it does not allow modification of underline reference count. Also
the use of WeakPtr has been reduced to minimum in this CL.
Bug: angleproject:372268711
Change-Id: Idd6fa77432a9351269c968c961785a7cf5fab50c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5944061
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
08c1724f
|
2024-10-11T14:29:00
|
|
Vulkan: Support GL_ARM_shader_framebuffer_fetch_depth_stencil
Bug: angleproject:352364582
Change-Id: I63fd78314fa7ebccbf366c252e309a9c0f09c8c1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5938150
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
65fcf9c4
|
2024-10-26T10:53:18
|
|
Vulkan: Remove redundant dependent feature checks
Since [1], when a feature is overriden, the dependent features
automatically take the override into account. Tests no longer need to
account for dependent features, neither does the logic in the code.
[1]:https://chromium-review.googlesource.com/c/angle/angle/+/4749524
Bug: angleproject:42266725
Change-Id: I5440aba4a89cffbe710e26ad7de4cfee783e9bdf
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5967414
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
2dcc80dd
|
2024-10-17T13:59:23
|
|
Vulkan: allocateDescriptorSet to avoid repeated try on same pool
DynamicDescriptorPool::allocateDescriptorSet has a few steps. It first
tries to allocate from the same pool. Then tries to allocate from
mCurrentPoolIndex and then loops all existing pools. This CL keeps the
same basic logic, but avoids repeated tries on the same pool.
Bug: angleproject:372268711
Change-Id: Ic3099ac8c68688fe9afe452f808be29ac9063d51
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5926182
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
9a4c7495
|
2024-10-15T13:05:28
|
|
Vulkan: Add feature flag to enable descriptorSet cache
So that we can disable it to compare the performance difference.
Bug: angleproject:372268711
Change-Id: I02da254e5d58815741080634a2dd005617aa7432
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5936135
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
dd54eeec
|
2024-10-11T13:26:46
|
|
Reland "Vulkan: Track GPU progress for individual DescriptorSet"
This is a reland of commit 292102944add2ab30f4aa12a971cac456cc7726b
with the fix of garbage being added back to garbage list.
Original change's description:
> Vulkan: Track GPU progress for individual DescriptorSet
>
> Right now ProgramExecutableVk keeps VkDescriptorSet object, and
> DescriptorSetHelper is created when a cache entry becomes invalid.
> Further, DescriptorSetCache keeps the cache of {VkDescriptorSet,
> RefCountedDescriptorPoolHelper} pair. So we are having three different
> type of objects at different stages of life: VkDescriptorSet,
> DescriptorSetHelper, and {VkDescriptorSet,
> RefCountedDescriptorPoolHelper. This CL makes DescriptorSetHelper at
> creation and at cache and at garbage. With this change, you have a
> reference counted DescriptorSetHelper object (i.e, DescriptorSetPointer)
> during entire life cycle and is passed around between cache and program
> as is. This CL is preparation for the future CL where we may disable
> cache for descriptorSet. The descriptorSet will be added to garbage list
> and reused constantly without go through the cache code. We need to
> track the individual descriptorSet with ResourceUse so that it won't
> reuse until GPU is finished. This CL is making DescriptorSetHelper a GPU
> tracking object so that it will still just work when cache is disabled.
>
> Bug: angleproject:372268711
> Change-Id: I1cfb77cc5069b202d870388fd8809e265cdca90b
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5918586
> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
> Commit-Queue: Charlie Lao <cclao@google.com>
> Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Bug: angleproject:372268711
Change-Id: Ic920f99cc78cde1e94690bdbee3b885844fa155b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5954701
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
45cc47af
|
2024-10-22T21:41:22
|
|
Revert "Vulkan: Track GPU progress for individual DescriptorSet"
This reverts commit 292102944add2ab30f4aa12a971cac456cc7726b.
Reason for revert: Causing bot failure in later CLs
Original change's description:
> Vulkan: Track GPU progress for individual DescriptorSet
>
> Right now ProgramExecutableVk keeps VkDescriptorSet object, and
> DescriptorSetHelper is created when a cache entry becomes invalid.
> Further, DescriptorSetCache keeps the cache of {VkDescriptorSet,
> RefCountedDescriptorPoolHelper} pair. So we are having three different
> type of objects at different stages of life: VkDescriptorSet,
> DescriptorSetHelper, and {VkDescriptorSet,
> RefCountedDescriptorPoolHelper. This CL makes DescriptorSetHelper at
> creation and at cache and at garbage. With this change, you have a
> reference counted DescriptorSetHelper object (i.e, DescriptorSetPointer)
> during entire life cycle and is passed around between cache and program
> as is. This CL is preparation for the future CL where we may disable
> cache for descriptorSet. The descriptorSet will be added to garbage list
> and reused constantly without go through the cache code. We need to
> track the individual descriptorSet with ResourceUse so that it won't
> reuse until GPU is finished. This CL is making DescriptorSetHelper a GPU
> tracking object so that it will still just work when cache is disabled.
>
> Bug: angleproject:372268711
> Change-Id: I1cfb77cc5069b202d870388fd8809e265cdca90b
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5918586
> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
> Commit-Queue: Charlie Lao <cclao@google.com>
> Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Bug: angleproject:372268711
Change-Id: I4d3c34058d100112a098144276b52c0faf8d593a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5955529
Auto-Submit: Charlie Lao <cclao@google.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
|
|
99ba07d3
|
2024-03-26T00:58:57
|
|
CL/Vulkan: Implement createImage
Enabling functionality of:
- clCreateImage
Tests-Passing: OCLCTS.test_api get_image<1d|2d|3d>_info
Bug: angleproject:42266936
Signed-off-by: Rafay Khurram <r.khurram@samsung.com>
Change-Id: I0281f092bff13cdd81b87d596fdd15b33dda7e46
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5796527
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
29210294
|
2024-10-11T13:26:46
|
|
Vulkan: Track GPU progress for individual DescriptorSet
Right now ProgramExecutableVk keeps VkDescriptorSet object, and
DescriptorSetHelper is created when a cache entry becomes invalid.
Further, DescriptorSetCache keeps the cache of {VkDescriptorSet,
RefCountedDescriptorPoolHelper} pair. So we are having three different
type of objects at different stages of life: VkDescriptorSet,
DescriptorSetHelper, and {VkDescriptorSet,
RefCountedDescriptorPoolHelper. This CL makes DescriptorSetHelper at
creation and at cache and at garbage. With this change, you have a
reference counted DescriptorSetHelper object (i.e, DescriptorSetPointer)
during entire life cycle and is passed around between cache and program
as is. This CL is preparation for the future CL where we may disable
cache for descriptorSet. The descriptorSet will be added to garbage list
and reused constantly without go through the cache code. We need to
track the individual descriptorSet with ResourceUse so that it won't
reuse until GPU is finished. This CL is making DescriptorSetHelper a GPU
tracking object so that it will still just work when cache is disabled.
Bug: angleproject:372268711
Change-Id: I1cfb77cc5069b202d870388fd8809e265cdca90b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5918586
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
4bdcdf0d
|
2024-10-16T11:44:49
|
|
Vulkan: Switch RefCountedDescriptorPoolBinding to use SharedPtr
This mostly a clean up. RefCountedDescriptorPoolBinding is replaced with
DescriptorPoolPointer, which is defined as
SharedPtr<DescriptorPoolHelper>. It has more intuitive semantics to use.
Bug: angleproject:372268711
Change-Id: I0397111b5228e896c1d226e00930851319d955a0
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5938947
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
c52e8493
|
2024-10-11T14:21:19
|
|
Vulkan: Switch DescriptorPoolPointer to use SharedPtr
To make the reference counting easier to maintain, SharedPtr class is
added to automatically tracking the reference counting and object
creation/destruction. Right now we have BindingPointer class doing
similar things except it does not automatically manage the object
create/destroy, which makes it less robust as well as redundant code to
manage object life cycle. The other problem with BindingPointer is that
it does not work with normal assign/copy operator which made it hard to
read and use. SharedPtr uses exact same API semantics as
std::shared_ptr, which makes the reference counting very easy to use.
The main difference of SharedPtr and std::shared_ptr is that it does not
use any atomic or lock since it assumes user only uses it under thread
safe environment, which ANGLE's backend is.
This CL also changes mDescriptorPools to mDynamicDescriptorPools to make
it clear that it is dynamic descriptor pool not the descriptor pool.
This is also preparation CL for the next CL where we will use SharedPtr
to manage DescriptorSetHelper life cycle, which otherwise a bit
complicated to manually manage.
Bug: angleproject:372268711
Change-Id: I1033d9bf259bbc075a9b374d8a28e1f67d889873
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5926183
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
a19f0947
|
2024-10-17T22:42:30
|
|
Vulkan: Cache depth- and stencil-only views
Existing depth/stencil blit and resolve paths created temporary depth-
and stencil-only views. For
GL_ARM_shader_framebuffer_fetch_depth_stencil, such views are needed as
well.
In preparation for that extension, this change adds depth- and
stencil-only views to ImageViewHelper and allows them to be retrieved
through RenderTargetVk. The blit and resolve paths are consequently
simplfied as a side-effect.
Bug: angleproject:352364582
Change-Id: Ia822efb44ca7c82f63afce904eb19dd1bed02ff5
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5938149
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Yuxin Hu <yuxinhu@google.com>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
a1584f49
|
2024-10-11T21:17:32
|
|
Vulkan: Qualify framebuffer fetch with "Color"
In preparation for depth/stencil framebuffer fetch, many framebuffer
fetch symbols are affixed with Color to indicate that they pertain to
color framebuffer fetch logic.
Bug: angleproject:352364582
Change-Id: I86000ada5e6ef47387dec0b6a3fca589d816cdc2
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5926593
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
62f33a5c
|
2024-10-09T16:06:54
|
|
Vulkan: Make retainResource for descriptorSetPool consistent
Right now the cache hit and cache miss case are handled differently.
This CL makes it consistent. Now Caller of
DynamicDescriptorPool::getOrAllocateDescriptorSet will handle this
retainResource call regardless of cache hit or miss.
Bug: b/372268711
Change-Id: I11e47ab9e56a24eb68a0231c5e553ab6b8833c82
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5921640
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
b3d85cce
|
2024-09-30T14:28:35
|
|
Vulkan: Consolidate write colorspace override states
ColorspaceState struct is now used to cache write colorspace related
states to determine the colorspace of Vulkan draw image views.
ImageViewHelper methods are called during initialization and when
colorspace related states are toggled dynamically which in turn process
these states and determine the final write colorspace.
We can now fully support rendering to EGLImages, with colorspace
overrides, via texture or renderbuffer EGLImage targets
Bug: angleproject:40644776
Tests: ImageTest*Colorspace*Vulkan
MultithreadingTestES3.SharedSrgbTextureMultipleContexts*Vulkan
ReadPixelsPBOTest.SrgbUnorm*Vulkan
Change-Id: I2be2cd3b5b2b4ac8ecb803c34cde2b846cbd1cbe
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5901256
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
|
|
|
b38cc7fa
|
2024-09-30T12:43:09
|
|
Vulkan: Consolidate read colorspace override states
ColorspaceState struct is now used to cache read colorspace related
states to determine the colorspace of Vulkan read image views.
ImageViewHelper methods are called during initialization and when
colorspace related states are toggled dynamically which in turn process
these states and determine the final read colorspace.
Bug: angleproject:40644776
Tests: ImageTest*Colorspace*Vulkan
SRGBTextureTest.SRGB*TextureParameter*Vulkan
SRGBTextureTestES3.SRGBDecodeTexelFetch*Vulkan
Change-Id: I16b3666cd80865936b826dc0738fc9210dabeda9
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5901255
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
|
|
|
7c811715
|
2024-09-25T11:09:44
|
|
Vulkan: fix crash when clearing stencil with ClearBuffer
Follow up to [1] which fixed a crash with glClear, but the bug remained
with glClearBufferiv. This change refactors the "is stencil write
masked out" query to always take the framebuffer's stencil bit count
into account (practically always 8), which also happens to make the rest
of the code checking this query more accurate in the presence of
nonsense masks where the bottom 8 bits are 0.
[1]: https://chromium-review.googlesource.com/c/angle/angle/+/3315158
Bug: chromium:40207259
Bug: angleproject:42266334
Change-Id: I68a6b0b75c67ed2cdc8c4d03b243efe5495efce1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5889788
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Geoff Lang <geofflang@chromium.org>
|
|
|
eaffa034
|
2024-09-24T20:56:04
|
|
Revert "Vulkan: Consolidate colorspace override states"
This reverts commit bffcd235ba6c031603d798daaa98f1cf9a3f3e46.
Reason for revert: Breaks Android test `org.skia.skqp.SkQPRunner#UnitTest_DMSAA_dst_read`. Details:
https://b.corp.google.com/issues/369388539.
Original change's description:
> Vulkan: Consolidate colorspace override states
>
> ColorspaceState struct is now used to cache colorspace related states
> and used to determine the colorspace of Vulkan image views.
> ImageViewHelper methods are called during initialization and when
> colorspace related states are toggled dynamically which in turn process
> these states and determine the final read and write colorspaces.
>
> We can now fully support rendering to EGLImages, with colorspace
> overrides, via texture or renderbuffer EGLImage targets
>
> Bug: angleproject:40644776
> Tests: ImageTest*Colorspace*Vulkan
> MultithreadingTestES3.SharedSrgbTextureMultipleContexts*Vulkan
> SRGBTextureTest.SRGB*TextureParameter*Vulkan
> SRGBTextureTestES3.SRGBDecodeTexelFetch*Vulkan
> ReadPixelsPBOTest.SrgbUnorm*Vulkan
> Change-Id: I1cc2b5bd834b519b83deab4d80a2fcaabeb271d6
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5841290
> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
> Reviewed-by: Charlie Lao <cclao@google.com>
> Commit-Queue: mohan maiya <m.maiya@samsung.com>
Bug: angleproject:40644776
Change-Id: I5bf6cf2ed0c8ec22fc02d8c3da92673ee85fe002
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5888506
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Yuxin Hu <yuxinhu@google.com>
|
|
|
bffcd235
|
2024-09-13T14:58:00
|
|
Vulkan: Consolidate colorspace override states
ColorspaceState struct is now used to cache colorspace related states
and used to determine the colorspace of Vulkan image views.
ImageViewHelper methods are called during initialization and when
colorspace related states are toggled dynamically which in turn process
these states and determine the final read and write colorspaces.
We can now fully support rendering to EGLImages, with colorspace
overrides, via texture or renderbuffer EGLImage targets
Bug: angleproject:40644776
Tests: ImageTest*Colorspace*Vulkan
MultithreadingTestES3.SharedSrgbTextureMultipleContexts*Vulkan
SRGBTextureTest.SRGB*TextureParameter*Vulkan
SRGBTextureTestES3.SRGBDecodeTexelFetch*Vulkan
ReadPixelsPBOTest.SrgbUnorm*Vulkan
Change-Id: I1cc2b5bd834b519b83deab4d80a2fcaabeb271d6
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5841290
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
|
|
|
e38d25b1
|
2024-06-21T18:22:32
|
|
Vulkan: Implement EXT_clear_texture
* Added new functions to TextureVk to clear the image.
* clearImage()
* clearSubImage()
* Both implemented via clearSubImageImpl(), with the former a
special case of the latter.
* For multisample or renderable images, stagePartialClear() from
ImageHelper is called to add the update.
* For single-sampled non-renderable images, a buffer is filled with
the pixel data and applied to the image as a buffer update.
* Added new update type: ClearPartial
* Used for renderable textures. This includes multisample textures.
* LOAD_OP_CLEAR is used in a render pass to perform the clear.
* UtilsVk::clearTexture()
* (Uses ClearTextureParameters)
* Uses the following functions to get the VkClearValue from the
input data and format:
* GetVkClearColorValueFromBytes()
* GetVkClearDepthStencilValueFromBytes()
* ClearPartial updates can also be superseded and removed similar to
Buffer updates.
* Updated UtilsVk::startRenderPass() to accept a VkClearValue* as an
input arg. If used, the render pass will use LOAD_OP_CLEAR.
* Enabled the feature "clearTextureEXT" on Vulkan.
* Added new unit tests in ClearTextureEXTTest for various formats and
pixel sizes.
* Added related multisample tests in FramebufferTest.cpp.
* FramebufferTest_ES31.ClearTextureEXT*
* Disabled some of the new tests failing using OpenGL.
* Disabled stencil-only-related tests on Pineapple.
Bug: angleproject:42266869
Change-Id: I89c631d68a4ed63d9991abe1783333255ade20dd
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5778348
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
9685cb96
|
2024-09-17T11:41:28
|
|
Vulkan: Clean up PackedClearValuesArray::store
The code was a bit confusing, raising question why there is check of
aspectFlags != VK_IMAGE_ASPECT_STENCIL_BIT. I believe this was
originally from
https://chromium-review.googlesource.com/c/angle/angle/+/2142711, and
then followed by
https://chromium-review.googlesource.com/c/angle/angle/+/2410366. The
code seems to having some special logic to handle packed depth stencil
clear value. This code may have been changed a bit. When I am looking at
current code base, I am not seeing good reason doing it this way. Caller
is handling the packed format by reading out depth value and pack them
together and then store. This CL replaces store/storeNoDepthStencil
pair to storeColor/storeDepthStencil.
Bug: b/167301719
Change-Id: I40cfca1e51654f5ddaf4b2e8460ae5a26c656f2b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5870921
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
1b4d6185
|
2024-09-12T09:18:46
|
|
Vulkan: Cleanup sRGB related code
Image and image view code is littered with sRGB related enums, even
in places that don't deal with sRGB. Remove sRGB related parameters
from initLayerImageView and getLevelLayerDrawImageView methods, which
now assume default values. Add dedicated methods that allow overriding
sRGB state values.
Also introduce ColorspaceState struct that consolidates all sRGB
related states, this will be used in follow up changes to track
and infer colorspace of image views
Bug: angleproject:40644776
Change-Id: Ifb366db48043e376f9ff6c30c852c44dd96562a1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5860808
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
|
|
|
937c5dc8
|
2024-09-09T12:18:55
|
|
Vulkan: Make image{Read,Write} helper interface api agnostic
Removing ContextVk dependency on the imageRead/imageWrite helper utility
functions.
Bug: angleproject:42266971
Change-Id: I493e1fb11e8ae192f766c822cbee278c49c23bfe
Signed-off-by: Gowtham Tammana <g.tammana@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5845197
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
7080b766
|
2024-08-16T11:31:39
|
|
Vulkan: Move LineLoopHelper from vk to rx namespace
There is no line loop support in vulkan. LineLoopHelper is a utility
function for backend, not a helper function for vulkan object. So it is
better fit in rx namespace instead of vk namespace.
This also helps my next CL where I am going to change
initBufferForVertexConversion to take a ConversionBuffer instead of
BufferHelper. LineLoopHelper uses initBufferForVertexConversion, which
means I have to change LineLoopHelper to uses ConversionBuffer. This
causes header inclusion problem that now vk namespace object end up have
to include rx namespace header. This CL fixes this inclusion problem by
moving it to the proper namespace.
Bug: b/357622380
Change-Id: I6d6cf1aa926f726bb1b1ab1017bcab092eaf5d37
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5787502
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
f8fc8ac3
|
2024-08-05T11:50:11
|
|
Vulkan: Remove dependency on ContextVk for CommandBufferHelper
Following on the changes in [1], this makes the
`CommandBufferHelperCommon` and `OutsideRenderPassCommandBufferHelper`
interfaces independent of `ContextVk` state. Any dependency is made
explicit.
In addition, interfaces that are not specific to GLES context are also
updated.
[1]: Commit (bcf814fda5 Vulkan: Constrain the dependency on ContextVk in
BufferHelper)
Bug: angleproject:8544
Change-Id: I7d90ad915e8c14187ab5584453b9e8802bd91e2b
Signed-off-by: Gowtham Tammana <g.tammana@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5319147
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
cc7d0220
|
2024-07-31T14:22:38
|
|
Vulkan: Fix serial mismatch during mid-loop flush
Currently, if the total buffer updates to the image surpasses a
certain threshold, it results in a flush. However, this can cause
discrepencies in the queue serial, which can result in incorrect
behavior on some platforms.
* Updated flushStagedUpdatesImpl() so that the image serial after
applying the updates matches that of the current outside command
buffer.
* That includes when there is a flush in the middle of the update
loop, resulting in submission and new queue serial for the CB.
* Added a unit test to check if a large texture can uploaded and
deleted after a second small texture is uploaded.
* Texture1UploadThenTexture2UploadThenTexture1Delete
* Added a unit test for flushing when uploading cubemap textures.
Bug: b/351650806
Bug: b/356192937
Change-Id: I7f9b20e4b7fd49115f22081a9733b4d44b740e4a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5744377
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
bd3a3308
|
2024-07-22T14:03:20
|
|
Vulkan: Remove implicit image barrier for shader write
When app uses compute or fragment shader to write to an image and makes
multiple dispatchCompute or draw calls, right now we are inserting an
implicit barrier to ensure WAW is hazard free. But Spec says that
"Explicit synchronization is required to ensure that the effects of
buffer and texture data stores performed by shaders will be visible to
subsequent operations using the same objects". This CL records the bits
from the last glMemoryBarrier call and will skip the barrier calls in
ContextVk::updateActiveImages if there is no layout change, unless there
is requirement from prior glMemoryBarrier.
Bug: angleproject:350994515
Change-Id: I8bdeeb658993824369824aaa0f25cb4b6e3785f7
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5719024
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
7691cea7
|
2024-07-22T13:46:14
|
|
Vulkan: Remove seamful cubemap emulation
Practically, the Vulkan backend is never expected to run on ES2
hardware. It _may_ for WebGL, but seamful cubemap emulation was
disabled for webgl anyway.
Bug: angleproject:354729454
Change-Id: Iafa20fbdbe232c4df4c777b12e7698ef7a87cf24
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5730143
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
0d458614
|
2024-07-18T00:00:00
|
|
Vulkan: Fix PBO readbacks with small row length
Use CPU path when the row length is
smaller than the source area width.
Fixed: angleproject:354005999
Change-Id: I5c4686ca5387a98c6137868afb19c333aed8ac21
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5724591
Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
1db80b88
|
2024-07-10T12:47:42
|
|
Reland "Vulkan: Use VK_KHR_dynamic_rendering[_local_read]"
This is a reland of commit c379ff48043a47e444c388c45270db40d3172d50
Original change's description:
> Vulkan: Use VK_KHR_dynamic_rendering[_local_read]
>
> Bug: angleproject:42267038
> Change-Id: I1f4eb0f309992a9c1c287a69520dadf5eff23b26
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5637155
> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
> Reviewed-by: Charlie Lao <cclao@google.com>
Bug: angleproject:42267038
Change-Id: I083e6963b5421386695e49a9872edbb2016c9763
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5691342
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
1f87cbc9
|
2024-07-15T13:07:35
|
|
Vulkan: Fix late-added resolve attachment tracking
Resolve attachments may be added after the fact to a render pass due to
glBlitFramebuffer or eglSwapBuffer. Previously, only the resolve image
views were tracked by the render pass, and otherwise the state tracking
(layout, content defined, etc) treated the resolve images as generically
written-to by the render pass.
As a result, the render pass was unable to finalize the layout of the
resolve images early. Optimizing the layout of the swapchain image when
the surface is multisampled for example was not done due to this issue.
In this change, when resolve attachments are added late, they are
tracked identically to when they are added at the beginning of the
render pass, fixing the issues described above.
Bug: angleproject:42265625
Bug: angleproject:42266019
Change-Id: I765560762bb8caf39ba1096fb028177201c082d7
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5707470
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
6578b9c0
|
2024-07-09T17:19:47
|
|
Vulkan: Exclude compute/preFrag only access images from event
This further restricts VkEvent usage for certain usage patterns. If
image is only used by compute, use VkEvent also will not benefit it
since compute itself can not overlap with compute (assume there is only
one compute engine and compute work can not overlap with each other).
Similarly this also applies to KPreFragment stages. Basically after this
CL, use of VkEvent is limited to usages that crosses different execution
units (modeled against tiler based GPUs where there are pre-fragment
stages and fragment stages and compute and all others). Before this CL,
we are seeing performance regression with antutu_refinery and
streets_of_rage_4 due to overhead of VkEvent, which is fixed with this
CL.
Bug: b/336844257
Change-Id: I5ca5d813daefe9bfcaf48f831340cdf9559f8104
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5692760
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
402c8ccd
|
2024-06-26T19:28:21
|
|
Vulkan: Limit VkEvent for images that has fragment access only
One of the problem with VkEvent is that the overhead comes with
VkCmdSetEvent causes some app traces regress performance. The goal in
this CL is to further limit VkCmdSetEvent to images that that we think
are potentially subject to the pipeline bubble. The bubble usually
occurs when accesses are alternated between different stages,
specifically a mix between vertex/transfer/compute/fragment. If all
accesses are from fragment shader or color attachment, then use VkEvent
will not be beneficial, but only adds extra overhead. This CL adds the
heuristic tracking for image access. Every time an image is used, a bit
is used to indicate the usage involves fragment only or not. A bitfield
is used to track the window of the history of the usage. When image is
used (usually at the time queueSerial is set), we shift the history bits
left and the new bit is added to the right most bit. If all accesses are
from the fragment shader or color attachment, then no need to use
VkEvent. For example, if a texture is always sample from fragment shader
only, then VkEvent will not used. Another common usage is you render to
it and then texture from it, it will also excluded from VkEvent with
this CL.
Bug: b/336844257
Change-Id: I175194f30b8f1d9b8fbf38ad594778474548016f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5664170
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
584fbcee
|
2024-07-10T12:43:34
|
|
Vulkan: Rework swap-time barrier logic
Avoids unnecessary transitions when overlay is enabled
Bug: angleproject:42267038
Change-Id: I0534911c0142c5e94cf3be112283fb98fcde0f6c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5691346
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
373ac541
|
2024-07-10T11:14:47
|
|
Vulkan: Make surface RP check independent from framebuffer object
With dynamic rendering, there is no framebuffer object, so checking
whether the currently open render pass belongs to the window surface (at
swap time) is made independent from these objects.
Bug: angleproject:42267038
Change-Id: I408e2376ba865b64fa1e8890316e8f57c08c695f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5691345
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
867697b7
|
2024-07-09T10:43:02
|
|
Vulkan: Add ImageHelper::onRenderPassAttach helper function
RenderPass attachments has one difference compared to other images. The
QueueSerial has to be set first so that we can detect an image is being
used as attachment. But the layout is delayed until the endRenderPass
time. This CL adds a onRenderPassAttach API to set the queueSerial so
that we have a central place to adding other code if needed.
Bug: b/336844257
Change-Id: I894fff83745691e8167a295c71cbc2e1d22f1343
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5689452
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
9ca3ed37
|
2024-07-08T16:48:51
|
|
Vulkan: Let ContextVk::onResourceAccess uses retainImage
Right now ContextVk::onResourceAccess calls retainResource for
everything. Mean time we also have a retainImage() function, which adds
a bit confusion to why we have two retain API. This CL moves retainImage
from CommandBufferHelperCommon to OutsideRenderPassCommandBufferHelper
and RenderPassCommandBufferHelper so that ContextVk::onResourceAccess
can use retainImage directly. The slightly behavior difference between
RenderPassCommandBufferHelper and OutsideRenderPassCommandBufferHelper's
retainImage is from compute shader's image access, which we are using
VkEvent to track images, mainly due to we tailor VkEvent to the
manhattan's usage case, which involves compute.
Bug: b/336844257
Change-Id: Id3fb694f683289a4720cc279387dbc27642745de
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5686352
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
7d461b21
|
2024-07-10T14:11:53
|
|
Revert "Vulkan: Use VK_KHR_dynamic_rendering[_local_read]"
This reverts commit c379ff48043a47e444c388c45270db40d3172d50.
Reason for revert: Regresses CPU perf and memory when _not_ using DR
Original change's description:
> Vulkan: Use VK_KHR_dynamic_rendering[_local_read]
>
> Bug: angleproject:42267038
> Change-Id: I1f4eb0f309992a9c1c287a69520dadf5eff23b26
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5637155
> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
> Reviewed-by: Charlie Lao <cclao@google.com>
Bug: angleproject:42267038
Change-Id: I3865f0d86813f0eeb9085a92875a33bd449b907f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5691337
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
c379ff48
|
2024-06-10T22:01:57
|
|
Vulkan: Use VK_KHR_dynamic_rendering[_local_read]
Bug: angleproject:42267038
Change-Id: I1f4eb0f309992a9c1c287a69520dadf5eff23b26
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5637155
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
8c546d35
|
2024-06-25T12:49:40
|
|
Vulkan: Limit VkEvent for usage matters for Manhattan31 only
If we use VkEvent to track all image operations causes performance
regression on some app traces, including manhattan10 trace. This mainly
because of CPU overhead comes with VkCmdSetEvent, mostly inside vulkan
driver. These app traces likely not benefit from VkEvent because the
specific bubble (false dependency) does not manifest on these app
traces, but the CPU overhead takes a performance toll on it. In order to
strike a balance between benefit and overhead, this CL removes most of
VkEvent usage and only leaves the ones that matters for manhattan31. The
only we still keeps are generateMipmap, dispatchCompute, texture
sampling. We can always add more if more beneficial usage cases comes up
and no regression in other traces.
Bug: b/336844257
Change-Id: I346fe70bc33e57edf04e933a2db0f79738c4481d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5654737
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
46dd6457
|
2024-06-25T15:56:15
|
|
Vulkan: Use DONT_CARE ops for missing D/S aspects
Simplifies op tracking with dynamic rendering.
Bug: angleproject:42267038
Change-Id: I394c154d94458c470190fea66d82c408e6f33725
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5655873
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
d193d51b
|
2024-06-17T22:46:08
|
|
Replace issue ids post migration to new issue tracker
This change replaces anglebug.com/NNNN links.
Bug: None
Change-Id: I8ac3aec8d2a8a844b3d7b99fc0a6b2be8da31761
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5637912
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
5703bd61
|
2024-06-14T14:12:41
|
|
Vulkan: Further optimize ProgramExecutableVk::resetLayout
1. Handle compute pipelines similar to how we handle graphics pipelines
2. Track valid compute pipeline permutations
Bug: angleproject:8297
Change-Id: I58200517e5a44a2b3092777ea24d1529ceee00f5
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5634574
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
06f1b72f
|
2024-06-03T08:59:46
|
|
Vulkan: Bugfix in MSRTT emulation
Transient multisampled images should have no mips. Enforce this
requirement when MSRTT is being emulated
Bug: angleproject:4836
Tests: MultisampledRenderToTexture*MultipleLevelsMultisample*
Change-Id: I6df21bbb49a4c45aa3ee321f7d49b81f55352562
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5601347
Commit-Queue: mohan maiya <m.maiya@samsung.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
75625e6b
|
2024-06-11T11:10:24
|
|
Vulkan: Clean up ImageHelper::flushSingleSubresourceStagedUpdates
This CL changed some logic to use helper function to make logic more
clear.
Bug: angleproject:42263375
Change-Id: I5d0ec0f6b0a315f9e755939420a655976a2fef5b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5620736
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
b4f3824e
|
2024-05-31T11:36:32
|
|
Reland "Vulkan: Defer texture data flush until data provided for all levels"
This is a reland of commit 490c056a88a33870cb4ba2a7906b0a9688d96262
Original change's description:
> Vulkan: Defer texture data flush until data provided for all levels
>
> One of the major overhead with VkEvent is seeing with first frame where
> all textures are being specified. The immutable textures, we always
> immediately flush out the update as data provided for each level. This
> means one VkEvent is created and SetEvent is called per level. This CL
> delays the flush until data for all levels are provided, thus there is
> only one flush per texture instead of per level. With this CL asphalt_9
> is no longer timeout on bots when VkEvent is enabled.
>
> There is also another benefit comes with this CL. On all desktop GPUs,
> ASTC format texture are falling back to RGBA8. We always stage a clear
> for the emulated format. That staged clear are able to be removed if
> data is provided later. Because of we flush out staged update when first
> level data is provided, all staged clear for the subsequent levels are
> also gets flushed out, losing the chance to be removed. This CL will
> allow all staged clears being removed.
>
> Bug: b/343976993
> Bug: b/336844257
> Change-Id: Ica731ea57db771b16966f4da92ccdc551ae93d81
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5588816
> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
> Commit-Queue: Charlie Lao <cclao@google.com>
Bug: b/343976993
Bug: b/336844257
Change-Id: Iabcc1b4ebca7d6f34a0e7f109795392fc00e7eda
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5606146
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
5b8e380c
|
2024-06-10T17:54:25
|
|
Vulkan: Fix bug in ImageHelper::flushSingleSubresourceStagedUpdates
There is another bug in ImageHelper flush staged update code path that
exposed by a new test I added in crrev.com/c/5606145. When we render to
a multi-layered texture and that layer we are trying to render to has a
staged clear and followed by an buffer update, and if the buffer update
overlaps with layer we try to render to but not exact match, we will
incorrectly think that the glClear call can override the buffer update.
The bug here is that ImageHelper::flushSingleSubresourceStagedUpdates is
using ImageHelper::SubresourceUpdate::isUpdateToLayers() call to decide
if buffer update will be overriden. That isUpdateToLayers is only
looking exact layer range match. So in this case because the buffer
update's layer range is bigger than glClear, it returns false. This
causes the flushSingleSubresourceStagedUpdates think it is outside the
layer range we try to render, and causes rendering bug. This CL renames
isUpdateToLayers to isLayerRangeExactMatch to reflect the actual
behavior of the function. This CL also adds new API isWithinLayerRange
and called by flushSingleSubresourceStagedUpdates to decide if the
updates can implement using renderPass loadOp.
Bug: angleproject:345532371
Bug: angleproject:42263375
Change-Id: Ia604ed1a61b56d7bde05f12a03baef8f00af2b17
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5619730
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
81452425
|
2024-06-07T11:49:28
|
|
Vulkan: Fix keeping overlapped updates in flushStagedUpdatesImpl()
There is an existing bug in ImageHelper::flushStagedUpdatesImpl() that
caused webGPU test to fail when my CL crrev.com/c/5588816 landed. The
bug is that when we flush out an update, we walk through the vector
updates and if the update is outside the range of requested layer range,
we stash away the update to updatesToKeep list. We only flush out the
updates that are intersects with the requested layer range. The bug here
is that if one of the update has bigger layer range than the requested
layer range, and there is an update that intersects with that update's
layer range but not overlap with requested layer range, now that update
may incorrectly gets moved to updatesToKeep list. Later on when that
updatesToKeep list gets flushed out, you end up overwriting the image
content.
This CL adds a new function adjustLayerRange() that first walk the
updates and calculate the actual layer range that will be flushed and
then use that adjusted layer range to determine if an update should be
kept or flushed.
Bug: angleproject:345532371
Change-Id: I59ef4ec935354766d35e4cfbb6ce4b13d9a2e868
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5607276
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
f5d6112b
|
2024-06-05T17:20:45
|
|
Vulkan: Remove EventStage::BottomOfPipe and AllCommands
These two StageFlags never being used in VkCmdSetEvent, and should not
be used given that these are very strong synchronization. They are
removed in this CL.
Bug: b/336844257
Change-Id: I68a47a5459dadf56ad5c269ebb3af55887110cc7
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5601811
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
295ff607
|
2024-06-05T14:49:33
|
|
Vulkan: Precompute stageMask of kImageMemoryBarrierData
Right now every time we need a pipelineStage in kImageMemoryBarrierData,
we are doing a bitwise AND with
mSupportedVulkanPipelineStageMask. This get called multiple
times from barrier call. This CL adds
mImageLayoutAndMemoryBarrierDataMap that has already precomputed all
stageMask, thus avoid run time bitwise OR.
This CL also precomputes the bufferWritePipelineStageMask so that
flushImpl can be use it without construct every time.
Bug: b/345279810
Change-Id: I878bd31c967cd217477061976f07df13b043fa7f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5601073
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
|