|
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>
|
|
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>
|
|
3ca8befb
|
2024-02-14T12:35:08
|
|
Vulkan: Handle multi-context apps in pipeline cache graphs
Append a monotonically increasing counter to filename so apps and
benchmarks with multiple contexts don't clobber each others files.
Bug: angleproject:6565
Change-Id: I5c781895e1ec8cc65728aa752e28fb2acb02abe9
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5297288
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
|
|
|
6607a2b9
|
2024-01-17T15:58:20
|
|
Vulkan: Add support for VK_EXT_vertex_input_dynamic_state
Hook into VK_EXT_vertex_input_dynamic_state so pipeline states
that differ only in vertex input state can reuse existing
pipelines.
Bug: angleproject:7162
Tests: StateChangeTestES3.Vertex*
Change-Id: Icd3134dee93fc5fc2e9d284fcfa8c674b62faec8
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5207462
Commit-Queue: mohan maiya <m.maiya@samsung.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
b380ed1f
|
2024-02-14T09:31:26
|
|
Vulkan: Add EGL_ANGLE_global_fence_sync
Chrome has an implicit assumption that due to context virtualization,
signaling a fence in one context results in synchronization with _all_
contexts that have previously made submissions.
This is not per EGL spec, but the functionality is easily implementable
in the Vulkan backend. In the Vulkan backend, each context is given its
own "timeline" of submissions (tracked by serials associated with
"indices"). The required functionality is implemented through a new EGL
fence sync object whose sole difference is that it synchronizes with all
the existing timelines rather than the one of the current context.
Bug: b/318721705
Change-Id: I6c45d065e592d0d4ed627ce9695196b1086d5021
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5297396
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@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>
|
|
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>
|
|
|
d05c9a5e
|
2024-01-25T13:01:49
|
|
Frontend support for QCOM foveated extensions
Add frontend state management to support foveated rendering extensions.
Bug: angleproject:8484
Test: Texture2D*Foveation*
Change-Id: I0e1be9f11b2d442207674562da760f5bfd7debc8
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5208091
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
|
ecc35205
|
2024-01-25T23:58:25
|
|
Move uniform block dirty bits to State
When glUniformBlockBinding changes the mapping from a program uniform
block to a buffer binding, all contexts in the share group need to
reprocess the affected block index. Prior to this change, the dirty
bits that indicated which blocks have their mapping redefined were
placed in the program executable, and were reset by the first context
that processed them. As a result, the other contexts in the share group
where not aware of such modifications.
Similarly, when a buffer changed in one context, the mapped program
blocks were marked dirty, with similar cross-context issues.
In this change, the dirty bits are moved to State, so every context
would react to these changes.
Bug: angleproject:8493
Change-Id: I5712002224cbc4a576bf2ac46e8e75f26ebc5b2a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5238991
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
0c4d6446
|
2024-01-24T10:38:45
|
|
Rework uniform block <-> uniform buffer mapping
In GLES, the shader declares which buffer binding a block (uniform,
storage or atomic counter) is bound to. For example:
layout(binding = 1) uniform ubo0 { ... };
layout(binding = 2) uniform ubo1 { ... };
layout(binding = 1) uniform ubo2 { ... };
In the above, ubo0 and ubo2 use data from the buffer bound to index 2
(through glBindBufferRange), while ubo1 uses data from the buffer bound
to index 1. For uniform blocks in particular, omitting the binding
is allowed, in which case it is implicitly bound to buffer 0.
GLES allows uniform blocks (and only uniform blocks) to remap their
bindings through calls to glUniformBlockBinding. This means that the
mapping of uniform blocks in the program (ubo0, ubo1, ubo2) to the
buffer bindings is not constant. For storage blocks and atomic counter
buffers, this binding _is_ constant and is determined at link time.
At link time, the mapping of blocks to buffers is determined based on
values specified in the shaders. This info is stored was stored in
gl::InterfaceBlock::binding (for UBOs and SSBOs), and
gl::AtomicCounterBuffer::binding. For clarity, this change renames
these members to ...::inShaderBinding.
When glUniformBlockBinding is called, the mapping is updated. Prior to
this change, gl::InterfaceBlock::binding was directly updated, trumping
the mapping determined at link time. A bug here was that after a call
to glProgramBinary, GL expects the mappings to reset to their original
link-time values, but instead ANGLE restored the mappings to what was
configured at the time the binary was retrieved.
This change tracks the uniform block -> buffer binding mapping
separately from the link results so that the original values can be
restored during glProgramBinary. In the process, the support data
structures for tracking this mapping are moved to ProgramExecutable and
the algorithms are simplified. Program Pipeline Objects maintain this
mapping identically to Programs and no longer require a special and more
costly path when a buffer state changes.
This change prepares for but does not yet fix the more fundamental bug
that the dirty bits are tracked in the program executable instead of the
context state, which makes changes not propagate to all contexts
correctly.
Bug: angleproject:8493
Change-Id: Ib0999f49be24db06ebe9a4917d06b90af899611e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5235883
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
ac71a592
|
2024-01-23T11:56:42
|
|
Vulkan: updates to pipeline cache graph dumping logic
1. To dump pipeline cache graph you need to -
1. add "angle_dump_pipeline_cache_graph" compile time flag to
args.gn
2. set Android property "angle.dump_pipeline_cache_graph" or envvar
ANGLE_DUMP_PIPELINE_CACHE_GRAPH on non-Android platforms before
app start
2. Default path for dump on Android is "/data/local/tmp/angle_dumps/"
3. "angle.pipeline_cache_graph_dump_path" Android property or
envvar ANGLE_PIPELINE_CACHE_GRAPH_DUMP_PATH on non-Android
platforms can be used to configure the dump path
Bug: angleproject:6565
Change-Id: I38848aff58f413dd7bdffc9083116bd4b95e4960
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5226054
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
|
|
|
b007c74d
|
2024-01-23T14:17:54
|
|
GL: Separate dirty bits leading to glUniformBlockBinding
The GL backend is special in that it needs to make actual calls (native
glUniformBlockBinding) in response to (application)
glUniformBlockBinding calls. The other backends just remap the bindings
based on that information when creating descriptor sets.
Previously, an optimization to track which bindings have changed used
the same dirty bits that were used to signify when the GL backend needs
to make these native calls. That ended up as a source of bugs.
In a previous change [1], the context DIRTY_BIT_UNIFORM_BUFFER_BINDINGS
is set when these mappings change, which fixes some of these issues.
That change obviates the need for an actual backend sync of programs,
except for GL programs that need to make these native calls.
This change splits the dirty bits maintained for the purposes of the GL
backend, moves them to that backend and removes the program backend
sync.
[1]: https://chromium-review.googlesource.com/c/angle/angle/+/5228599
Bug: angleproject:8493
Bug: b/318806125
Change-Id: I73c6514e88a116f1cd701cb06da0d8c38f07f7f6
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5230137
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
e00995d4
|
2023-12-21T15:57:39
|
|
Vulkan: Invalidate pipeline with FBO draw buffer change
Enabling/disabling draw buffers can affect the graphics pipeline without
changing the render pass description. In that case, the graphics
pipeline was not being invalidated.
Bug: angleproject:8463
Change-Id: I6848472dcbb3d3ce4c34d95be28c8ec3fc50dcd7
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5147847
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: mohan maiya <m.maiya@samsung.com>
|
|
|
a1143857
|
2023-12-18T15:24:42
|
|
Fix UBO dirty bits vs PPOs
This change fixes propagation of UBO dirty bits (such as through
glUniformBlockBinding and glBindBufferRange) to program pipeline
objects. Since PPOs concatenate the attached programs' UBOs in a list,
a map of program UBO indices to PPO UBO indices is introduced to
offset these dirty bits appropriately. Additionally, when the program's
executable's buffer bindings change (through glUniformBlockBinding), a
notification is send to the PPO to update its executable's buffer
binding accordingly (which is otherwise only updated during PPO link).
Bug: angleproject:8462
Change-Id: I4965ae23e6fc6cac0842e1643755e42e95d3d5cc
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5131418
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Cody Northrop <cnorthrop@google.com>
|
|
|
4bf40237
|
2023-12-18T15:24:15
|
|
GL: Fix missing glUniformBlockBinding handling
When a program is current and this call is made, the program is made
dirty so that the GL backend reacts to this call. Prior to
https://chromium-review.googlesource.com/c/angle/angle/+/4922969, the
program was made dirty when its executable was installed as well (if it
had any UBOs dirty), but that change removed it. As a result, if this
call was made while the program was _not_ current, the GL backend would
miss processing it.
This call ensures that the appropriate dirty bit is set when the program
is made current again. This revealed a bug in the Vulkan backend where
sometimes the executable's dirty bits would not get reset. This was
benign but fired an assertion, and is fixed in this CL as well.
Bug: chromium:1511506
Change-Id: Iae86ba0aa5b8f9e4f20dd6df6002d37e405280e7
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5123005
Reviewed-by: Cody Northrop <cnorthrop@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
74f9da02
|
2023-12-04T19:53:25
|
|
Vulkan: Remove spam about depth/stencil feedback loop
It triggers a warning even if the application is appropriately using
BASE and MAX levels to avoid feedback loop.
Bug: b/289436017
Change-Id: Ie7e8281908802e91dfaad1b49dd95197ac6de1a1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5086070
Commit-Queue: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
3680a5dc
|
2023-11-17T13:51:07
|
|
Vulkan: Let program warmup continue passed link
The warmup task does not actually affect the link results, so there is
no reason to wait for it when the application queries the link status.
This change allows the warm up task to continue in parallel until the
program is used at draw time. This allows the warm up to be more
efficient when the link itself is not parallelized.
For applications that create programs in the middle of every frame, it's
still likely best to disable warm up (as the following immediate draw
will already effectively do the warm up).
Note that currently the warm up code in the Vulkan backend is not
completely thread-safe, and so the program still blocks on that task
before the first draw can happen (or the program is modified in any
way).
Bug: angleproject:8417
Change-Id: I0877fef39a0585c3279e32699ce817d4643d7cd6
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5037538
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
|
8b4901d0
|
2023-11-06T10:43:14
|
|
Avoid GLenum conversion in BlendStateExt blend and equation
The following functions now return value as is without ToGLenum
conversion (that is often unnecessary):
getEquationColorIndexed
getEquationAlphaIndexed
getSrcColorIndexed
getDstColorIndexed
getSrcAlphaIndexed
getDstAlphaIndexed
(at least) getEquationColorIndexed is on the hot path with noticeable
performance impact; this CL also moves the implementation to the
header to allow inlining.
Bug: b/300968773
Change-Id: Ie223abe14b12afd7844686863ee5806945d10e45
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5008031
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Roman Lavrov <romanl@google.com>
|
|
2ee06400
|
2023-10-31T10:57:02
|
|
Vulkan: fix dynamic buffer alignment issue.
Bug: b/306763053
Change-Id: I2f15fe2a2a36a9f55686987641e6afddb44ec9aa
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4994410
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Hailin Zhang <hailinzhang@google.com>
|
|
471b5040
|
2023-10-26T09:33:29
|
|
Vulkan: Only enable DS dynamic state if there is DS attachment.
This is discovered while investigating EXT_yuv_target crash in driver.
What happens is that UtilsVk::copyImage does not set depth stencil
dynamic state since there is no depth stencil attachment. But we enabled
dynamic state for D/S, thus driver still does D/S state setup, which
sees garbage data and hitting assertion. Even though this is discovered
with EXT_yuv_target test, I believe this is a general issue. This CL
adds the renderPassDesc.hasDepthAttachment() and hasStencilAttachment()
check and enable depth or stencil related dynamic state only if there is
depth or stencil attachment. This fixes crash in driver with
ImageTestES3.ClearYUVAHB test. This also has added performance benefit
that we now completely skips depth/stencil related dynamic state dirty
bit handling code, thus reduces state processing CPU overhead.
Bug: b/223456677
Change-Id: I3a4fe6d97b14c066d78f8b8ded21c626cb2f376c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4980765
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
58ffa778
|
2023-10-11T09:41:23
|
|
Vulkan: Implement YUV_TARGET use VK_ANDROID_external_format_resolve
This implements EXT_YUV_TARGET using VK_ANDROID_external_format_resolve
extension.
This CL is based on Chris Forbes's CL on android gerrit.
Bug: b/223456677
Change-Id: Ieb6970a0787b0c2a72a76b208695a678d2c79e80
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4857459
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
1ea49a22
|
2023-10-13T11:28:41
|
|
Move uniform dirty bits to ProgramExecutable
Rather than try to funnel them through Program and ProgramPipeline to
the executable in the backend, just move them to ProgramExecutable in
the front end.
This fixes Dota Underlords at the same time due to not needing to set
the Program dirty to propagate bits.
Test: Dota Underlords
Test: ProgramPipelineTest31.ProgramPipelineBindBufferRange
Bug: b/299532942
Change-Id: Ic73c45608e22f89ca400ebf684f8cd287ed2f43a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4922969
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Cody Northrop <cnorthrop@google.com>
|
|
|
2608c622
|
2023-10-06T13:32:49
|
|
Vulkan: Refactor SharedGarbageList into templated class
This CL mostly involves non-functional changes to prepare for next CL.
No behavior change is expected.
This CL wraps the garbage list into its own templated class which
maintains std::queue and tracks number bytes in the queue etc.
This CL also renames SharedBufferSuballocationGarbageList to
BufferSuballocationGarbageList to reduce verbosity a bit.
This CL deleted GarbageAndQueueSerial and GarbageQueue since they are no
longer being used.
This renames vk::GarbageList to vk::GarbageObjects to reduce name
confusion with SharedGarbageList.
Bug: b/302739073
Change-Id: I7370c147847ffe69ad8aa3b48251d8b5762f97f9
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4919816
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Hailin Zhang <hailinzhang@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
53e37a3e
|
2023-09-29T14:15:37
|
|
Replace mActiveTextures.fill(nullptr) with memset
std::array::fill yields unoptimized, unrolled loop with 8 byte
increments.
Surprisingly high (>2%) effect on the instructions counter in my tests
(first frame of real_racing3 trace)
The number of samples hitting this spot in profiling is also
signficantly reduced.
Impact on power harder to judge due to noise but does seem to be a bit
better.
Added a FillWithNullptr utility to check that nullptr is 0 and used it
in other places where fill(nullptr) was used in ContextVk. It's not used
elsewhere in vulkan.
Bug: b/302708437
Change-Id: If7fab66d858bc10ca356418d2ab26232bb9a9ce7
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4902288
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Roman Lavrov <romanl@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
34c8778b
|
2023-09-26T13:45:06
|
|
Use atomic counters early in perf warning macros
Before this CL, snprintf was called repeatedly to format the warning
message which was then discarded after 4 logs. snprintf showed up in
profiling at ~2% and this CL appears to yield an ~8% power
improvement in one of the traces (egypt_1500).
A mutex was previously used to avoid the race condition on the static
sRepeatCount variable. This CL avoids the need for that by using static
atomics instead.
Also updated the Debug macro to use the VK macro vararg approach so that
formatting only happens when the message is actually logged.
Bug: b/302112423
Change-Id: Ia8a18361cfb5a9f2aa19ff939499754ba861efb7
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4886388
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Roman Lavrov <romanl@google.com>
|
|
9fc3baf5
|
2023-07-26T10:29:13
|
|
Add the missing GraphicsPipelineDesc legacy dither bit update
When the app calls glEnable(GL_DITHER) or glDisable(GL_DITHER),
we need to update the legacy dither bit of the renderpass that
belongs to ContextVk::mGraphicsPipelineDesc. If not, there is a
change that the graphics pipeline will be created with a
renderpass that has outdated legacy dither bit. This results
the dither being applied to the render results incorrectly:
e.g. the app calls glDisable(GL_DITHER),
but the render results have dithering applied.
Bug: b/286921997
Bug: b/292282210
Bug: b/293349058
Bug: b/284462263
Change-Id: Ie24b95898526c9021be6e3cb7620e4050f9faaaf
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4722446
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Roman Lavrov <romanl@google.com>
Commit-Queue: Yuxin Hu <yuxinhu@google.com>
|
|
|
e1d2e88a
|
2023-09-20T11:53:15
|
|
Check pending garbage after some buffer releases
* Embedded BufferHelper::releaseBufferAndDescriptorSetCache() inside
a new ContextVk method: releaseBufferAllocation()
* After releasing the buffer, there is a check for excess pending
garbage. If the tracked pending garbage size is larger than the
threshold, the context will be flushed.
* Unskipped the test "BufferDataInLoopManyTimes", which was failing
on Android devices.
Bug: b/280304441
Change-Id: Ib34319f3291dd2200fc1a92e30645f9d1da8e2b9
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4879086
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
9ca025d2
|
2023-09-18T15:50:48
|
|
Flatten BufferVariable/ShaderVariableBuffer/InterfaceBlock struct
InterfaceBlock inherits from ShaderVariableBuffer, ShaderVariableBuffer
is not a trivially copyable struct, this made InterfaceBlock not
trivially copyable. InterfaceBlock is being used by some app traces for
uniform blocks. BufferVariable inherits from sh::ShaderVariable which is
very complicated and not trivially copyable. This CL flattens all of
these three structs to simple structs without inheritance, and wraps all
trivially copyable data into one POD struct, thus load/save are cheaper.
Bug: b/275102061
Change-Id: I96f89176ce3d3131cb1d3ea3280c3c36c257560f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4874610
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Roman Lavrov <romanl@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
53e3ce59
|
2023-09-08T17:41:56
|
|
Add device lost handle after finishImpl
It is possible that the during context destroy,
when calling finishImpl, the vulkan device is lost,
e.g.
https://github.com/KhronosGroup/Vulkan-ValidationLayers/issues/6447#issuecomment-1711479164.
We should check vulkan device lost after finishImpl().
Bug: b/289544394
Change-Id: I75aa650cdd38d81815f7354770639e896e3376a7
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4854763
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Yuxin Hu <yuxinhu@google.com>
|
|
|
91ef1f3c
|
2023-09-08T16:39:53
|
|
Move buffer suballocation callers to ContextVk
* Moved the following functions from BufferHelper to ContextVk.
* initBufferForBufferCopy()
* initBufferForImageCopy()
* initBufferForVertexConversion()
Bug: b/280304441
Change-Id: I890f4396b00b0c20feb44f0ad113c55924ce1014
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4854760
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
a1f52f1b
|
2023-09-07T14:44:24
|
|
Vulkan: Flush pending image garbage more often
* Added a counter to the context object to keep track of the size of
the pending image garbage: mEstimatedPendingImageGarbageSize.
* Modified hasExcessPendingGarbage() to use the sum of the size of
the image and and suballocation garbage.
* RendererVk::calculatePendingGarbageSizeLimit() provides the limit.
* Currently the limit is based on the available heap sizes. It will
use a fraction of the largest memory heap size.
* The portion is currently kGarbageSizeLimitCoefficient = 0.2f.
* Unskipped the test "TextureDataInLoopManyTimes", which was failing
on Android devices.
Bug: b/280304441
Change-Id: Ibcced1d118ea8a1f347028b62d29cfbd9e38e8c0
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4851252
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
27896999
|
2023-08-16T16:44:22
|
|
Vulkan: Flush pending suballoc garbage more often
* Added a counter to the renderer object to keep track of the pending
suballocation garbage.
* mPendingSuballocationGarbageSizeInBytes
* Once it surpasses a limit (mPendingSuballocationGarbageSizeLimit), it
will flush the context so the pending garbages can be freed.
* Currently the limit is based on the available heap sizes. It will
use a fraction of the largest memory heap size.
* The portion is currently kGarbageSizeLimitCoefficient = 0.2f.
* At the end of the render pass, it is checked if the limit has been
reached. If so, context flush will occur.
Bug: b/280304441
Change-Id: I08e6028cfe20059ece2b2e4e971ece897544cd6d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4787950
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
b4852ef9
|
2023-02-08T14:18:06
|
|
Vulkan: Drop support for Vulkan 1.0
Bug: angleproject:7959
Change-Id: Ib673679ea1a503af22b37092dbff1ee1fd34fba6
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4233092
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Ian Elliott <ianelliott@google.com>
|
|
|
e7418836
|
2023-08-16T14:25:52
|
|
Vulkan: Add context flushing as OOM fallback
* As a new fallback for out-of-memory errors, if an allocation results
in device OOM, the context is flushed and the allocation is retried.
* Functions related to buffer/image allocations now return a VkResult
value instead of angle::Result, which will be bubbled up to a higher
level for safer handling.
* The OOM is no longer handled at the level where the allocation
happens, but is moved up to the context.
* Added two functions to ContextVk for allocating memory for images and
buffer suballocations, which also include the fallback options.
* initBufferAllocation(): Uses BufferHelper::initSuballocation()
* initImageAllocation(): Uses ImageHelper::initMemory()
* Moved initNonZeroMemory() out of the following functions:
* BufferHelper::initSuballocation()
* Moved to ContextVk::initBufferAllocation().
* ImageHelper::initMemory()
* Moved to ContextVk::initImageAllocation().
* Also moved to new function:
ImageHelper::initMemoryAndNonZeroFillIfNeeded().
This function replaced the rest of initMemory() usages outside
initImageAllocation().
* New macros for memory allocation
* VK_RESULT_TRY()
* If the output of the command inside it is not VK_SUCCESS, it will
return with the error result from the command.
* VK_RESULT_CHECK()
* If the output of the command inside it is not VK_SUCCESS, it will
return with the input error.
* Added a test in which allocation would fail due to too much pending
garbage without the fix on some platforms. The test ends once there
has been a submission.
* New suite: UniformBufferMemoryTest
* Added a similar test for flushing texture-related pending garbage.
* New suite: Texture2DMemoryTestES3
Bug: b/280304441
Change-Id: I60248ce39eae80b5a8ffe4723d8a1c5641087f23
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4787949
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
48e2c605
|
2023-09-07T14:30:46
|
|
More instances of program usage converted to executable
Bug: angleproject:8297
Change-Id: I8e4eeef8f4f20610bbe0f994ce1141c17d588765
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4850888
Reviewed-by: Shahbaz Youssefi <syoussefi@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
|
6698fb69
|
2023-08-25T22:21:32
|
|
Vulkan: Stop passing both ProgramExecutable and ...Vk around
Now that ProgramExecutableVk is accessible through ProgramExecutable.
Bug: angleproject:8297
Change-Id: Ie08770ef97400195d63b87f2d4b7e2a2c8f4ad24
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4812147
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
bb135f0e
|
2023-08-24T15:29:11
|
|
Make ProgramExecutableImpl managed by ProgramExecutable
This change allows both parts of the program executable to be safely
backed up and swapped on link.
Bug: angleproject:8297
Change-Id: I17e4b6c05e4e481a66a227d6047dbf943d2c2603
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4812138
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
|
571b4cdb
|
2023-08-14T16:55:28
|
|
Vulkan: Move pipeline/desc-set layout creation to link job
The pipeline and desc-set layout caches are consequently made
thread-safe. The reference counter on the layouts are also made atomic.
With this change, practically all of the link in the Vulkan backend is
moved to the link job.
Bug: angleproject:8297
Change-Id: Iba694ece5fc5510d34cce2c34441ae08ca5bb646
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4774787
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
b8d5a423
|
2023-08-21T14:43:42
|
|
Add static_assert(std::is_trivially_copyable<LinkedUniform>(),"")
Since we are using memcpy for LinkedUniform, it is desirable to utilize
compile time assertion to ensure that in future if anyone modifies POD
struct (and the class of data members of POD struct) and made it that no
longer memcopy-able, we would immediately caught at compile time.
std::is_trivially_copyable<>is exactly for this reason. In order to make
this work, the POD struct and any data it uses can not have user defined
copy constructor. The problem is that right now ANGLE is using
clang_use_chrome_plugins=true, and chrome-style generates warnings if
the complex struct (has more than 10 data members) does not define a
copy constructor, and that warning causes build failure with -Werror. So
clang_use_chrome_plugins=true and std::is_trivially_copyable have this
conflicting requirements that I can not apply both. This has been raised
to compiler team, but before we get a solution from them, if we have to
make a choice, I think the better choice is to disable
clang_use_chrome_plugins and apply std::is_trivially_copyable, since the
later is more critical to ensure safety, while chrome-style is mostly
trying to minimize the code size, but won't affect
correctness/robustness. This CL sets clang_use_chrome_plugins to false,
and removes the copy constructor and copy assignment operator from
BitSetT and LinkedUniform and added static assertion
is_trivially_copyable for LinkedUniform. Same thing applied to
ProgramInput as well.
In future once we have a better solution from compile team, we can
re-enable clang_use_chrome_plugins and disable only for structs that
requires is_trivially_copyable assertion.
Bug: b/275102061
Change-Id: If33415ea61deda568d855a7dd6a4fd6042058be5
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4799342
Reviewed-by: Roman Lavrov <romanl@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
745023ef
|
2023-08-14T10:47:11
|
|
Vulkan: Ensure mComputeDirtyBits is set for potential submission.
When ContextVk::flushOutsideRenderPassCommands is called and we run out
of serial numbers reserved for outsideRPCommands (which means we have an
already started renderpass)., we will call flushCommandsAndEndRenderPass
so that we can have new queue serials for both renderPass and outsideRP
commands. When this happens, the current bug is that we will not add
mNewComputeCommandBufferDirtyBits to mComputeDirtyBits. If another
thread comes in did the submission, and then this context calls
dispatchCompute again without any state change, we will get a new
primprary command buffer without dirty bits for the new command buffer.
This CL ensures we always add mNewComputeCommandBufferDirtyBits
immediately after mRenderer->flushOutsideRPCommands call.
Bug: b/295533354
Change-Id: I1c672310b3b00cd9be25b5ee55a0a060239102a9
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4778445
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Hailin Zhang <hailinzhang@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
16cfa28e
|
2023-08-08T22:08:24
|
|
Vulkan: Basic infra for parallel link
This change moves pipeline warm up to a parallelizable task, mostly as
an exercise to put in the infrastructure for parallel link in the Vulkan
backend. Follow up changes will move more of the link step to this
task.
The end goal is to be able to make the link task independent of
ContextVk, which would allow it to be run as an UnlockedTailCall, even
if not using a worker thread.
Bug: angleproject:8297
Change-Id: I17047162b2a41f0d681d9e3ee33f2e0239b4280d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4764231
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
a990ba34
|
2023-08-02T17:21:00
|
|
Fix write out of bounds on non robust contexts crashes
dEQP-EGL.functional.robustness.reset_context.shaders.out_of_bounds_non_robust.reset_status.writes.*
tests are failing, because the test expectes EGL_SUCCESS
upon eglMakeCurrent(EGL_NO_CONTEXT), regardless of whether
the context was lost.
This CL:
1) Changes the validation function of eglMakeCurrent:
if the EGLContext passed to eglMakeCurrent
is EGL_NO_CONTEXT, do not return EGL_CONTEXT_LOST even if
the context is already lost.
2) Adds a lost context check in checkOneCommandBatch.
If the context is lost, do not check fence status and
assume all of the vulkan commands have finished execution,
so that we can properly destroying all
the resources before destroying the context.
3) Changes the GL error code from GL_INVALID_OPERATION
to GL_CONTEXT_LOST when there is a vulkan device lost.
Bug: b/286921997
Bug: b/289544394
Change-Id: I91e8a4105f0d7a3ec3b59bae58da80bc64ffa94a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4728466
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
938ee1e8
|
2023-07-21T16:16:23
|
|
Vulkan: legacy_dithering disallow reactivate when breaking RP
Hitting the assert in dEQP GLES2.functional.fragment_ops.random.0:
https://crsrc.org/c/third_party/angle/src/libANGLE/renderer/vulkan/ContextVk.cpp;drc=52fe3116ead9a5de51ddad17fcb14bf8ecb3a69d;l=2347
Bug: b/292259684
Change-Id: Ib40b90dde3b271c714b6181e4ba4d70f3e1b5e86
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4706174
Reviewed-by: Charlie Lao <cclao@google.com>
Auto-Submit: Roman Lavrov <romanl@google.com>
Commit-Queue: Roman Lavrov <romanl@google.com>
|
|
|
52fe3116
|
2023-07-17T16:20:54
|
|
Vulkan: Deduplicate share group's context set tracking
Bug: angleproject:8224
Change-Id: I7a59a37229682fb91ff777f31e02e05d7ab2b80f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4690345
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
9f9284b7
|
2023-07-17T15:41:27
|
|
Move ShareGroup to its own files
Bug: angleproject:8224
Change-Id: Id6d272018bb5ee8c3e35488f641efa4d99fa836d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4690003
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
c0f2f71e
|
2023-06-27T16:00:09
|
|
Use VK_EXT_legacy_dithering when available instead of emulation
Yields improvement in gpu power: http://b/284462263#comment45
Bug: b/284462263
Change-Id: I5bfd115557b6baac17c05639118feaebf19c5cd4
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4652590
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Roman Lavrov <romanl@google.com>
|
|
|
6ffd0d20
|
2023-07-12T12:09:45
|
|
Vulkan: Clean up depth stencil feedback mode part 2
Right now the tracking of depth stencil buffer readOnly or feedback loop
is in FramebufferVk class. This really belongs to ContextVk, since it is
not a permanent state of framebuffer, but current state of context. This
CL moves it to ContextVk and changes to use BitSet instead of four
boolean.
Bug: b/289436017
Change-Id: I955c439259935f82eff30ddfff776a69723e5d0d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4679886
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
a33ec5dd
|
2023-07-11T18:01:12
|
|
Vulkan: Clean up depthStencil feedback loop implementation Part1
This is first clean up effort for depth stencil feedback loop
implementation. This CL moves updateRenderPassStencilReadOnlyMode and
updateRenderPassDepthReadOnlyMode methods from FramebufferVk to
RenderPassCommandBufferHelper class. The method is actually updating
renderPass's state, not FramebufferVk's state. In the next CL,
FramebufferVk will be removed from the argument as well. With this
change, I also removes updateStartedRenderPassWithDepthMode() and
updateStartedRenderPassWithStencilMode() to use
updateStartedRenderPassWithDepthStencilMode() directly.
This CL is mechanical changes only, no behavior chnage is expected.
Bug: b/289436017
Change-Id: Id3960f973a7115c05ebea199cb8ef802e995941a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4679365
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
f5986fbb
|
2023-07-11T12:11:20
|
|
Vulkan: Dont break RP if there is actual render feedback loop
There is a bit terminology confusion here that will be fixed in next CL.
If a depth attachment is read only, then there is no feedback loop, we
should not call feedback loop for read only depth attachment. The real
depth render feedback loop mode is formed when we write to depth and
sample from depth at the same time. In this condition, the content is
undefined per OpenGLES spec section 9.3.1
(https://registry.khronos.org/OpenGL/specs/es/3.2/es_spec_3.2.pdf). The
shouldSwitchToReadOnlyDepthStencilFeedbackLoopMode() implementation
handles the usage case that the same render pass has depth write and
then switch to read only. Under this usage there is no actual feedback
loop, and we should still work properly by end current render pass and
start a new render pass with read only depth attachment. This
implementation also treating the actual feedback loop case exactly the
same way by ending render pass first, even though this is undefined
behavior. gangstar_vegas has the exact this undefined behavior usage
case, where it write and sample from depth buffer at the same draw call.
Native driver is not ending the render pass but ANGLE currently does.
This puts ANGLE into worse performance. Since this is undefined
behavior, either way is correct. This CL checks if there is an actual
feedback loop in the current render pass and if yes, we adopt the native
driver's behavior that keep the current render pass going. This improves
gangstar_vegas frame time from 4.365ms to 3.89ms, and interestingly,
yield the same golden image.
Bug: b/289436017
Change-Id: Ifc04ecd8ad6455a88e8615bd5452b9cce88c6687
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4679361
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
2a08c33b
|
2023-07-10T17:47:49
|
|
Vulkan: Avoid flushCommandsAndEndRenderPass for readonlyDS switch
When we switch to read only depth stencil mode, right now we always call
flushCommandsAndEndRenderPass, even though the started render pass is
empty and loadOp is load. This flush will cause render pass actually
submitted and color attachment being cleared and then color attachment
gets loaded in the subsequent render pass. In this CL, we only flush if
the depthStencil attachment has clear or written This CL save one
renderPass for the following app traces: antutu_refinery, aztec_ruins,
manhattan_10, manhattan_31.
Bug: b/290833623
Change-Id: I13b7a968d797b4c913f1cfbe9677d9b8abe791d2
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4674087
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
6ee402f6
|
2023-07-06T16:56:28
|
|
Clamp the max Framebuffer width and height to 16 bit
GraphicsDriverUniforms struct packs framebuffer
width and height into a 32 bit uint, meaning the
maximum width and height supported are 16 bit each.
We should make sure below values do not exceed the
maximum value of a 16-bit uint:
caps.maxFramebufferWidth
caps.maxFramebufferHeight
caps.maxRenderbufferSize
so that the application won't try to create a FBO
with width/height exceeding 16-bit.
We have clamped the caps.max2DTextureSize to
32768, it makes sense to clamp the FBO width and height
to the same value.
Bug: b/286921997
Change-Id: Iae598b37215c58d1a0f6a50bba9f391d4d23d1f2
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4671327
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
5f581f87
|
2023-06-27T20:38:03
|
|
Pass dirty bits by value
Split CL from follow up change where the dirty bits need to be passed
by value as they are calculated from two sets. Many cached dirty bits
are turned to constexpr as a result.
Bug: angleproject:8224
Change-Id: Ibdb3090d6ee93788e1502b72bce55f4677937c58
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4650074
Reviewed-by: Roman Lavrov <romanl@google.com>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
02292814
|
2023-06-01T14:46:05
|
|
Vulkan: Optimize the usage of FastMap in DescriptorSetDescBuilder
While looking at disassemble of
DescriptorSetDescBuilder::updateOneShaderBuffer() function, I noticed
that there are a lot of CPU cycles spent in FastMap::operator[]. What
happend here is that we are increasing size one by one as we build
descriptorSet, and that hit `if (mData.size() <= key)` case and we end
up resize the underline FastVector, and that resize also initialize the
element with zeros, which immediately overwrite by actual data. Since we
actually know the eventual size of
DescriptorSetDescBuilder::mDesc/mHandles/mDynamicOffsets, we could just
switch to angle::FastVector which will avoid this check size and grow
every time we write to it. This CL switches the use of FastMap in
DescriptorSetDescBuilder to FastVector. The only trick we need to watch
out is that previously the new elements are always zero filled and now
it does not. So we need to make sure we write every field of structure.
This CL also renames WriteDescriptorDescBuilder to WriteDescriptorDescs
since when it is read only we are passing it as const reference already,
there is no added advantage to have two classes.
Bug: b/282194402
Change-Id: I06a063cc51585fc17fbf0d5aa916b9aa0ab88dd4
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4581881
Reviewed-by: Roman Lavrov <romanl@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
2e209516
|
2023-06-26T11:58:50
|
|
Move state dirty bits definitions out of the class
This is in preparation for a follow up change that splits the state
class.
Bug: angleproject:8224
Change-Id: Ic9b253583e40fcc93ff37605b6b6e1deb55a6e55
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4631843
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
|
ec1f18db
|
2023-06-21T10:16:51
|
|
Vulkan: Remove ShaderVariableType and flatten info map
With the conversion of the interface variable info map keys to SPIR-V
ids, there is no longer a benefit to bucket resources by their type.
This change removes this bucketing and flattens the map.
Bug: angleproject:7220
Change-Id: If83cb02ca9e91f72dddb2deb7313fee40f9f06c3
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4632577
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
bbcf54bc
|
2023-06-16T16:02:08
|
|
Vulkan: Refactor uniform/block binding duplication code
Previously, resource binding assignment was done as such:
```
for each shader stage
assign bindings to textures
assign bindings to blocks
assign bindings to images
etc
```
To deduplicate bindings when the same resource was used in multiple
stages, a map was used, keyed by the resource's name, to detect when an
already visited resource is encountered in a future stage. This was
both inefficient and unnecessarily complicated.
With this change, resource binding assignment is done as such:
```
for each texture
assign one binding to all shader stages
for each block
assign one binding to all shader stages
for each image
assign one binding to all shader stages
etc
```
The aforementioned map is removed.
Because the resource bindings are now changed, the rest of the code
(which sets up the pipeline layout, updates descriptor sets, sets
dynamic buffer offsets, etc) are all updated to follow the above
pattern. As a result, nested loops are avoided and duplicate entries in
the variable map are never visited.
Bug: angleproject:7220
Change-Id: Iaff7b5f8b2bada8ac5078d21e5c790bf0d27aca7
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4622011
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
e21ecd1b
|
2023-05-26T14:06:46
|
|
Vulkan: Add dirty bit processing for uniform buffer change
When app calls glBufferData for the uniform buffer, we may end up
reallocate the storage. This will set DIRTY_BIT_UNIFORM_BUFFER_BINDINGS
on the context, but the exact uniform block index gets lost along the
way. This CL sets mDirtyBits on the program for the corresponding block
index and then changed vulkan backend to utilize the program's
mDirtyBits and only update the buffer if it is dirty, instead of always
update all uniform buffers even if only one of the buffer is dirty. In
order to make this work, this CL also adds the reverse tracking from
buffer binding to uniform blocks. Previously we already have the
tracking of which buffer binding index is used for which buffer block
index. This CL adds mUniformBlockBindingMasks which is an array of
BitSets. Each array element tracks all the uniform block index that is
using this buffer binding index (you can have the same buffer bound to
multiple uniform block index). Then when a buffer binding index is
dirty, that BitSet gets added into program's uniform block dirty bits.
This CL and previous CL improves GfxBench gl_driver2_off score 1.8%
(from average 6797 to average 6919) on pixel 7 pro.
Bug: b/282194402
Change-Id: Ic5002643a5297907276fc9b20ca7d21af9bdc4fe
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4553136
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Roman Lavrov <romanl@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
2501903e
|
2023-05-31T11:59:36
|
|
Vulkan: Merge UpdateShader***Buffers into updateShaderBuffers
Both UpdateShaderUniformBuffers() and
DescriptorSetDescBuilder::updateShaderBuffers() walks the list of
uniform blocks (or storage blocks). Some of the logic are the same and
we are paying that overhead twice. In this CL,
UpdateShaderStorageBuffers, UpdateShaderUniformBuffers and
UpdateShaderAtomicCounterBuffers functions are merged into
DescriptorSetDescBuilder::updateShaderBuffers and
DescriptorSetDescBuilder::updateAtomicCounters. In order to handle the
usage that same buffer used by multiple shader stages, a new variant of
bufferRead() function is added that takes "const gl::ShaderBitSet"
instead of single PipelineStage. This also paves way for next CL so
that we can call updateOneShaderBuffer individually.
Bug: b/282194402
Change-Id: I09d045d6295827b60bdb4c05df9333fe593fa40e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4574288
Reviewed-by: Roman Lavrov <romanl@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
b0e9bbd7
|
2023-05-31T14:23:40
|
|
Vulkan: Split features for dynamic state
When a driver bug with dynamic state is encountered, it is hard to debug
which dynamic state exactly is causing an issue, due to the current
granularity of disabling all entire state from an extension. With this
change, every dynamic state gets its own ANGLE feature, and can be
toggled as necessary.
Disabling the supportsExtendedDynamicState* features implicitly
disables all dependent features.
Bug: b/285124778
Bug: b/275210062
Bug: fuchsia:107106
Bug: angleproject:5906
Change-Id: Ic291279872df2d0eb58618ff364ab118bdcc4a9f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4577553
Reviewed-by: Cody Northrop <cnorthrop@google.com>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
ec7e0778
|
2023-05-26T22:11:49
|
|
Vulkan: Track the emulated texture buffer in command buffer
... instead of the original texture buffer, because the emulated one is
the one that is actually being used. This removes the necessity to
issue a hacky barrier after the emulation is done.
Bug: angleproject:8128
Change-Id: Ibc812894204cc1b2c6147817674de44e9c7ba2f4
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4571701
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Roman Lavrov <romanl@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
01f629e3
|
2023-05-26T10:23:20
|
|
Vulkan: Remove the loop when calling updateShaderBuffers
Right now there is a loop of getLinkedShaderStages when calling
mShaderBuffersDescriptorDesc.updateShaderBuffers. The shaderType
variable is only used to check if block is active or not, and get
info.binding. They can be retrieved without loop of shaderType. This CL
removes the loop so that we call
DescriptorSetDescBuilder::updateShaderBuffers only once. Similar thing
is applied to atomic counter buffer and images.
Bug: b/282194402
Change-Id: I03f3b4a391e773dfc162877802a2f940311866b8
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4554625
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
297687c6
|
2023-05-18T17:27:54
|
|
Vulkan: Reduce CPU overhead for uniform buffer change
One of the common usage pattern is change uniform buffers and draw.
Right now every uniform buffer change goes into ShaderResource dirty
code path that rebuilds entire ShaderResource cache key and descriptor
set etc. This CL keeps SHaderResource dirty code path, and will be used
when program changes or framebuffer changes. But uniform buffer change
will go down its own code path that only update uniform buffer related
state.
This CL along with prior two CLs reduced asphalt_9 average frame time
(with multi context hacked away) from 5.375 ms to 5.2594 ms (reduced
2.15%).
Bug: b/282194402
Change-Id: Ibae2895663918ddc10bf13bc559f1483f94d2e11
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4528314
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Roman Lavrov <romanl@google.com>
|
|
|
9445fbbe
|
2023-05-16T10:43:55
|
|
Vulkan: Move mWriteDescriptors out of DescriptorSetDescBuilder
DescriptorSetDescBuilder has two data structures: mWriteDescriptors,
which keeps track of "layout" of descriptorSet, and mDescriptorInfos,
which is the actual cache key for descriptorSet. mDescriptorInfos will
be updated every time buffer or image changes. But mWriteDescriptors is
immutable with buffer/image, it is static per program executable (with
exception of InputAttachment). Right now whenever there is a buffer or
image change, we call into DescriptorSetDescBuilder and update both
mWriteDescriptors and mDescriptorInfos. This CL moves mWriteDescriptors
out of DescriptorSetDescBuilder, and stores it in ProgramExecutableVk.
To deal with InputAttachment variation, ContextVk makes a copy of
mWriteDescriptors when program is bound, and then update inputAttachment
with framebuffer information. This not only removes unnecessary update
of mWriteDescriptors, but also removes the requirement that
mShaderBuffersDescriptorDesc has to reset and rebuild as a whole
(because mWriteDescriptors keeps mCurrentInfoIndex which gets
incremented as we build). This allows us to do further optimization in
future to do piece meal update of mDescriptorInfos with only the changed
data.
Bug: b/282194402
Change-Id: I443c7c3b85b7a2e2e93c68d40ea102533c43f76a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4540280
Reviewed-by: Roman Lavrov <romanl@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
2c836045
|
2023-05-18T12:00:41
|
|
Vulkan: Remove buffer/image tracking from DescriptorSetDescBuilder
Right now DescriptorSetDescBuilder keeps an array of images and buffers
as we build DescriptorSet cache key. Later on if we have a cache miss
and allocated a new cache entry, we walk the array and tag the images
and buffers with newSharedCacheKey. If we have a cache hit, the tracked
images/buffers are unused and then cleared. This means the effort of
keep track of these buffers are wasted when we have cache hit, which we
expect to be most likely. This was initially implemented this way simply
because of convenience, but there is really not a need to add another
tracker for them, as they are readily available from context state
anyway. This CL remove the tracking of images/buffers from
DescriptorSetDescBuilder and replaced with context API to tag images and
buffers with newSharedCacheKeywhen when we have a cache miss.
Bug: b/282194402
Change-Id: I355c2fbabdfc573ce71c0a4281788c942d260271
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4539290
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Roman Lavrov <romanl@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
934a25bc
|
2023-05-22T00:00:00
|
|
Vulkan: Implement EXT_depth_clamp
Bug: angleproject:8047
Change-Id: I73244f5dcd6eeeb1889214ee3a611e4ecabbfe7e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4558744
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
|
|
5ab2fa96
|
2023-05-12T08:38:19
|
|
Vulkan: Move texture QFOTs to syncState()
... (and getAttachmentRenderTarget() which is syncState()-like
for deferred clear) so that QFOTs are not actually scheduled until
first use. SurfaceFlinger optimistically creates EGL images and
textures for AHBs in case it does need them in the future.
However, the images and textures may go unused. Prior to this
change, ANGLE would create pending QFOT barriers while importing
AHBs into EGL images and GL textures. However, SurfaceFlinger may
not be doing any "real work" (other than repeatedly creating and
destroying EGL images and GL textures) which would result in the
command buffers containing the QFOTs being flushed. This can
result in a large build up of unreleased memory (as the
VkDeviceMemory would still be kept alive by the reference from
the unflushed QFOT command buffer) and lead to the low memory
killer nuking processes.
Bug: b/282075554
Test: cts -m CtsOpenGLTestCases
-t android.opengl.cts.GLSurfaceViewTest
Test: adb shell dumpsys SurfaceFlinger
Test: angle_end2end_tests
--gtest_filter=ImageTestES3.AHBImportReleaseStress/ES3_Vulkan
Change-Id: I7776abb2c6f834e96aa3926c26e77c53352ee561
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4527437
Commit-Queue: Jason Macnak <natsu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
086b6c20
|
2023-05-04T15:55:31
|
|
Vulkan: Simplify TransformFeedback buffer tracking
Right now the buffers that used by transform feedback is tracked by
mCurrentTransformFeedbackBuffers, which is angle::FlatUnorderedSet.
With the QueueSerial numbers, this can be much simplified. This CL
removes mCurrentTransformFeedbackBuffers. It adds a new QueueSerial
variable called mCurrentTransformFeedbackQueueSerial, and is inavlid if
no active transform feedback. Then check if a buffer is used by
transform feedback is as simple as check if it is written by
mCurrentTransformFeedbackQueueSerial. Since buffers are already tracked
by queue serial, so there is no new tracking needed. It is simply a
check if the buffer contains mCurrentTransformFeedbackQueueSerial or
not.
Bug: b/280889890
Change-Id: I54bdc4a0cfc7194a12d2aa0abdc67a3211949024
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4507978
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
903d9fdf
|
2023-01-19T15:37:45
|
|
Vulkan: Implement ExternalFence for use in SyncHelperNativeFence
`ExternalFence` allows concurrent usage in `CommandQueue` and
`SyncHelperNativeFence` classes eliminating need of additional
`vkQueueSubmit()` call.
Waiting in `CommandQueue` on `QueueSerial` or `ResourceUse` will ensure
corresponding state of the native FD (because `CommandQueue` will wait
on the same FD instead of some other fence).
After this change there will be only single `vkQueueSubmit()` call
from the `SyncHelperNativeFence::initializeWithFd()` method.
This CL and the follow-up is sufficient to fix the bugs below.
Bug: angleproject:8115
Bug: angleproject:8117
Test: angle_end2end_tests --gtest_filter=EGLSyncTest.AndroidNativeFence_ExternalFenceWaitVVLBug*
Change-Id: Ic562ecc71a95203454a1dc438589a13bcf3bff7f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4392879
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
72f9add4
|
2023-05-03T15:30:33
|
|
Vulkan: Initialize mLastSubmittedQueueSerial to valid value
Currently, ContextVk::mLastFlushedQueueSerial and
ContextVk::mLastSubmittedQueueSerial are invalid after Context
initialization. Although, invalid QueueSerial will always test as
submitted and finished, this produce a edge case. In case of
SyncHelper::mUse, we can not longer assert that mUse.valid() after
submitSyncIfDeferred() call, because invalid mUse is now a valid case...
This CL initializes both members to valid value, that will also always
test as submitted and finished. This removes the edge case, and allow
using assert in SyncHelper to check if everything works as expected.
Bug: b/277644512
Change-Id: I6be71596ab7dca1026764756fba7b21b81524413
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4503485
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
|
|
|
e24f4519
|
2023-01-19T02:30:39
|
|
Vulkan: Add externalFence into submitCommands()
Currently one-off fence in the `queueSubmitOneOff()` is used only in
`SyncHelperNativeFence::initializeWithFd()` to submit external fence.
Other `queueSubmitOneOff()` calls may use `QueueSerial` instead of a
fence.
Providing `fence` into `queueSubmitOneOff()` prevents tracking that
submission with `QueueSerial`. Therefore using `mUse` to collecting
`mFenceWithFd` as garbage will not work as intended.
This CL removes `fence` from `queueSubmitOneOff()` and adds
optional `externalFence` into `submitCommands()` instead.
Providing `externalFence` will cause additional `vkQueueSubmit()` call:
- first submission will submit everything as usual except using
the `externalFence`.
- second, will only submit internal `CommandQueue` fence for
`QueueSerial` tracking.
As the result of this CL, call to `initializeWithFd()` will always
produce two (2) `vkQueueSubmit()` calls. Previously it may be one (1) or
two (2) submissions. Future CL will reduce submission count to one (1).
If add additional submission into `queueSubmitOneOff()` instead of
`submitCommands()`, then maximum number of submissions will be
three (3).
Bug: angleproject:8117
Change-Id: I6f1ec12682aaab71bfc871e665fec2659df96b26
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4392877
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
|
|
|
b052a5bf
|
2023-03-31T00:00:00
|
|
Vulkan: Implement polygon mode extensions
* NV_polygon_mode
* ANGLE_polygon_mode
Bug: angleproject:1791
Bug: angleproject:8132
Change-Id: I2beffdad0c1569546020b78a9c6d9b8ea87c2100
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4498687
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
|
|
|
73f9cf00
|
2023-03-31T00:00:00
|
|
GL: Implement polygon mode extensions
* Implemented polygon mode extensions
on the OpenGL backend
* Supported capture and serialization
of the new commands and state
* Added PolygonModeTest end2end tests
Bug: angleproject:1791
Bug: angleproject:8132
Change-Id: I3bc08546a02f110dd739950129bee25ccc507bf6
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4492683
Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
90539b10
|
2023-04-24T16:36:01
|
|
Vulkan: Clean up some of trace events
CommandBuffer::begin/end/reset events are too fine grain. The trace
event retireFinishedCommandsLocked already covers reset.
Also made flushImpl generate event only if we did submit, if we end up
early out, that is not interesting.
Also add event for fenceWait, since that is quite important for
performance investigation, sometimes an indication of bad
synchronization.
Bug: b/277644512
Change-Id: I7d2f6d0716a83bf3b88a9e590ddc042b038b347a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4471747
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
b875f47b
|
2023-04-24T11:11:03
|
|
Vulkan: Make mLastSubmittedQueueSerial reflect what it means
Right now we always update ContextVk::mLastSubmittedQueueSerial and
ContextVk::mLastFlushedQueueSerial when context becomes current, even
though it does not make any submission. It was done it this way mainly
for simplification (i.e, you will always see both queueSerial's index
the same). But this also causes a performance cost when a
mLastSubmittedQueueSerial is used to tag a resource. For example, if you
insert a EGLSync right after makeCurrent, that EGLSync may get a queue
serial number bigger than it should be, which will translate to longer
sync wait time. This CL changes these two queue serial to exact what the
name suggests, that it will only update if we made a "flush" or "submit"
call.
Bug: b/277644512
Change-Id: Ibe4c78985a3fe0726836d620202e5276894a8e7c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4458532
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
ec04c40d
|
2023-04-24T23:12:09
|
|
Vulkan: Fix regression not calling mRenderer->notifyDeviceLost
Change:
Vulkan: Fix freeing not completed Secondary Command Buffers.
https://chromium-review.googlesource.com/c/angle/angle/+/4334579
.. accidentally removed `mRenderer->notifyDeviceLost();` line from
`ContextVk::handleDeviceLost()` method. This CL fixes that regression.
Bug: angleproject:6100
Change-Id: Iba3c9df71399821ac1b05109e873abfe5dc02bad
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4470307
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
e27759f9
|
2023-04-20T00:00:00
|
|
D3D11: Ignore sample mask and A2C for single-sampled rendering
Also fixed alpha-to-coverage for single-sampled
rendering and simplified sample coverage code
in the Vulkan backend.
Fixed: angleproject:8102
Change-Id: Ieea03dfdc13c6105ddf916dca6d0fea593eb3a62
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4455508
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
|
|
|
77d86c4a
|
2023-04-20T11:21:59
|
|
Vulkan: Set shading rate dynamic state unconditionally
Since this state is dynamic, it must be set before use.
Bug: angleproject:8108
Change-Id: I3ceeae95cdfad3388c35dd9e629e1424617f48b0
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4455148
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Yuxin Hu <yuxinhu@google.com>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
fa9172a3
|
2023-03-27T09:49:33
|
|
Reland "Vulkan: Use midRenderPass clear if RP has started but inactive"
This is a reland of commit 98151770adfd990c533991da27615b4879494307
Original change's description:
> Vulkan: Use midRenderPass clear if RP has started but inactive
>
> This CL extends prior CL's optimization so that if clear is issued right
> after blitFramebuffer call (this could make sense if blit and clear are
> on different buffer), we can keep the started render pass and do the
> midRenderPass clear instead of endRenderPass and start another
> renderPass.
>
> Bug: b/273808966
> Change-Id: Ia2504e8e260867a6f797d42cd4c8a72f187280ef
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4374145
> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Bug: b/273808966
Change-Id: I5c8c85c173f021a7753ef579f83d9ceb24147a7c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4442911
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
2f19bb74
|
2023-03-16T16:03:29
|
|
Reland "Vulkan: Reactivate already started render pass when possible"
This is a reland of commit ad9537af7f2bb5e22bc73f4e833fd3789adaa217
Original change's description:
> Vulkan: Reactivate already started render pass when possible
>
> In some usage case (such as lineage_mobile), we are seeing in the middle
> of render pass, app switch to another fbo just to issue a glClear()
> call, which the clear call itself gets deferred. Application then switch
> back to the original frame buffer. Before this CL, the render pass gets
> recreated due to frame buffer binding change, even though the clear gets
> deferred and new render pass and the previous render pass are
> essentially the same. This CL detects this situation and reactivate the
> current render pass instead of creating a new one. With this CL,
> lineage_m app trace reduces frame time from 3.86ms to 3.7ms, and only
> one render pass is used instead of two.
>
> This CL also allows the render pass started by BlitFramebuffer reused by
> subsequent draw calls. Asphalt_9 is hitting this use pattern and this CL
> reduces frame time by 0.1245 ms (from 5.6203 ms to 5.4958 on pixel 7
> pro)
>
> Bug: b/273808966
> Change-Id: I48c2671cbef3ff9d6cf59caae88c37c77828ee07
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4348713
> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
> Commit-Queue: Charlie Lao <cclao@google.com>
Bug: b/273808966
Change-Id: Ice9062122ae320b1a0108ff981bc65bd13b2ada0
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4406888
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
459f0fad
|
2023-04-06T13:42:49
|
|
Vulkan: Force submit when switch to system framebuffer draw
Given recent finding on unnecessary wait for acquire image semaphore,
since the semaphore wait is per submission, any GPU will have this same
performance problem if we only do command submit per frame. This CL
forces submission when we switch draw framebuffer to system default
framebuffer, so that the semaphore wait will not block user's fbo
rendering.
Bug: b/275624771
Change-Id: Id6b941870ef296393c13d0daaf81a41b6c042b9a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4406882
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
d58fbf04
|
2023-04-05T12:32:09
|
|
Vulkan: Wait for surface ANI semaphore only if image is used
Right now there is a bug that surface's ANI semaphore is added to
context when WindowSurfaceVk::getAttachmentRenderTarget get called,
which gets called from FramebufferVk::syncState, which is before we end
the previous render pass, due to the endRenderpass usually is deferred
until next renderPass starts. This caused ANI semaphore gets added to
the previous render pass's submission, which does not use surface, and
thus a bubble in GPU execution pipeline where the user FBO rendering
gets unnecessarily blocked until ANI semaphore is signaled. This lowers
GPU utilization and thus GPU frequency gets dropped and frame time
increased. This CL stores ANI semaphore to ImageHelper object and when
barrier is generated, the ANI semaphore is moved to CommandBuffer. When
CommandBuffer gets flushed and submitted, it gets added to the
waitSemaphores vector and submitted to vulkan. Since all use of swap
chain image must go through barrier code first (you need at least change
layout), this ensures ANI semaphore gets waited in exact and robust way.
Only the submission that references the swap chain image will be waited.
With this CL, professional_baseball_spirits reduces frame time from 3.8
ms to 2.7 ms, achieving parity with native GLES on pixel 7 pro.
Bug: b/275624771
Change-Id: Ifa6cacf9e3bc147bfde54eb7def2fca48c50aca0
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4400011
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
65ed3050
|
2023-04-04T11:57:38
|
|
Vulkan: Let recordWriteBarrier use CommandBufferHelper
This is preparation for next CL. It changes
OutsideRenderPassCommandBuffer argument to
OutsideRenderPassCommandBufferHelper for recordWriteBarrier() and
recordReadBarrier() calls, so that it has access to the helper object
(will be used in next CL). It passes CommandsState to executeBarriers()
instead of PrimaryCommandBuffer. No actual functionality change is
expected.
Bug: b/275624771
Change-Id: Ia06a0398a127539b0b642005803a498cb2a9d7f1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4400407
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
20f875f8
|
2023-04-05T09:47:46
|
|
Vulkan: Add commandQueueWaitSemaphoresTotal perf counter
This counts total number of wait semaphores we submitted. This will be
used to write test to ensure that we insert wait semaphores properly in
future CLs.
Bug: b/275624771
Change-Id: I5b8e209500ff553617f6b30c2f8b4626d29c0e6a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4400823
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
8b79410b
|
2023-04-02T22:25:12
|
|
Vulkan: Treat readonly SSBOs as readonly!
Instead of assuming SSBOs are always written to, this change adds
plumbing for the backend to know when an SSBO is declared readonly and
marks the buffer readonly accordingly.
With this change, BufferVk can optimize uploads and copies to and from
the buffer with the knowledge that it can be safely mapped on the CPU
for read while it's being used by the GPU.
Bug: b/276002151
Change-Id: I75342148c07949a83436054a738395bbd88caec5
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4392720
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
41f0a321
|
2023-04-03T21:58:43
|
|
Revert "Vulkan: Reactivate already started render pass when possible"
This reverts commit ad9537af7f2bb5e22bc73f4e833fd3789adaa217.
Reason for revert: Suspected cause for flakiness. anglebug.com/8118
Original change's description:
> Vulkan: Reactivate already started render pass when possible
>
> In some usage case (such as lineage_mobile), we are seeing in the middle
> of render pass, app switch to another fbo just to issue a glClear()
> call, which the clear call itself gets deferred. Application then switch
> back to the original frame buffer. Before this CL, the render pass gets
> recreated due to frame buffer binding change, even though the clear gets
> deferred and new render pass and the previous render pass are
> essentially the same. This CL detects this situation and reactivate the
> current render pass instead of creating a new one. With this CL,
> lineage_m app trace reduces frame time from 3.86ms to 3.7ms, and only
> one render pass is used instead of two.
>
> This CL also allows the render pass started by BlitFramebuffer reused by
> subsequent draw calls. Asphalt_9 is hitting this use pattern and this CL
> reduces frame time by 0.1245 ms (from 5.6203 ms to 5.4958 on pixel 7
> pro)
>
> Bug: b/273808966
> Change-Id: I48c2671cbef3ff9d6cf59caae88c37c77828ee07
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4348713
> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
> Commit-Queue: Charlie Lao <cclao@google.com>
Bug: b/273808966
Change-Id: I81cc2dcacb52466808b2ccf5819feda466c39fc5
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4396502
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
3aea3cfd
|
2023-04-03T16:38:29
|
|
Vulkan: Workaround depth bias constant factor on ANV
Bug: b/249380591
Change-Id: Iaeda7faf5eb40e0e2086674d3e63bf5bc9911ab4
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4392893
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
c5e9de23
|
2023-04-03T15:14:03
|
|
Revert "Vulkan: Use midRenderPass clear if RP has started but inactive"
This reverts commit 98151770adfd990c533991da27615b4879494307.
Reason for revert: Suspected cause for flakiness. anglebug.com/8118
Original change's description:
> Vulkan: Use midRenderPass clear if RP has started but inactive
>
> This CL extends prior CL's optimization so that if clear is issued right
> after blitFramebuffer call (this could make sense if blit and clear are
> on different buffer), we can keep the started render pass and do the
> midRenderPass clear instead of endRenderPass and start another
> renderPass.
>
> Bug: b/273808966
> Change-Id: Ia2504e8e260867a6f797d42cd4c8a72f187280ef
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4374145
> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Bug: b/273808966
Change-Id: I7a11635a6eceafb6f4fb3a0d95f6627ee98321c0
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4393497
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
b24b5568
|
2023-03-27T00:00:00
|
|
Vulkan: Skip sample coverage for single sample rendering
A new test sets sample coverage to zero and checks
that it is applied only to multisampled rendering.
Bug: angleproject:8102
Change-Id: I1a5649869e9b7ecf0543108fb99095bfaf6fd858
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4379839
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
|
|
|
98151770
|
2023-03-27T09:49:33
|
|
Vulkan: Use midRenderPass clear if RP has started but inactive
This CL extends prior CL's optimization so that if clear is issued right
after blitFramebuffer call (this could make sense if blit and clear are
on different buffer), we can keep the started render pass and do the
midRenderPass clear instead of endRenderPass and start another
renderPass.
Bug: b/273808966
Change-Id: Ia2504e8e260867a6f797d42cd4c8a72f187280ef
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4374145
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
ad9537af
|
2023-03-16T16:03:29
|
|
Vulkan: Reactivate already started render pass when possible
In some usage case (such as lineage_mobile), we are seeing in the middle
of render pass, app switch to another fbo just to issue a glClear()
call, which the clear call itself gets deferred. Application then switch
back to the original frame buffer. Before this CL, the render pass gets
recreated due to frame buffer binding change, even though the clear gets
deferred and new render pass and the previous render pass are
essentially the same. This CL detects this situation and reactivate the
current render pass instead of creating a new one. With this CL,
lineage_m app trace reduces frame time from 3.86ms to 3.7ms, and only
one render pass is used instead of two.
This CL also allows the render pass started by BlitFramebuffer reused by
subsequent draw calls. Asphalt_9 is hitting this use pattern and this CL
reduces frame time by 0.1245 ms (from 5.6203 ms to 5.4958 on pixel 7
pro)
Bug: b/273808966
Change-Id: I48c2671cbef3ff9d6cf59caae88c37c77828ee07
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4348713
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
97897d92
|
2023-03-27T16:02:57
|
|
Vulkan: Work around driver bug with dynamic primitive restart
This CL forces the state to be static on buggy drivers.
Bug: b/275210062
Change-Id: Ia3391ecb19c3c9d19c05a83e11da8c718513a4e2
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4374104
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@google.com>
|
|
c6ec59dc
|
2023-03-27T11:15:48
|
|
Explicitly pass the extended dirty bits to syncState.
Add a the extended dirty bits and bit mask to syncState instead of
calling gl::State::getAndResetExtendedDirtyBits when encountering
DIRTY_BIT_EXTENDED. It disallowed us from masking the extended dirty
bits and feels like an anti-pattern to modify the extended dirty bits
in gl::State from the backend.
This is a refactor only.
Bug: chromium:1410191
Change-Id: I66fdec3eb57e3426cf0fda9ccb759700eafdda14
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4374100
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
e27e7c6a
|
2023-03-17T19:43:54
|
|
Vulkan: Retire Command Buffers before destroying the Pools.
"VulkanSecondaryCommandBuffer"s may be still in "CommandQueue" when
"ContextVk" destroys the Command Pools (asyncCommandBufferReset = true).
Fixed by calling "retireFinishedCommandsLocked()" when appropriate.
Normally, it is only required to retire Vulkan Secondary Buffers.
However, some drivers may have bug and also require to reset
Primary Buffers, that have Secondaries recorded, before destroying the
Secondaries Pools.
Bug: angleproject:6811
Bug: angleproject:6100
Change-Id: I891547c95cfbdfab44398980f939596af56ab57b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4350269
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
9524c639
|
2023-01-17T18:47:47
|
|
Vulkan: Fix Secondary Command Buffers with asyncCommandQueue.
This change fixes following errors (asyncCommandQueue = true):
1. "vkEndCommandBuffer()" called from "asyncCommandQueue" thread.
Call stack:
vkEndCommandBuffer()
VulkanSecondaryCommandBuffer::end()
OutsideRenderPassCommandBufferHelper::flushToPrimary()
CommandQueue::flushOutsideRPCommands()
CommandProcessor::processTask()
Fixed by calling "vkEndCommandBuffer()" from the Context thread
in the new "OutsideRenderPassCommandBufferHelper::detachCommandPool()"
method.
2. "vkAllocateCommandBuffers()/vkBeginCommandBuffer()" called from
"asyncCommandQueue" thread.
Call stack:
vkAllocateCommandBuffers()/vkBeginCommandBuffer()
VulkanSecondaryCommandBuffer::initialize()
<*>CommandBufferHelper::initializeCommandBuffer()
<*>CommandBufferHelper::reset()
<*>CommandBufferHelper::flushToPrimary()
CommandQueue::flush<*>Commands()
CommandProcessor::processTask()
Fixed by calling "vkAllocateCommandBuffers()/vkBeginCommandBuffer()"
from the Context thread in the new
"<*>CommandBufferHelper::attachCommandPool()" method.
3. "SecondaryCommandPool::collect()" called from "asyncCommandQueue"
thread without synchronization.
Call stack:
SecondaryCommandPool::collect()
rx::vk::RecycleCommandBufferHelper()
CommandBufferRecycler<>::recycleCommandBufferHelper)
RendererVk::recycle<*>CommandBufferHelper()
CommandProcessor::processTask()
No need for this call, because "SecondaryCommandPool" is already
detached.
Notes:
This CL not only fixes errors, but also optimizes CommandBufferHelper
recycling. Before, there was no recycling plus unnecessary
"VulkanSecondaryCommandBuffer" allocation/freeing.
Further optimization may add multiple "VkCommandPool"s to the
"SecondaryCommandPool" to allow resetting buffers in the async thread.
Bug: angleproject:6811
Bug: angleproject:6100
Change-Id: I7004c27a112e916c5c973b43b137193017d6aa3d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4342189
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
|
|
|
f2c5ce4e
|
2023-03-16T17:44:56
|
|
Re-enable mutable texture upload for one context
It was observed that in some apps, mutable textures are uploaded in a
context, but that context's outside RP command buffer is not flushed
at all, resulting in invalid (noise) or incorrect textures.
* Added isEligibleForMutableTextureFlush() to be used to determine
whether onMutableTextureUpload() should be called.
* Restricted the use of mutable texture upload to single-context
share groups.
* When the number of contexts becomes greater than one, the original
context's outside render pass command buffer is flushed.
* Added related tests.
* Added a test to make sure that textures can be uploaded in one
thread, and used for draw calls in another, with the help of a
sync object.
* Added a test to make sure that textures can be uploaded in the
main thread, and used in a new thread.
* Added a test in which a new context is created after mutable
mipmap textures are defined.
Bug: b/264143971
Change-Id: I66c0d8b04d39bb7244e5752aac0e46a0192f012e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4349156
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
e809e7bd
|
2023-03-13T00:00:00
|
|
Reland "Implement EXT_depth_clamp"
This is a reland of commit f8c1418319ac2aef4b3101e322005b1d0f73120f
Host GPU bugs are observable in iOS Simulator
Original change's description:
> Implement EXT_depth_clamp
>
> * Added depthClamp to the RasterizerState
> * Added DepthWriteTest end2end tests covering
> both clipped and clamped depth writes
>
> Capture
> * Updated serialized rasterizer state
> * Updated CaptureMidExecutionSetup
>
> OpenGL
> * Requires GL 3.2 or ARB_depth_clamp
> on desktop contexts
> * Maps to EXT_depth_clamp on ES
>
> D3D11
> * Maps to the opposite of
> D3D11_RASTERIZER_DESC.DepthClipEnable
> * The new tests uncover several edge cases where
> a workaround is needed to implement unextended
> OpenGL semantics on top of D3D
>
> Metal
> * Maps to the setDepthClipMode command
>
> Bug: angleproject:8047
> Bug: angleproject:8077
> Change-Id: I1b3448e5b84443e4be18af9bc22d2f8495ac8267
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4347753
> Reviewed-by: Geoff Lang <geofflang@chromium.org>
> Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
Bug: angleproject:8047
Bug: angleproject:8077
Change-Id: I8c5f8304276c97c51b2c3382cd2764592ee0c3fe
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4349938
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
|
|
|
4a77b0f5
|
2023-03-18T00:16:24
|
|
Revert "Implement EXT_depth_clamp"
This reverts commit f8c1418319ac2aef4b3101e322005b1d0f73120f.
Reason for revert: This change breaks angle_end2end_tests on Metal backend: https://ci.chromium.org/ui/p/chromium/builders/ci/ios-angle-intel/26035/overview
Original change's description:
> Implement EXT_depth_clamp
>
> * Added depthClamp to the RasterizerState
> * Added DepthWriteTest end2end tests covering
> both clipped and clamped depth writes
>
> Capture
> * Updated serialized rasterizer state
> * Updated CaptureMidExecutionSetup
>
> OpenGL
> * Requires GL 3.2 or ARB_depth_clamp
> on desktop contexts
> * Maps to EXT_depth_clamp on ES
>
> D3D11
> * Maps to the opposite of
> D3D11_RASTERIZER_DESC.DepthClipEnable
> * The new tests uncover several edge cases where
> a workaround is needed to implement unextended
> OpenGL semantics on top of D3D
>
> Metal
> * Maps to the setDepthClipMode command
>
> Bug: angleproject:8047
> Bug: angleproject:8077
> Change-Id: I1b3448e5b84443e4be18af9bc22d2f8495ac8267
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4347753
> Reviewed-by: Geoff Lang <geofflang@chromium.org>
> Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
Bug: angleproject:8047
Bug: angleproject:8077
Change-Id: I829add68c006c72b7b4acf03aee3efa8a9a16fac
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4350876
Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Yuxin Hu <yuxinhu@google.com>
|
|
|
7d1a401b
|
2023-01-17T18:45:55
|
|
Vulkan: Fix freeing not completed Secondary Command Buffers.
Problem:
- Protected Context flushes its commands to the Protected
Primary Command Buffer;
- Unprotected Context flushes its commands to the Unprotected
Primary Command Buffer;
- Context with different "egl::ContextPriority" may flush commands
into different Primary Command Buffers.
- Secondary Command Buffers from all Contexts end-up in the single
"CommandBufferRecycler::mSecondaryCommandBuffersToReset" list;
- One of the Contexts submits its Primary Command Buffer, and attaches
current "mSecondaryCommandBuffersToReset" list to the "CommandBatch";
- Secondary Command Buffers of other Contexts may be collected and
later freed by "SecondaryCommandPool" without submitting/completion
corresponding Primary Command Buffers.
Fix:
- Moving "mSecondaryCommandBuffersToReset" to the new
"SecondaryCommandBufferCollector" class.
- Separate "SecondaryCommandBufferCollector" instance is stored
in the "CommandQueue" for each current Primary Command Buffer.
Additionally fixes "asyncCommandQueue" related problem:
"releaseCommandBuffersToReset()" may get outdated results if flush is
not yet executed in the "asyncCommandQueue" thread.
Bug: angleproject:6100
Change-Id: I7df161ac1f999fb34d4eccaebb603c58ecb1ac11
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4334579
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
|
|
|
9b6368cc
|
2023-03-14T14:48:30
|
|
Vulkan: Fix freeing Secondary Command Buffers from wrong thread.
Problem:
- Secondary Command Buffers are freed in the "CommandQueue" class.
- This may happen from any Context thread that calls
"checkCompletedCommands()" or "finish<*>()" methods.
- As the result, one Command Buffer may be freed from one thread, while
other Command Buffer from the same "VkCommandPool" is
allocated/reset/recorded in the other thread.
Vulkan spec demands external "VkCommandPool" synchronization for any
modifications (begin/end/reset/free/cmd) on its "VkCommandBuffer"s.
Fix:
- Added new "rx::vk::SecondaryCommandPool" class that replaces the
"rx::vk::CommandPool" wrapper.
- This class has "collect()" method for storing "VkCommandBuffer"s.
Collected buffers are freed from the correct thread on the next
"allocate()" call.
This CL only fixes the problem, keeping Secondary Command Buffer memory
management as is (allocate/free single buffer without reuse).
In the future CLs this behavior may be changed (reuse buffers,
reset/free entire pools).
Bug: angleproject:6100
Change-Id: If938416c4df4fe55f0cfb418b6759721ac53098b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4334577
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
f8c14183
|
2023-03-13T00:00:00
|
|
Implement EXT_depth_clamp
* Added depthClamp to the RasterizerState
* Added DepthWriteTest end2end tests covering
both clipped and clamped depth writes
Capture
* Updated serialized rasterizer state
* Updated CaptureMidExecutionSetup
OpenGL
* Requires GL 3.2 or ARB_depth_clamp
on desktop contexts
* Maps to EXT_depth_clamp on ES
D3D11
* Maps to the opposite of
D3D11_RASTERIZER_DESC.DepthClipEnable
* The new tests uncover several edge cases where
a workaround is needed to implement unextended
OpenGL semantics on top of D3D
Metal
* Maps to the setDepthClipMode command
Bug: angleproject:8047
Bug: angleproject:8077
Change-Id: I1b3448e5b84443e4be18af9bc22d2f8495ac8267
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4347753
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
|