|
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>
|
|
|
87bbeaee
|
2024-06-03T15:04:25
|
|
Vulkan: Reduce VkEvent counts by using EventStage enums
Right now we are using too many VkCmdSetEvents and causes some of the
deqp tests timeout on CI bots (because of VVL is very slow along with
the number of events being used). RefCountedEvents are per ImageLayout.
But some of ImageLayous have the same VkPipelineStageFlags, for example
TransferSrc and TransferDst. This CL changes RefCountedEvent to per
unique VkPipelineStageFlags instead of per ImageLayout, thus allows
TransferSrc and TransferDst to share one VkEvent.
To do that, EventStage enum and kEventStageAndPipelineStageFlagsMap
table are added to define the predefined VkPielineStageFlags that ANGLE
uses. RefCountedEvent now keeps EventStage instead of ImageLayout. To
further reduce the CPU overhead, a customized
mPipelineStageMaskAndEventMap table is precomputed in renderer with
supported vulkan pipeline stages.
With this CL, previously timed out tests such as
KHR-GLES3.copy_tex_image_conversions.forbidden.renderbuffer_cubemap* now
passing.
Bug: b/336844257
Change-Id: I021a8f1d6112d5cf96c61652c9af5f679b1172eb
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5597732
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
92f198f6
|
2024-06-06T21:42:35
|
|
Revert "Reland "Vulkan: Defer texture data flush until data provided for all levels""
This reverts commit b93af07ac1ddb9f2e262d611d155f4b63f18999f.
Reason for revert: b/345532371
Original change's description:
> 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: Ie987582a44e0d73abd38ce8f6813ff8995e907e2
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5597810
> Reviewed-by: Cody Northrop <cnorthrop@google.com>
> Commit-Queue: Charlie Lao <cclao@google.com>
Bug: b/343976993
Bug: b/336844257
Change-Id: I9356da6b4cdb21dba47758d6e937d1ae02f0ae34
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5606144
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
|
|
|
b93af07a
|
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: Ie987582a44e0d73abd38ce8f6813ff8995e907e2
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5597810
Reviewed-by: Cody Northrop <cnorthrop@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
170851ff
|
2024-06-04T09:01:11
|
|
Revert "Vulkan: Defer texture data flush until data provided for all levels"
This reverts commit 490c056a88a33870cb4ba2a7906b0a9688d96262.
Reason for revert: breaks win-trace
https://ci.chromium.org/ui/p/angle/builders/ci/win-trace/6014/overview
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: I25854b855334c4cac1c2b40467d8e2ecb7661b8f
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5593935
Auto-Submit: Yuly Novikov <ynovikov@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
|
|
|
490c056a
|
2024-05-31T11:36:32
|
|
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>
|
|
|
34b832a3
|
2024-05-24T13:38:58
|
|
Vulkan: Add RefCountedEvent recycler
Previously the recycler was disabled due to race between resetEvent and
setEvent. This CL splits mFreeStack into two list: mEventsToReset and
mEventsToReuse. Events are first added to mEventsToReset list. Then at
OutsideRenderPassCommandBufferHelper::flushToPrimary time,
VkCmdResetEvents are added to reset all events in mEventsToReset list,
and that reset operation is tracked by mResettingQueue. When reset
command is completed, events moved into mEventsToReuse list. Since
access to renderer's RefCountedEventRecycler requires lock,
RefCountedEventCollector (a queue of events) is passed between
ShareGroupVk and renderer's recycler to minimize the locked access.
Bug: b/336844257
Change-Id: Iffac095729a81ba65a43df68cc9255d76e4be7c9
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5576757
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
018188c7
|
2024-05-28T14:44:14
|
|
Vulkan: Fix CachedPreferCoherent to actually require cached
VK_MEMORY_PROPERTY_HOST_CACHED_BIT should be in requiredBits instead of
preferredBits for CachedPreferCoherent buffer.
This again caused pixel6 test failures. flush() call is added right
after buffer allocation to fix the test failure. This likely is due to
the spec says " If a range of non-coherent memory is written by the host
and then invalidated without first being flushed, its contents are
undefined.".
Bug: b/339562049
Change-Id: Ie8529722bd03534598b03983ba447131573b1879
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5578276
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
0d772ebe
|
2024-05-21T16:41:41
|
|
Vulkan: Cleanup releaseToExternal/acquireFromExternal API
This CL addresses some feedback from the earlier CLs.
Bug: b/337135577
Change-Id: I90c26a9374254af69bf00eb6580ce9580b71ca5a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5561465
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
d27c0f95
|
2024-05-21T16:27:08
|
|
Vulkan: Fix UNASSIGNED-SubmitValidation-WaitEvents-WrongQueue
Before this CL, when eventBarrier is used for images, we may see
UNASSIGNED-SubmitValidation-WaitEvents-WrongQueue VVL error. What
happens is that when context is created with medium priority and image
is used, we created VkEvent that was set on medium priority VkQueue.
Later on when a new context with higher priority is added to the share
group, we upgrade all contexts to high priority and all subsequent
commands will be submitted to high priority VkQueue. Now if the image is
used and we call VkCmdWaitEvent, we end up waiting on new VkQueue for an
event that was set on the old VkQueue. This violates the vulkan spec.
With all previous prepartion CLs, now Context and ImageHelper all keeps
track of which DeviceQueueIndex it was last used. We can just check the
DeviceQueueIndex and fallback to pipelineBarrier if they has changed.
When pipelineBarrier is used, the event will be released, and subsequent
event will be created on new queue. So this fallback should only occur
once for the ImageHelper objects that was experiencing the queue switch.
ImageHelper::barrierImpl already checking DeviceQueueIndex changes, so
this will automatically works for VkEvent. This CL only needs to add the
support for ImageHelper::updateLayoutAndQueue.
Bug: b/336844257
Change-Id: Ia3f1caee4f3c8e98dc858d387e93d3b2d6eb8053
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5556443
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
1a9a703b
|
2024-05-21T11:14:40
|
|
Vulkan: Add DeviceQueueIndex to Context/BufferHelper/ImageHelper
This CL adds a utility class DeviceQueueIndex, which encapsulates
queueFamilyIndex and the queueIndex into one integer value so that we
can pass around to barrier function. vk::Context and BufferHelper and
ImageHelper class now keeps mCurrentDeviceQueueIndex instead of
mCurrentQueueFamilyIndex. For All contexts by default it gets the
default queue from renderer (which is always the one corresponding to
Medium priority). For ContextVk, when priority changes it update
mCurrentDeviceQueueIndex to match new context priority.
Bug: b/337135577
Change-Id: I62cc483cfdb3e974d38db074e671c57299300074
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5555903
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
b22cce5f
|
2024-05-21T10:55:27
|
|
Vulkan: Remove Renderer::getDeviceQueueIndex
Renderer::getDeviceQueueIndex() returns queueFamilyIndex. There is a
function that already returns mCurrentQueueFamilyIndex, so this function
is now removed.
This CL also renames ImageHelper::isQueueChangeNeccesary to
isQueueFamilyChangeNeccesary
Bug: b/337135577
Change-Id: I3cd9ded1414d1389e162aaa5399c231a987f871e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5553067
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
9ed415e5
|
2024-05-16T14:28:31
|
|
Vulkan: Clean up in ImageHelper::updateLayoutAndBarrier
There was a duplicated pipelineBarrier wait in
ImageHelper::updateLayoutAndBarrier that possibly come from bad code
merge. It is removed in this CL.
The check of hasEvent and subsequently call addAdditionalStageAccess has
moved out of addMemoryEvent and make its own function so that it only
affects the specific case where the image is used in different shader
stage in the *same* render pass.
Bug: b/336844257
Change-Id: I78b0c952be32124cb0fb6a2cf750df41f6c8259d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5544450
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
f82d812d
|
2024-05-16T15:46:05
|
|
Vulkan: Fix EventBarrier bug when asyncSubmission is enabled
Since we have moved RefCountedEvent garbage collection into
ShareGroupVk, we have changed the reference counting to use non-atomic.
There is a bug with async submission code path where the
executeSetEvents gets called from submission thread which does not have
share group lock. This CL fixes this bug by storing VkEvent in
RenderPassCommandBufferHelper so that executeSetEvents uses VkEvent
instead of RefCountedEvent when async submission is enabled.
This CL also adds assertion that RefCountedEvent::releaseImpl does not
get called from async submission thread.
Bug: b/336844257
Change-Id: Ifcbd5a09d2bc7636cc15b2c6728dbbca103d4d9c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5544449
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
0636b509
|
2024-05-06T12:36:20
|
|
Vulkan: Move RefCountedEvent GC and recycler to ShareGroupVk (2/3)
One of the problem we had with RefCountedEvents is CPU overhead comes
with it, and some part of the CPU overhead is due to atomic reference
counting. The RefCountedEvents are only used by ImageHelper and
ImageHelpers are per share group, so they are already protected by front
end context share lock. The only reason we needs atomic here is due to
garbage cleanup, which runs in separate thread and will decrement the
refCount. The idea is to move that garbage list from RendererVk to
ShareGroupVk so that access of RefCountedEvents are all protected
already, thus we can remove the use of atomic. The down side with this
approach is that a share group will hold onto its event garbage and not
available for other context to reuse. But VkEvents are expected to be
very light weighted objects, so that should be acceptable.
This is the second CL in the series. In this CL, we added
RefCountedEventsGarbageRecycler to the ShareGroupVk which is responsible
to garbage collect and recycle RefCountedEvent. Since most of
ImageHelper code have only access to Context argument, for convenience
we also stored the RefCountedEventsGarbageRecycler pointer in the
vk::Context for easy access. vk::Context argument is also passed to
RefCounteEvent::init and release function so that it has access to the
recycler. The garbage collection happens when RefCountedEvent is needed.
The per renderer recycler is still kept to hold the RefCounteEvents that
gets released from ShareGroupVk or when it is released without access to
context information.
Bug: b/336844257
Change-Id: I36fe5d1c8dacdbe35bb2d380f94a32b9b72bbaa5
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5529951
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
2e0aefe9
|
2024-05-06T11:03:19
|
|
Vulkan: Move RefCountedEvent GC and recycler to ShareGroupVk (1/3)
One of the problem we had with RefCountedEvents is CPU overhead comes
with it, and some part of the CPU overhead is due to atomic reference
counting. The RefCountedEvents are only used by ImageHelper and
ImageHelpers are per share group, so they are already protected by front
end context share lock. The only reason we needs atomic here is due to
garbage cleanup, which runs in separate thread and will decrement the
refCount. The idea is to move that garbage list from RendererVk to
ShareGroupVk so that access of RefCountedEvents are all protected
already, thus we can remove the use of atomic. The down side with this
approach is that a share group will hold onto its event garbage and not
available for other context to reuse. But VkEvents are expected to be
very light weighted objects, so that should be acceptable (If not, we
can add some limit to the number of events it can hold in the garbage
list).
This is the first CL in the series. Before this CL, the RefCounteEvents
are garbage collected at flushToPrimrary time, at which time we have
lost ContextVk information. In order for us to do garbage collect to
ShareGroupVk, we need to move the garbage collection process early,
before command buffers leaving ContextVk's visibility. For
OutsideRenderPassCommands, this is easy to do, we just call
flushSetEvents before we call mRenderer->flushRenderPassCommands. For
RenderPassCommands, that flushSetEvents call will simply make another
copy of RefCountedEvents and add to the garbage list and the actual
VkCmdSetEvents are defered at the executeSetEvents call that get called
from flushToPrimrary time.
Bug: b/336844257
Change-Id: I1948cd8240ff61d407931083b7584a54b1dc6b0d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5517891
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
5332ab8c
|
2024-05-10T19:48:34
|
|
Vulkan: Add RefCountedEventRecycler to vk::Renderer
This CL adds event recycler in vk::Renderer to avoid the constant create
and destroy of VkEvents. When RefCountedEvent is destroyed previously,
it now goes into per renderer recycler. When RefCountedEvent is created
previously, it now dips into this recycler and fetch it. Before we issue
VkCmdSetEvent, if this event was from recycler, we also issue
VkCmdResetEvent before VkCmdSetEvebt. When glFinish/EGLSwapBuffer is
called or context gets destroyed, this recycler is purged to keep the
free count under limit.
Bug: b/336844257
Change-Id: I92ec1b183f708112a96c3d06fcfa265024f5aa04
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5519174
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
df2e7bd7
|
2024-05-10T19:48:34
|
|
Vulkan: Handle the case that VkEvent failed to create.
If VkEvent failed to create, we can still fall back to pipeline barrier.
This CL changes RefCountedEvent::init to return boolean. Also when it
fail, this CL did an immediate garbage clean up in case it will free up
more event from garbage list and then retry again.
Bug: b/336844257
Change-Id: I28251849a92d1785701c55eb028a8fed63cfc372
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5532869
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
36cd4c1f
|
2024-05-08T12:27:22
|
|
Adding basic readPixels.
This change adds to methods in ImageHelper to read texture data.
It also implements FramebufferWgpu::readPixels to get the parameters
and read the texture data from an ImageHelper that's stored in
mRenderTargetCache.
Bug: angleproject:8653
Change-Id: I349ed8a0ae3d8d0e187c658f3402c4f8cac23eb8
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5441353
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Liza Burakova <liza@chromium.org>
Reviewed-by: Matthew Denton <mpdenton@chromium.org>
|
|
|
3d04180c
|
2024-05-02T17:30:02
|
|
Vulkan: Add a dedicated garbage list for RefCountedEvents
Previously each individual RefCountedEvent is wrapped into a
GarbageObject. That is the reason behind RefCountedEvent being a
subclass from WrappedObject, since vk::GetGarbage call requires garbage
object is a subclass of WrappedObject. This CL adds a new garbage list
dedicated for RefCountedEvents, named mRefCountedEventGarbageList. With
this new change, we no longer limited by the vk::GetGarbage requirements
since it no longer called for RefCountedEvents. RefCountedEventCollector
is a vector of RefCountedEvents and every time a RefCountedEvent needs
to be released, it adds into the collector. Then the event collector
entire thing is treated like a garbage object and gets ResourceUse
tracked and added into mRefCountedEventGarbageList. This list gets
walked and cleaned when GPU is completed. This CL is also a preparation
for later CLs that adds event recycle support.
Bug: b/336844257
Change-Id: I4eff69b66922dfe5521b6994f240e967ff3726bd
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5516458
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
5b9e7f20
|
2024-05-06T14:50:44
|
|
Vulkan: Release mCurrentEvent before oneOff surface image copy
In ImageHelper::copySurfaceImageToBuffer and
ImageHelper::copyBufferToSurfaceImage, which get called from
lockSurface, we are doing a one off submission to do the data copy
between image and buffer. Surface image may have a current event set
earlier, but we do not have a garbage collector to collect it. This will
crash in barrierImpl when we try to add mCurrentEvent to the garbage
collector. This CL releases mCurrentEvent so that it will fall back to
pipelineBarrier. Since this is not on performance critical code path,
the impact should be acceptable as well.
Bug: b/336844257
Change-Id: Ib85c3038657a1845e86286cdb5f52247c2b9eb73
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5519173
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
c3a1cae4
|
2024-04-15T14:58:55
|
|
Use angle::SimpleMutex everywhere in libGLESv2
Only cases left that use std::mutex are:
- Share group and the context ErrorSet mutexes as they need try_lock()
- Anywhere mutexes are used in conjunction with std::condition_variables
(as they explicitly require std::mutex)
Bug: angleproject:8667
Change-Id: Ib6d68938b0886f9e7c43e023162557990ecfb300
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5453294
Reviewed-by: Roman Lavrov <romanl@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
28d4c3eb
|
2024-05-03T13:00:03
|
|
Vulkan: Remove BarrierType argument from ImageHelper::barrierImpl
Originally I passed the barrierType argument into barrierImpl function
to force pipelineBArrier in a few edge cases. Notably when we do a
oneoff submission. In that case if we have an event that is pending
setEvent call, and we will end up inserting a waitEvent call on an event
that has not yet set, which is bad. But this really won't not happen.
This CL removed BarrierType from the API and added a few assertions in
the caller to ensure we do not have a valid event when doing a oneoff
submission (if there is a pending setEvent, mCurrentEvent will be
valid).
Bug: b/336844257
Change-Id: I7161b844fc1f36993cf7ff6c90a070d9f92930cc
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5512878
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
5eb3bca0
|
2024-05-01T11:47:34
|
|
Vulkan: Minor cleanup
Bug: b/336844257
Change-Id: I8d93c6dd814a666debf9990d151cad79c45469f1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5503645
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
d30e4772
|
2024-02-02T14:13:33
|
|
Vulkan: Add VkCmdWaitEvents for image barriers
This CL add EventBarrierArray (sister class of PipelineBarrierArray)
that accumulates the event barriers instead of pipeline barriers.
ImageHelper::barrierImpl and ImageHelper::updateLayoutAndBarrier has
been updated to have a code path that inserts waiting event to
EventBarrierArray. PipelineBarrier code path is still kept and is also
used when event is invalid or under certain situation as a fallback
method from waitEvent. After we generate barrier (regardless it is
pipelineBarrier or eventBarrier, we always release
ImageHelper::mCurrentEvent. When next barrier/layout call is made, if we
see mCurrentEvent is invalid, we always fallback to pipelineBarrier.
This way it is safe that if somehow we did not (intentionally or
accidentally) insert a new event between two barrier calls, we will not
end up with second barrier call wait for old event which creates
synchronization hazard. With this approach, second barrier will use
pipelineBarrier which is still safe.
In this CL the useVkEventForImageBarrier feature flag is still disabled,
so no events are created and thus pipelineBarrier is still used.
Bug: b/336844257
Change-Id: Idaf5a7200b85f901eae5d376543f189d21522022
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5263701
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
a96e9197
|
2024-04-25T10:35:02
|
|
Vulkan: Add RefCountedEvent class and VkCmdSetEvent call
This CL defines RefCountedEvent class that adds reference counting to
VkEvent. CommandBufferHelper and ImageHelper each holds one reference
count to the event. Every time an event is added to the command buffer,
the corresponding RefCountedEvent will be added to the garbage list
which tracks the GPU completion using ResourceUse. That event garbage's
reference count will not decremented until GPU is finished, thus ensures
we never destroy a VkEvent until GPU is completed.
For images used by RenderPassCommands, As
RenderPassCommandBufferHelper::imageRead and imageWrite get called, an
event with that layout gets created and added to the image. That event
is saved in RenderPassCommandBufferHelper::mRefCountedEvents and that
VkCmdSetEvents calls are issued from
RenderPassCommandBufferHelper::flushToPrimary(). For renderPass
attachments, the events are created and added to image when attachment
image gets finalized.
For images used in OutsideRenderPassCommands, The events are inserted as
needed as we generates commands that uses image. We do not wait until
commands gets flushed to issue VkCmdSetEvent calls. A convenient
function trackImageWithEvent() is added to create and setEvent and add
event to image all in one call. You can add this call after the image
operation whenever we think it benefits, which gives us better control.
(Note: Even if forgot to insert the trackImageWithEvent call, it is
still okay since every time barrier is inserted, the event gets
released. Next time when we inserts barrier again we will fallback to
pipelineBarrier since there is no event associated with it. But that is
next CL's content).
This CL only adds the VkCmdSetEvent call when feature flag is enabled.
The feature flag is still disabled and no VkCmdWaitEvent is used in this
CL (will be added in later CL).
Bug: b/336844257
Change-Id: Iae5c4d2553a80f0f74cd6065d72a9c592c79f075
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5490203
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
caebfea1
|
2024-04-24T16:58:39
|
|
Vulkan: Make PipelineBarrierArray a class
Right now PipelineBarrierArray is just a
angle::PackedEnumMap<PipelineStage, PipelineBarrier>. To make iterate
over barrierArray faster we added mPipelineBarrierMask. They are not
encapsulated well. This CL makes PipelineBarrierArray a class which
internally tracks mPipelineBarrierMask bits. We also moved
pipelineBarrier related code into this class. This is a preparation for
the later CL that we will have a EventBarrierArray so that the
pipelineBarrier and eventBarrier are better separated.
Bug: b/336844257
Change-Id: I6002e3fdd584d5a63587f68f13a260b417b3db32
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5484711
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
298b8739
|
2024-04-15T13:58:01
|
|
Vulkan: Restrict the ContextVk dependency in CommandBufferHelper
Updating the interfaces that have no need for ContextVk state and
instead passing in the vk::Context.
Bug: angleproject:8544
Signed-off-by: Gowtham Tammana <g.tammana@samsung.com>
Change-Id: Id3b72d9eabb7d1d6ee89c46cdc24a23da9e32b5c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5492319
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
2905a6a6
|
2024-04-19T15:09:41
|
|
Vulkan: Fix read pixel to cached non-coherent memory
The bug here is that when we use cached non-coherent memory for image
read, we must wait until DMA to finish before calling invalidate().
Otherwise CPU pre-fetching might end up populate the cache line again
with old data between invalidate and DMA and causes CPU reads get the
stale data from cache. This CL moves invalidate() call after we wait for
copy to finish and removes requireCachedBitForStagingBuffer feature
flag.
Bug: b/335937565
Bug: b/315836169
Bug: b/324953979
Change-Id: Ie8a1854e17a5fe9c534c5102b2e0d51bd35c131a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5468597
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Cody Northrop <cnorthrop@google.com>
|
|
d4abe622
|
2024-04-03T17:46:38
|
|
CL/VK: Implement enqueue NDRangeKernel & Task
Adding support for:
clEnqueueNDRangeKernel
clEnqueueTask
Bug: angleproject:8631
Change-Id: If57002be3ea00a55215e89ca47ab8fe9a422c6e7
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5406614
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Austin Annestrand <a.annestrand@samsung.com>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
|
48132950
|
2024-04-17T17:05:07
|
|
Vulkan: Optimize DescriptorSetLayoutDesc layout
Separate out immutable samplers into its own array so we can remove
padding from PackedDescriptorSetBinding which reduces the size of that
struct from 16 bytes to 4 bytes.
Bug: angleproject:2462
Change-Id: I79d1ab584178202c9b7f34b0c7926edced4e21a8
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5464162
Commit-Queue: mohan maiya <m.maiya@samsung.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
80c8b6f0
|
2024-04-17T10:06:45
|
|
Revert "Vulkan: Only enable DS dynamic state if there is DS attachment."
This reverts commit 471b50407d7d1c22491d066df77060cb8b9b2f89.
The reverted change does not correctly handle UtilsVk functions, leading
to validation failures. UtilsVk could be made to not set dynamic state
when the depth/stencil attachments are missing, but instead the change
is reverted because:
- The original issue that prompted this is easily fixable (and fixed in
this change)
- Disabling depth/stencil dynamic state is not necessarily a performance
improvement; every time a pipeline in such a render pass is bound, the
driver would have to make sure to no-op the relevant state change if
static, which is also costly. Instead, dynamic state may need to be
set only once in the entire render pass.
Bug: b/223456677
Bug: b/315353258
Bug: angleproject:8242
Change-Id: I8282b87857d6b9285dbcf307c3c6ecf69df5fadb
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5462079
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
d9943e44
|
2024-04-09T23:53:48
|
|
Remove Program::syncState
The last bit of responsibility still left in Program::syncState was to
wait for post-link tasks for the sake of EGLBlobCacheTest tests. A new
extension, GL_ANGLE_program_binary_readiness_query is created so that
the wait can be done in the test itself.
This extension is ultimately useful for applications as well, so they
can avoid blocking the CPU by calling glGetProgramBinary prematurely.
Bug: angleproject:8297
Change-Id: Ied6b755cb9b060198f82c7948bfd03441435a578
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5440302
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: mohan maiya <m.maiya@samsung.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
d3aaf795
|
2024-04-05T15:57:38
|
|
Vulkan: Early out ImageHelper::updateLayoutAndBarrier when possible
If one image is attached to more than one attach points, when render
pass closes we end up calling ImageHelper::updateLayoutAndBarrier
multiple times. The first one is required since it does the layout
transition etc. But the second call is unnecessarily inserting memory
barriers. This is optimization itself, but will also fix the other
bigger problem when we start using VkEvent instead of PipelineBarrier:
we may end up waiting for an event that has not been set (since setEvent
gets called after we end render pass but waitEvent is before render
pass. Calling this sequence twice on the same image for the same render
pass means second waitEvent is called before setEvent).
Bug: b/333391804
Change-Id: Ic7b409c71806e63cb56c25e10b0bd0bfc9f6086d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5431033
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
13829f20
|
2024-03-26T23:03:12
|
|
Vulkan: Optimize depth/stencil resolve with glBlitFramebuffer
Like color resolve, depth/stencil resolve is now also possibly done by
modifying the render pass and attaching a depth/stencil resolve
attachment.
Bug: angleproject:7551
Change-Id: I045e3875e24006d2473a55b6c3856dd768fe8b84
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5398004
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
103c1b53
|
2024-03-29T14:37:23
|
|
Vulkan: Drop MSRTT emulation dependency on independentResolveNone
Usage of VK_RESOLVE_MODE_NONE was removed in [1], but dependency to this
property was accidentally added in [2].
[1]: https://chromium-review.googlesource.com/c/angle/angle/+/2743666
[2]: https://chromium-review.googlesource.com/c/angle/angle/+/3353895.
Bug: angleproject:4836
Change-Id: I25028b5d343686edd794acdac3714c4a6cb5fa17
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5407073
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
b559efa8
|
2024-03-26T22:02:41
|
|
Vulkan: Allow depth and stencil resolve to be separately added
In preparation for optimizing resolve through glBlitFramebuffer for
depth/stencil attachments.
Bug: angleproject:7551
Change-Id: I57650d82c0cc6e56f44591eadfc42ac794cfef09
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5399140
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
9475ac40
|
2023-11-15T10:25:06
|
|
Vulkan: Make efficient MSAA resolve possible
Prior to this change, using a resolve attachment to implement resolve
through glBlitFramebuffer was done by temporarily modifying the source
FramebufferVk's framebuffer description. This caused a good deal of
complexity; enough to require the render pass to be immediately closed
after this optimization.
The downsides to this are:
- Only one attachment can be efficiently resolved
- There is no chance for the MSAA attachment to be invalidated
In this change, resolve attachments that are added because of
glBlitFramebuffer are stored in the command buffer, with the
FramebufferVk completely oblivious to them. When the render pass is
closed, either the FramebufferVk's original framebuffer object is used
(if no resolve attachments are added) or a temporary one is created to
include those resolve attachments.
With the above method, the render pass is able to accumulate many
resolve attachments as well as have its MSAA attachments be invalidated
before it is flushed.
For a FramebufferVk that is resolved in this way, there used to be two
framebuffers created each time and thrown away as the code alternated
between starting a render pass without a resolve attachment and then
closing with one. With this change, there is now one framebuffer
(without resolve attachments) that is cached in FramebufferVk (and is
not recreated every time), and only the framebuffer with resolve
attachments is recreated every time.
Ultimatley, when VK_KHR_dynamic_rendering is implemented in ANGLE, there
would be no framebuffers to create and destroy, and this change paves
the way for that support too.
WindowSurfaceVk framebuffers are still imagefull. Making them imageless
adds unnecessary complication with no benefit.
-----------------
To achieve efficient MSAA rendering on tiling hardware, applications
should do the following:
```
glBindFramebuffer(GL_FRAMEBUFFER, msaaFBO);
// Clear the framebuffer to avoid a load
// Or invalidate, if not needed to load:
// glInvalidateFramebuffer(GL_DRAW_FRAMEBUFFER, ...);
glClear(...);
// Draw calls
// Resolve into the single sampled framebuffer
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, resolveFBO);
glBlitFramebuffer(...);
// Immediately discard the contents of the MSAA buffer, to avoid store
glInvalidateFramebuffer(GL_READ_FRAMEBUFFER, ...);
```
The above would translate to the following Vulkan render pass:
- MSAA LOAD_OP_CLEAR/DONT_CARE
- MSAA STORE_OP_DONT_CARE
- Resolve LOAD_OP_DONT_CARE
- Resolve STORE_OP_STORE
This makes sure the MSAA data doesn't leave the tile memory and greatly
reduces bandwidth usage.
Once anglebug.com/4892 is fixed, this would also allow the MSAA image
to never be allocated either.
Bug: angleproject:7551
Bug: angleproject:8625
Change-Id: Ia9f4d20863d76a013d8495033f95c7b39f77e062
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5388492
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
914fe61b
|
2024-03-15T13:20:49
|
|
Vulkan: Rename RendererVk.* to vk_renderer.*
Done in a separate CL from the move to namespace vk to avoid possible
rebase-time confusion with the file name change.
Bug: angleproject:8564
Change-Id: Ibab79029834b88514d4466a7a4c076b1352bc450
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5370107
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
d2cef82a
|
2024-03-18T18:15:11
|
|
Vulkan: Use fragment shading rate access flags
Image memory barrier for a fragment shading rate attachment needs to use
VK_ACCESS_FRAGMENT_SHADING_RATE_ATTACHMENT_READ_BIT_KHR as the access
flag instead of VK_ACCESS_SHADER_READ_BIT
Bug: angleproject:8484
Change-Id: I3316f1a5965ed3866e683494ee4f8df0b208d92c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5379262
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
60aaf4a0
|
2024-03-14T12:58:56
|
|
Vulkan: Move renderer to namespace vk
This class is agnostic of EGL. This change moves it to namespace vk for
use with the OpenCL implementation
Bug: angleproject:8564
Change-Id: I57f7807d6af8b3d5d7f8efbaf8b5d537a930f881
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5371324
Reviewed-by: Austin Annestrand <a.annestrand@samsung.com>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
d4d34781
|
2024-03-14T13:03:55
|
|
Multisampling support check: sampleCounts > 1 and createFlags
At least two drivers are returning VK_SUCCESS from
vkGetPhysicalDeviceImageFormatProperties2
but also set sampleCounts to 1 which supposedly means no MSRTT
Qualcomm reference device driver fails vkCreateImageView
when enabling the multisampling bit one cubemaps which have
sampleCounts == 1
Additionally,
* include vk::GetMinimalImageCreateFlags() in createFlags - we don't get
the cubemap bit without that
* check both the image format and the additional view format
(linear+srgb) as we set both of these when creating the image
This fixes a bunch of cubemap and 3D tests on Qualcomm reference device
Bug: b/329286011
Change-Id: I6d3ddea0cd997cf37b503050063f42d69723bd50
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5372826
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Roman Lavrov <romanl@google.com>
|
|
|
91ddf851
|
2024-03-03T10:57:22
|
|
Vulkan: support QCOM foveated rendering extensions
Add support for foveated rendering in the vulkan backend.
This is done by leveraging the VK_KHR_fragment_shading_rate extension.
Bug: angleproject:8484
Change-Id: I0d01d07583f710b2302ea07b19c9d113c73bfe41
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5269907
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
2ee295b4
|
2024-02-15T11:27:39
|
|
Vulkan: Add per-level image update tracker
* Add a per-level image write tracker to ImageHelper.
* It tracks the updates scheduled for different parts of the image.
Within each level, it also tracks different layers, currently up
to 64.
* kMaxParallelSubresourceUpload renamed to kMaxParallelLayerWrites;
moved to vk_helper header.
* It is reset when a barrier is issued for the image.
* Modified ImageHelper::recordWriteBarrier().
* Added isWriteBarrierNecessary().
* Now it checks the added writes for the image. It will no longer
issue a barrier if the image is in the same layout and there is
no write to a part of the image to which was previously written.
* Added ReadImageSubresources to CommandBufferAccess.
* It is used for layouts that allow both reading and writing to the
image (including self-copy):
* TransferSrcDst (used in CopyImageSubData)
* ComputeShaderWrite (used in compute-based mipmap generation)
* CommandBufferImageWrite -> CommandBufferImageSubresourceAccess
* Updated onImageSelfCopy() args to include read subresource data.
* Improves gpu_time for TextureUploadETC2TranscodingBenchmark perf test
* Windows/NVIDIA: ~180609 ns -> ~62669 ns (~2.88x)
* Linux/NVIDIA: ~157283 ns -> ~93360 ns (~1.68x)
* Windows/Intel: ~72297 ns -> ~57153 ns (~1.27x)
* Added a test to show that self-copy for a write-after-read works.
* ArraySelfCopyImageSubDataWithWriteAfterRead
* (ArraySelfCopyImageSubData covers RAW hazards; renamed)
Bug: b/308455694
Change-Id: I5cef296d991ce6ec02792edc3ffc5cc4994831e1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5301855
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
3c517e45
|
2024-02-14T14:26:42
|
|
Vulkan: Process ClearEmulatedChannels update first
* When going through the level updates in flushStagedUpdates(), the
ClearEmulatedChannels updates are expected to be before the rest. In
addition, there can be only one such update in the level update list.
Therefore, now they are processed and applied before the rest of the
updates. By doing so, if this is the only update for the image, an
unnecessary layout transition can be avoided.
* Added flushStagedClearEmulatedChannelsUpdates().
* Added flushStagedUpdatesImpl() for the rest of the update types.
* Used clipLevelToUpdateListUpperLimit() to limit the flush loops to
the number of levels in subresource update list.
* Added unit test to ensure updates after ClearEmulatedChannels are not
ignored.
* ImageTestES3.IncompleteRGBXAHBImportThenUploadThenEnd
* The test contains a ClearEmulatedChannels followed by an image
update. If the latter is ignored in this test, there is a failure
during teardown due to orphanNonEmptyBufferBlock when destroying
the buffer that contains the update.
Bug: b/308455694
Change-Id: I53c73acb60a9c5440548886cde913112a664402d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5297317
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
38cc4cf0
|
2024-02-14T16:36:08
|
|
Vulkan: Update flushStagedUpdate to use switchcase
* The if-else statements to check update type have been replaced with
switch-case statements for more clarity.
Bug: b/308455694
Change-Id: I3d5b77e697d342e77596fd177b2527ece4d228ed
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5297547
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
bcf814fd
|
2024-02-02T10:30:34
|
|
Vulkan: Constrain the dependency on ContextVk in BufferHelper
Make the BufferHelper interface be not dependent on ContextVk state.
This makes the interface to be suitable for implementation of other APIs
with Vulkan backend. Any dependency on ContextVk is made explicit and
handled in ContextVk.
Bug: angleproject:8544
Change-Id: I8b285f54c8758a26dd7edf27b1371f9afcf7e241
Signed-off-by: Gowtham Tammana <g.tammana@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5303573
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
|
dbc6bd9d
|
2024-02-12T14:07:49
|
|
Reland "Vulkan: Fix alignment issues with SecondaryCommandBuffer"
This is a reland of commit e53270c9ca1afe393d6d7d0359e81cf6755b6ca5
Original change's description:
> Vulkan: Fix alignment issues with SecondaryCommandBuffer
>
> This solves undefined behaviour on 64-bit systems. This inflates the
> size of a few commands, but most commands either already did align to 8
> bytes or could be aligned to 8 bytes with a few tweaks.
>
> Bug: angleproject:7852
> Change-Id: Ie61976d5bf8df7790acd95c0e15d4c79402622a1
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5288636
> Reviewed-by: Charlie Lao <cclao@google.com>
> Reviewed-by: Yuxin Hu <yuxinhu@google.com>
> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Bug: angleproject:7852
Change-Id: Ie206e66fc21c5db7c9e67eb478d9cddada5db8e0
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5296376
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
|
|
|
243f8ad9
|
2024-02-14T11:44:58
|
|
Revert "Vulkan: Fix alignment issues with SecondaryCommandBuffer"
This reverts commit e53270c9ca1afe393d6d7d0359e81cf6755b6ca5.
Reason for revert: breaks x86 Android build:
https://chromium-review.googlesource.com/c/chromium/src/+/5293321
https://ci.chromium.org/ui/p/chromium/builders/try/android-x86-rel/144329/overview
Original change's description:
> Vulkan: Fix alignment issues with SecondaryCommandBuffer
>
> This solves undefined behaviour on 64-bit systems. This inflates the
> size of a few commands, but most commands either already did align to 8
> bytes or could be aligned to 8 bytes with a few tweaks.
>
> Bug: angleproject:7852
> Change-Id: Ie61976d5bf8df7790acd95c0e15d4c79402622a1
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5288636
> Reviewed-by: Charlie Lao <cclao@google.com>
> Reviewed-by: Yuxin Hu <yuxinhu@google.com>
> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Bug: angleproject:7852
Change-Id: Id9c7a94ccc12816bc9e8c3803bd940550d9f7953
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5295854
Auto-Submit: Yuly Novikov <ynovikov@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
|
|
|
e53270c9
|
2024-02-12T14:07:49
|
|
Vulkan: Fix alignment issues with SecondaryCommandBuffer
This solves undefined behaviour on 64-bit systems. This inflates the
size of a few commands, but most commands either already did align to 8
bytes or could be aligned to 8 bytes with a few tweaks.
Bug: angleproject:7852
Change-Id: Ie61976d5bf8df7790acd95c0e15d4c79402622a1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5288636
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
c603a4f1
|
2024-02-08T10:53:27
|
|
Don't perf warn about ETC1->ETC2 emulation as it is efficient
Format is forwards compatible:
https://crsrc.org/c/third_party/angle/src/libANGLE/renderer/gl/formatutilsgl.cpp;drc=21f16cb16333802dfa942d67cac59885f904301d;l=701
Added hasInefficientlyEmulatedImageFormat() helper
Bug: b/302115557
Change-Id: Ibc82c27ecf4e3afbfaac52cb45bdda776c50b4b3
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5278562
Commit-Queue: Roman Lavrov <romanl@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
5a061558
|
2024-01-31T13:05:59
|
|
Vulkan: Update dynamic buffer size policy
When allocating a dynamic buffer, it is checked if the new data can
fit in an existing allocation. However, if the size of the new data
exceeds that of the current buffer, a new one is allocated. To avoid
using too much memory, if the data size is less than a threshold (a
fraction of the current buffer size, a smaller size will be used for
the new buffer.
However, with a specific pattern for the new sizes, combined with the
threshold value, there could be many allocations and deallocations,
which can affect the performance.
In this CL, the policy to update the dynamic buffer size is updated to
avoid this issue.
* Instead of using a smaller buffer when the required size is less than
1/4 of the current buffer size, it is done when the average required
size is less than 1/8 of the current size.
* Added a decaying average required size for the DynamicBuffer object.
* mSizeInRecentHistory
* For each new buffer allocation, the new required size is used with
the average size to calculate the new average.
* For each calculation, kDecayCoeffPercent is used as the weight for
the existing average, and the rest is the new required size, plus
rounding.
* kDecayCoeffPercent is currently set to 20%.
* sizeIgnoringHistory renamed to minRequiredBlockSize for more clarity.
Bug: b/322216767
Change-Id: Idcabbbe50f656910fe2103925e4d6d8602ca3425
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5254218
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
f5f3304a
|
2024-02-02T16:27:38
|
|
Vulkan: Simplify handling of YUV filtering support
When the requested filtering mode changes, we need to consider whether
it is actually supported by the Vulkan driver. Now that we support
renderable YUV textures, there are now three interesting cases:
1) The texture has a VkFormat, and so filtering support can be queried
from GPDFP, as was already done.
2) The texture is imported from an opaque AHB using an external format,
that format is renderable, and so we have assigned one of the
EXTERNALn angle formats. This was *not* covered properly, and would
lead to VVL errors or UB.
3) The texture is imported from an opaque AHB using an external format,
and we have not assigned an EXTERNALn angle format to it, because the
format is not renderable, or the Vulkan driver is missing the
external format resolve functionality; In this case the angle format
is NONE.
This was similarly *not* covered properly, although the code did
attempt to protect itself from querying the capabilities of format
NONE. VVL errors and UB were still possible.
To most simply cover all of these cases, capture whether the image has
the VK_FORMAT_FEATURE_SAMPLED_IMAGE_YCBCR_CONVERSION_LINEAR_FILTER
feature upfront, and forget about format lookups in the internals of the
YcbcrConversionDesc.
Bug: b/315387961
Change-Id: Ie140293d52c2b88bf06ef19bc54bb1c95927b8ce
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5259719
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Cody Northrop <cnorthrop@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
5c2fc02b
|
2024-01-29T16:49:28
|
|
Vulkan: Bugfix in ImageFormat
FixedVector::operator[] does not update FixedVector::mSize.
Need to call FixedVector::push_back(...) instead.
Bug: angleproject:7553
Change-Id: I544a68276d1635957a27d21c222f50f71d35a609
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5246088
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
6367f541
|
2024-01-25T10:16:04
|
|
Vulkan: supply YcbcrConversionDesc earlier
Previously, the AHB import path would allow ImageHelper to build a bogus
YcbcrConversionDesc (in initExternal) and then later overwrite it with
what it wanted. The intermediate state was not necessarily valid, and
could cause assertion failures and VVL errors.
Instead, have ImageHelper clients provide the conversion they want
upfront. In the non-external case, build an appropriate conversion
for formats which need them, before delegating to initExternal.
Bug: b/315387961
Change-Id: Icc8f561bb2de0289ceec56d41978b8c4651a47a2
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5232769
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Chris Forbes <chrisforbes@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
fad2adb2
|
2024-01-12T14:43:33
|
|
Vulkan: Fix importing external object and using as storage image
The create flags used to create the imported object was 0. Later, when
the texture was used as a storage image, TextureVk::syncState would
recreate the image (losing connection to external object).
This change makes sure the create flags include all the necessary create
flags such that the texture can be correctly used as storage image.
Bug: angleproject:8464
Change-Id: I6587b53b1c2819a11dec8f2d5a3a30c889a4c63f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5194064
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
ed2a8ef8
|
2023-12-20T00:06:10
|
|
Vulkan: Defer QFOT when acquiring texture with GL_NONE layout
Instead of issuing a queue family ownership transfer with the UNDEFINED
layout (and then hack its dst layout to be GENERAL), this change simply
lets the queue family be changed when the image is next accessed (at
which point a layout transition is necessary anyway).
Bug: angleproject:8464
Change-Id: Iab36af0c641bd04029bdc0d9097e766e8a0f4145
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5138657
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
4b356c39
|
2023-08-17T10:49:19
|
|
Vulkan: Drop support for VMA 2.0
Since ANGLE and Chromium were last updated to use VMA 3.0, there have
been no breaking issues so far.
* ANGLE update: https://crrev.com/c/4777337
* Chromium update: https://crrev.com/c/4911597
Therefore, the support for the old VMA (2.3) can now be removed.
* Removed ANGLE_VMA_VERSION from the build files, since they are
no longer required.
* Removed the VMA-related guards in the code as well.
* Removed the flags and thresholds for the buddy algorithm, which were
used in VMA 2.3.
* Share group buffer pools is no longer a map.
Bug: b/303290680
Change-Id: Ic2b29e8f95ca5c941b297b20442c5bad4b8f52e3
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4791667
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
0aaa8de9
|
2023-12-19T23:23:40
|
|
Vulkan: Fix memory tracking vs external texture acquire
... with a layout of GL_NONE.
Bug: angleproject:8464
Change-Id: I94690c5693c5bcb6d510e4a27097206f0da58a41
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5138656
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
40f4de8f
|
2023-12-15T10:17:32
|
|
Vulkan: Ensure we use cached memory for readPixels stagingBuffer
Previous CL crrev.com/c/5112759 does not solve the performance issue for
ChromeOS. The reason is that on more recent intel GPU, there is no
hostVisibleCachedCoherent heap. When we allocate staging buffer, we
specify CachedCoherent as the preferredFlags instead of requiredFlags.
This means we still end up getting UncachedCoherent since VMA tries to
respect coherent bits as first priority. This CL Changes CachedCoherent
to CachedPreferCoherent, and made Cached as required bit, thus ensures
the memory allocated is cached. Since coherent bit may not be honored,
thus we have to call invalidate/flush (which underline implementation
will check the bit and early out if no need).
Somehow on ARM GPU using cachedNonCoherent staging buffer causing many
test failures, even though we do call invalidate() after allocation, and
tests pass on all other GPUs. It almost indicates ARM driver have a bug
with invalidate() that it is not doing expected. But before I can be
sure and fixed, I added feature bit to keep ARM the old behavior, which
uses UnCached memory for readPixels which should suffer the performance
as well.
Bug: b/315836169
Bug: b/310701311
Change-Id: I1eec6105ce74275faa893b0206be8470f0cde72f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5122318
Commit-Queue: Charlie Lao <cclao@google.com>
Auto-Submit: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
de591cff
|
2023-12-11T13:15:30
|
|
Vulkan: Add CachedCoherent staging buffer
Right now if we allocate a coherent staging buffer, it always uncached.
I believe the reason it picked uncached is that most usage for staging
buffer is data flow from CPU to GPU. CPU only sequentially write into
staging buffer. Uncached may has better performance here due to write
combined. But this performs horrible if CPU ever read from it. This CL
adds a CachedCoherent staging buffer and let staging buffer use that for
coherent memory. UncachedCoherent is currently not used, but I still
kept here in case we find regression for certain type of usage.
Bug: b/315836169
Change-Id: Ica331914c1f4729baa9d2eab048dc3099a2887b5
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5112759
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
d0eb968d
|
2023-12-08T16:11:46
|
|
Vulkan: Fix the AHB leak for AHB backed buffer object
For client buffer backed OpenGL buffer object, we call
InitAndroidExternalMemory which calls AHB acquire. But when buffer
object is released/destroyed, we never call
ReleaseAndroidExternalMemory, which end up leaking AHB.
Bug: b/314791770
Change-Id: I693c74213e73008497a6dfeca93ea62e84c71352
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5106599
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Auto-Submit: Charlie Lao <cclao@google.com>
|
|
|
e9d5f13e
|
2023-12-04T22:36:41
|
|
Vulkan: More trace points in the readpixels path
Occassionally we hit a bad path in this case, this change makes it
clearer from the traces which bad path is hit.
Bug: b/310701311
Change-Id: Ic674d6396b0e88f1a1db3ded7efe195fb7397135
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5087207
Reviewed-by: Charlie Lao <cclao@google.com>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
99b077b7
|
2023-11-26T08:24:18
|
|
Vulkan: fix data clobbering with AllocateNonZeroMemory
The offset of the suballocation was not being used when initializing
memory, so it was possible to overwrite the start of an existing buffer
with garbage.
Bug: angleproject:8427
Change-Id: I8205068a173dc4342894c6c49ee5fa9c4a8a255a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5060776
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Auto-Submit: Steven Noonan <steven@uplinklabs.net>
|
|
|
8ae36a93
|
2023-11-14T10:11:51
|
|
Vulkan: Bugfix in isFastUnpackPossible
Disallow fast unpack when there is a mismatch between the
actual texture format and intended buffer (PBO or client buffer)
format.
Bug: angleproject:3777
Test: Texture2DTestES3.UnpackCompatibleFormatButDifferentType*
Change-Id: I9ea9d9cdd5e1391acebb3d75d69437e27cfa90df
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5029504
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
|
|
|
3a6b385f
|
2023-11-09T15:48:48
|
|
Vulkan: Fix depth/stencil texture copy
Bug: angleproject:7289
Change-Id: Icde8a26e855e95a6c0a1e506d2435e981adc6f28
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5018798
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
d896fab8
|
2023-11-09T15:03:05
|
|
Vulkan: Fix texture self-copy
A new layout is introduced to support self-copy.
Bug: angleproject:7289
Change-Id: Ib914c433d55b9a79cfeb7a91f8a2b8680824d473
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5018797
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
9a5d75de
|
2023-10-30T11:59:19
|
|
Vulkan: Fix incompatible redefinition of cube faces
The TextureVk::mRedefinedLevels bitmask tracked which levels are
incompatibly redefined, greatly reducing the complexity of dealing with
GL's mutable textures.
It did not however take into account the fact that GL allows each
cubemap face to be separately redefined (unlike 2D arrays, where all
layers are defined together). This change turns the bitmask into an
array of bitmasks. Previously, a single bit represented whether the
level is incompatibly redefined. Now, elements of the array track the
same information for each cube face. For non-cube-map textures, only
element 0 is used.
Bug: chromium:1494664
Change-Id: I69568d3da2391796bf5f01505861fee42c6c8924
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4986289
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
5dd0c842
|
2023-10-24T13:48:29
|
|
Vulkan: improve memory type mismatch issue.
for dynamic buffer usage, the memoryTypeIndex
returned from findMemoryTypeIndexForBufferInfo
not used. if we add more flags like
VK_MEMORY_PROPERTY_HOST_CACHED_BIT at alloction.
the actual memory type allocated may not have such flag.
Bug: b/306763053
Change-Id: I778e51fdd5ce0bc0810a965c45b5763a155fc391
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4973574
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Hailin Zhang <hailinzhang@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
4f611a1f
|
2023-10-24T20:56:19
|
|
Vulkan: Remove RendererVk::collectAllocationGarbage
Instead of adding separate method overload `DestroyGarbage()` method.
This will avoid checking `mUse` and creating garbage list twice.
Bug: b/218891184
Change-Id: If56ffe72a639021b1fd37feb02ebb91f62ad0933
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4974318
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
ba65feb4
|
2023-10-18T17:33:38
|
|
Vulkan: Limit mutable texture flush to one update
In case there are many updates for a mutable texture, flushing
it preemptively can reduce performance, especially if it is done
repeatedly.
* Added getLevelUpdateCount() to ImageHelper.
* Previous mutable textures will now be flushed only if they have
exactly one update per mip level/cubemap face (if defined).
* This means that mutable textures with no data will also not be
flushed.
* Added unit tests for single-level texture flushing and situations
with no updates or more than one update.
Bug: b/285613719
Change-Id: I1592ecf502051a55ebfbb7fcd22577c9ce87bf43
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4953847
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
d2de7451
|
2023-10-19T14:10:44
|
|
Vulkan: Fix VK_android_external_format_resolve VVL error part 5
Fix assertion in RendererVk::getFormatFeatureBits(). When formatID is
external format, we can not use vkGetPhysicalDeviceFormatProperties to
get the formatFeature (since VkFormat is undefined). To fix this, we
keep the formatFetaure that returned from AHB in the
ExternalYuvFormatInfo and use that in getFormatFeatureBits() if it is
external format.
This also fixes the VVL error VUID-VkImageCreateInfo-pNext-02396: The
Vulkan spec states: If the pNext chain includes a
VkExternalFormatANDROID structure whose externalFormat member is not 0,
flags must not include VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT
Bug: b/223456677
Change-Id: I625c2bf4fe534fa206918b16772ac3ac7c6fa79a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4956117
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|