|
98915e44
|
2025-09-12T14:15:05
|
|
Vulkan: Fix blit src missing mip
Bug: angleproject:433816259
Bug: angleproject:40644750
Change-Id: I50261279224dea8e37beff388207b927399d099a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6944327
Reviewed-by: Cody Northrop <cnorthrop@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
428afbc2
|
2025-09-09T12:38:30
|
|
Vulkan: Remove hardcoded image layouts
In some places, ANGLE assumed and hardcoded the image layout. This was
often unnecessary, as the layout (or ImageAccess) was readily available
already.
In preparation for setting the image layout to GENERAL due to
VK_KHR_unified_image_layouts, this change makes sure the image layout is
not assumed to be anything specifically not GENERAL.
Bug: angleproject:422982681
Change-Id: I831bed0ca20197bd7424295ab0858d6bce83fe81
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6932268
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
166c9e23
|
2025-09-05T12:52:38
|
|
Vulkan: Separate barrier data into its file
vk::Renderer includes a modified copy of kImageMemoryBarrierData. When
using VK_KHR_unified_image_layouts, even more of this data is modified
based on device features. Leaving kImageMemoryBarrierData in
vk_helpers.cpp runs the risk that it's accessed directly instead of
using the copy in vk::Renderer.
Bug: angleproject:422982681
Change-Id: I7e288ef0ac519c53842214fe934ba7b2474e1f9c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6927350
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
26926a8b
|
2025-09-08T13:07:49
|
|
Vulkan: Rename CommandBufferAccess to CommandResources
CommandBufferAccess was named as such to indicate "what the command
buffer is going to access". The new name indicates "what resources are
the following command going to use".
The rename is happening to reduce usages of "access", in preparation for
introducing another "access" which can be confused with this.
Bug: angleproject:422982681
Change-Id: Ib072cde8533515ba76734b6426b4d673cb07cc45
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6923331
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
25390156
|
2025-08-21T00:13:19
|
|
Suppress unsafe buffers on a file-by-file basis in src/ [1 of N]
In this CL, we suppress many files but stop short of actually
enabling the warning by not removing the line from the
unsafe_buffers_paths.txt file. That will happen in a follow-on
CL, along with resolving any stragglers missed here.
This is mostly a manual change so as to familiarize myself with
the kinds of issues faced by the Angle codebase when applying buffer
safety warnings.
-- Re-generate affected hashes.
-- Clang-format applied to all changed files.
-- Add a few missing .reserve() calls to vectors as noticed.
-- Fix some mismatches between file names and header comments.
-- Be more consistent with header comment format (blank lines and
trailing //-only lines when a filename comment adjoins license
boilerplate).
Bug: b/436880895
Change-Id: I3bde5cc2059acbe8345057289214f1a26f1c34aa
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6869022
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
677d8281
|
2025-08-25T15:59:46
|
|
Vulkan: Pass ContextVk to view-creation functions
In preparation for moving the ycbcr conversion cache to the share group.
This change is a no-op.
Bug: angleproject:440364873
Change-Id: I0c18062259b07813dd04ec02650bb6fab48947ad
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6879204
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
214a48c4
|
2025-07-16T12:42:18
|
|
Vulkan: add support for yuv resolve with transient image
Add support for the YUV_target extension in cases where the
implementation supports VK_ANDROID_external_format_resolve without
supporting nullColorAttachmentWithExternalFormatResolve.
Bug: angleproject:386749841
Tests: ImageTest*YUV*
Change-Id: Iebcb4f843b962f3d0d2f4e42db479902b6c1f849
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6761834
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
cdffecb7
|
2025-07-21T11:30:45
|
|
Vulkan: Ensure FramebufferVk::mRasterizationSamples > 0
GraphicsPipelineDesc can't handle samples being zero. This CL ensures we
always use at least one sample.
Bug: angleproject:431250668
Change-Id: I7f6b14c6060585fe7ef6fb55ed6a4b9813634f3f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6431827
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
d5babf99
|
2025-06-23T12:46:51
|
|
Vulkan: Fix unhandled deferred clears after glGetMultisamplefv
Issue was introduced in the commit that implemented deferred clears.
The `glGetMultisamplefv()` synchronizes draw framebuffer which defers
possibly staged clears. Since API is not handling deferred clears they
are left untouched, causing the ASSERT.
This change fixes the issue by not deferring clears for the
`glGetMultisamplefv()` command during flushing staged updates of dirty
framebuffer attachments.
Changes:
- Add `gl::Command::GetMultisample` enumeration for clarity.
- Add `gl::CommandBlitBuffer::CommandBlitBufferDepthStencil` enumeration
to improve code readability.
- Add `command` parameter into `gl::State::syncDirtyObject()` method to
use actual command enum instead of `Other`.
- Remove `previousDeferredClears` local variable and update ASSERT in
the `FramebufferVk::syncState()` method. New assert ensures empty
`mDeferredClears` instead of just checking dirty attachments, since
it is easy to make all attachments dirty making old and new assertions
act the same.
- Replace logic in `FramebufferVk::syncState()` that decides whether
need to defer attachments or not with switch-case. This makes the
logic more clear regarding handling individual commands and simplify
updating this handling in the future. Except of the bug fix with
`GetMultisample` command, handling of other command is uncached.
- Remove `flushDeferredClears()` from `FramebufferVk::readPixels()`
because `mDeferredClears` are not expected (now it's more clear after
the refactoring). And even if there are `mDeferredClears` (in case of
a bug or after API failure), `flushDeferredClears()` only flushes
clears for the draw framebuffer, while checking `mDeferredClears` of
the read framebuffer. This is a problem in case if read and draw
framebuffers are not the same.
Bug: angleproject:40644727
Test: angle_end2end_tests --gtest_filter=TextureMultisampleTest.GetMultisamplefvAfterClear/*
Test: angle_end2end_tests --gtest_filter=EGLSurfaceTest.GetMultisamplefvAfterClear/*
Change-Id: I376a62de52de5e17dbc63cc7ddb0506741a69266
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6661958
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
d8c15499
|
2025-05-27T03:46:24
|
|
Vulkan: Clear depth and stencil unresolve separately
To take into account two situations.
1. LoadOp for depth and stencil attachments are set differently.
2. depth and stencil unresolves could be different between the
previous render pass and the current render pass.
Bug: angleproject:42266019
Change-Id: I9e069b3972f86abb84eee6280919e6bba2901225
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6590197
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
65159c4e
|
2025-06-05T15:05:46
|
|
Update pipeline desc when sample count changes
* If the sample count changes when calling
glFramebufferTexture2DMultisampleEXT, we need to update pipeline desc
to ensure it is the same as the API requires.
* Add a new end2end test to verify.
Bug: angleproject:422611722
Change-Id: I7de7d3d17513cf03f5e24baa2db83633a229b4b8
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6623419
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Auto-Submit: Aurora Zhang <Aurora.Zhang@arm.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
db962407
|
2025-06-03T08:00:43
|
|
Vulkan: Optimize FramebufferVk::getSamples()
Cache value of samples during syncState(...) and return this value
on subsequent queries
Bug: angleproject:386749841
Change-Id: I21fb2221187c7b2159fed1b271da642ba2552348
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6619019
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
|
|
|
c884460a
|
2025-04-24T16:43:04
|
|
Vulkan: Fix deferred clears vs noop multidraw
Bug: chromium:407828338
Change-Id: I5da22aeb72605bb7943fa5ae079ae297d00888f7
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6488794
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Cody Northrop <cnorthrop@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
cbe26d0c
|
2025-03-04T16:56:26
|
|
Wrong texture coordinates sent to VULKAN for blit
In ANGLE's Vulkan backend, complex blit operations are implemented using
draw calls that utilize samplers and shaders, with texture coordinates
passed via push constants.
In this test case, texture coordinates are calculated based on the
effective framebuffer size, which is determined by the smallest
attachment dimensions. However, the draw call is executed on an
attachment with its original size, leading to unexpected texture
coordinates and incorrect sampling results.
Use ReadImageExtent size instead of framebuffer effective size to
calculate the sample texture coordinate.
Bug: angleproject:400584608
Change-Id: I06f0a1e48463f36aef7189f772515561d2e752d1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6321348
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Auto-Submit: Jiaqi Li <Jiaqi.Li@arm.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
65343c4c
|
2025-02-27T11:23:04
|
|
Vulkan: Improve ConvertImageLayoutToVkImageLayout()
This CL removes supportsMixedReadWriteDepthStencilLayouts feature flag.
This feature flag was introduced when ANGLE only requires vulkan 1.0.
But now we require vulkan 1.1 and this is part of vulkan 1.1 core spec.
So it is no longer needed and wasting CPU cycles to check this every
time ConvertImageLayoutToVkImageLayout() is called.
With supportsMixedReadWriteDepthStencilLayouts removed, convert from
ImageLayout to VkImageLayout no longer needs renderer parameter. The
layout information in kImageMemoryBarrierData is never modified by
renderer at run time. So the renerer arguments has been removed in a lot
of places, avoids another pointer de-reference.
Bug: b/384839847
Change-Id: I5a89a890c0c0a1f99d2fdc1b2a85baf7de5c28bf
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6310839
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
ba174a76
|
2025-02-19T16:35:15
|
|
Vulkan: Bugfix for nullColorAttachmentWithExternalFormatResolve
When nullColorAttachmentWithExternalFormatResolve is VK_TRUE,
* The imageView in VkRenderingAttachmentInfo for dynamic rendering
should be VK_NULL_HANDLE.
* Push YUV resolveImageView as if it is the color attachment to ensure
the coherency between ops, clearValues and attachmentViews for both
dynamic rendering and render pass objects. Then pack the YUV resolve
information first as well.
* Add end2end tests that render and clear YUV with a depth attachment.
Bug: angleproject:395212980
Change-Id: I8b6173b41723ed7dc12359e181791fb1ac22fc41
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6262510
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
03019646
|
2025-01-29T10:36:38
|
|
Vulkan: Fix invalidate of emulated format followed by more draws
If invalidating a color image with emulated channels, a clear is
automatically staged so the emulated channels don't contain invalid data
later. This is problematic with deferred clears; the clear marks the
framebuffer attachment as dirty, and the next command causes
`FramebufferVk::syncState` to pick the clear up as a deferred clear.
This is normally correct, except if the following command is another
draw call; in that case, the render pass does not close, yet the clear
is cached in `mDeferredClears`. When the render pass later closes, it
undoes the invalidate and attempts to remove the clear from the image...
but it does not exist there anymore (it's in `mDeferredClears`). Next
usage of the image then clears it, undoing the draws after invalidate.
In this case, the simplest approach is to close the render pass right
away here. Note that it is not possible to make
`FramebufferVk::syncState` avoid picking up the clear in
`mDeferredClears`, not apply the clear, _and_ keep the render pass open;
because future uses of the image (like with |glReadPixels|) will not
trigger `FramebufferVk::syncState` and the clear won't be done.
Bug: angleproject:353167428
Change-Id: Ie677bd12d9f11953cdcd5e4c374b59c4f63e7456
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6214331
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
c1214ec2
|
2025-01-22T14:22:56
|
|
Vulkan: Rename Context to ErrorContext
In preparation for adding another Context (derived by GL and CL
contexts), which includes logic that pertains to command recording (such
as barrier tracking).
Bug: angleproject:390443243
Change-Id: Idf495b62e63fb9aa901a2f16447fdaf3c2acd90b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6191248
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
87d891dc
|
2024-12-13T19:51:42
|
|
Inline more tiny functions on hot path
Similar to https://crrev.com/c/6094283, not as hot but broader.
Highlighted by PGO profile of driver_overhead_2 trace combined with size
and offset of the corresponding .so sections to maximize reduction in
TLB misses.
Improves driver_overhead_2 performance by 1~2% on Pixel 8. Almost no
change in .so size as functions are tiny.
Bug: b/383305597
Change-Id: Ib1c021d4635141b879667b59305e4d45de7b8aef
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6088958
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Roman Lavrov <romanl@google.com>
|
|
|
518e162e
|
2024-11-15T00:07:14
|
|
Fix validation for 3D depth/stencil textures
They should fail with GL_INVALID_OPERATION:
> Textures with a base internal format of DEPTH_COMPONENT, DEPTH_STENCIL
> or STENCIL_INDEX are supported by texture image specification
> commands only if target is TEXTURE_2D, TEXTURE_2D_MULTISAMPLE,
> TEXTURE_2D_ARRAY, TEXTURE_2D_MULTISAMPLE_ARRAY, TEXTURE_CUBE_MAP or
> TEXTURE_CUBE_MAP_ARRAY. Using these formats in conjunction with any
> other target will result in an INVALID_OPERATION error.
Bug: angleproject:379674017
Change-Id: Icdd4cea24601f6744a3a85bdf8ef07946569a16f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6019830
Reviewed-by: Alexey Knyazev <lexa.knyazev@gmail.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
e3b3dd68
|
2024-11-14T23:00:52
|
|
Vulkan: Optimize color clears vs read-only depth/stencil switch
When switching to read-only depth/stencil mode, if the aspect that
intends to be in read-only mode has a deferred clear, the clear is
flushed separately beforehands (as that would be a write operation).
Prior to this change, _all_ deferred clears were flushed for simplicity.
In this change, only the aspect that is switching modes is cleared,
leaving the other aspects free to be optimized as loadOp of the
following render pass.
Bug: angleproject:378058737
Change-Id: Iba4371590bee99f5022575c09b0d32231562488c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6019829
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
08c1724f
|
2024-10-11T14:29:00
|
|
Vulkan: Support GL_ARM_shader_framebuffer_fetch_depth_stencil
Bug: angleproject:352364582
Change-Id: I63fd78314fa7ebccbf366c252e309a9c0f09c8c1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5938150
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
65fcf9c4
|
2024-10-26T10:53:18
|
|
Vulkan: Remove redundant dependent feature checks
Since [1], when a feature is overriden, the dependent features
automatically take the override into account. Tests no longer need to
account for dependent features, neither does the logic in the code.
[1]:https://chromium-review.googlesource.com/c/angle/angle/+/4749524
Bug: angleproject:42266725
Change-Id: I5440aba4a89cffbe710e26ad7de4cfee783e9bdf
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5967414
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
a19f0947
|
2024-10-17T22:42:30
|
|
Vulkan: Cache depth- and stencil-only views
Existing depth/stencil blit and resolve paths created temporary depth-
and stencil-only views. For
GL_ARM_shader_framebuffer_fetch_depth_stencil, such views are needed as
well.
In preparation for that extension, this change adds depth- and
stencil-only views to ImageViewHelper and allows them to be retrieved
through RenderTargetVk. The blit and resolve paths are consequently
simplfied as a side-effect.
Bug: angleproject:352364582
Change-Id: Ia822efb44ca7c82f63afce904eb19dd1bed02ff5
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5938149
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Yuxin Hu <yuxinhu@google.com>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
a1584f49
|
2024-10-11T21:17:32
|
|
Vulkan: Qualify framebuffer fetch with "Color"
In preparation for depth/stencil framebuffer fetch, many framebuffer
fetch symbols are affixed with Color to indicate that they pertain to
color framebuffer fetch logic.
Bug: angleproject:352364582
Change-Id: I86000ada5e6ef47387dec0b6a3fca589d816cdc2
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5926593
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
1608d0be
|
2024-10-10T16:53:15
|
|
Vulkan: Isolate framebuffer fetch no-RP-break optim from DR
Prior to [1], changes to framebuffer fetch usage by shaders caused a
render pass break. This was due to a limitation of render pass
compatibility rules. It also caused other headache, such as needing to
clear the render pass cache, recreating pipelines etc.
[1]:https://chromium-review.googlesource.com/c/angle/angle/+/3697308
In [1] an important optimization was implemented for tiling GPUs where
ANGLE permanently switched to framebuffer fetch mode on first
encountering framebuffer fetch use. From that point on, ANGLE would
always make every render pass framebuffer fetch compatible.
In reality, the render pass break was unnecessary, which became apparent
with dynamic rendering (for example that whether the render pass
includes input attachments has no bearing on a pipeline that doesn't use
input attachments at all). In [2], dynamic rendering kept the render
pass break + permanent switch behavior for simplicity.
[2]:https://chromium-review.googlesource.com/c/angle/angle/+/5637155
This change untangles the optimization done for legacy render passes
from dynamic rendering, allowing dynamic rendering to start every render
pass without framebuffer fetch and enable it later if a framebuffer
fetch program is used.
This is in preparation for supporting depth/stencil framebuffer fetch,
where a perma-switch is troublesome (for example in combination with
read-only depth/stencil feedback loops).
Bug: angleproject:352364582
Change-Id: I31221cf22a28d58b9b2bf188e9c0b786cd0fe3d2
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5923120
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
b3d85cce
|
2024-09-30T14:28:35
|
|
Vulkan: Consolidate write colorspace override states
ColorspaceState struct is now used to cache write colorspace related
states to determine the colorspace of Vulkan draw image views.
ImageViewHelper methods are called during initialization and when
colorspace related states are toggled dynamically which in turn process
these states and determine the final write colorspace.
We can now fully support rendering to EGLImages, with colorspace
overrides, via texture or renderbuffer EGLImage targets
Bug: angleproject:40644776
Tests: ImageTest*Colorspace*Vulkan
MultithreadingTestES3.SharedSrgbTextureMultipleContexts*Vulkan
ReadPixelsPBOTest.SrgbUnorm*Vulkan
Change-Id: I2be2cd3b5b2b4ac8ecb803c34cde2b846cbd1cbe
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5901256
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
|
|
|
605c2f85
|
2024-09-27T12:00:58
|
|
Vulkan: Bugfix in FramebufferVk::blit(...)
If any color attachment of GL_DRAW_FRAMEBUFFER is already in use in the
currently started renderpass, don't reuse the renderpass for blit.
Bug: angleproject:40644776
Tests: Texture2DTestES3.UnitTest_DMSAA_dst_read*
Change-Id: Ib4266fc65d0ac7151f362f263e9e706adb1231ce
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5895158
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
7c811715
|
2024-09-25T11:09:44
|
|
Vulkan: fix crash when clearing stencil with ClearBuffer
Follow up to [1] which fixed a crash with glClear, but the bug remained
with glClearBufferiv. This change refactors the "is stencil write
masked out" query to always take the framebuffer's stencil bit count
into account (practically always 8), which also happens to make the rest
of the code checking this query more accurate in the presence of
nonsense masks where the bottom 8 bits are 0.
[1]: https://chromium-review.googlesource.com/c/angle/angle/+/3315158
Bug: chromium:40207259
Bug: angleproject:42266334
Change-Id: I68a6b0b75c67ed2cdc8c4d03b243efe5495efce1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5889788
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Geoff Lang <geofflang@chromium.org>
|
|
eaffa034
|
2024-09-24T20:56:04
|
|
Revert "Vulkan: Consolidate colorspace override states"
This reverts commit bffcd235ba6c031603d798daaa98f1cf9a3f3e46.
Reason for revert: Breaks Android test `org.skia.skqp.SkQPRunner#UnitTest_DMSAA_dst_read`. Details:
https://b.corp.google.com/issues/369388539.
Original change's description:
> Vulkan: Consolidate colorspace override states
>
> ColorspaceState struct is now used to cache colorspace related states
> and used to determine the colorspace of Vulkan image views.
> ImageViewHelper methods are called during initialization and when
> colorspace related states are toggled dynamically which in turn process
> these states and determine the final read and write colorspaces.
>
> We can now fully support rendering to EGLImages, with colorspace
> overrides, via texture or renderbuffer EGLImage targets
>
> Bug: angleproject:40644776
> Tests: ImageTest*Colorspace*Vulkan
> MultithreadingTestES3.SharedSrgbTextureMultipleContexts*Vulkan
> SRGBTextureTest.SRGB*TextureParameter*Vulkan
> SRGBTextureTestES3.SRGBDecodeTexelFetch*Vulkan
> ReadPixelsPBOTest.SrgbUnorm*Vulkan
> Change-Id: I1cc2b5bd834b519b83deab4d80a2fcaabeb271d6
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5841290
> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
> Reviewed-by: Charlie Lao <cclao@google.com>
> Commit-Queue: mohan maiya <m.maiya@samsung.com>
Bug: angleproject:40644776
Change-Id: I5bf6cf2ed0c8ec22fc02d8c3da92673ee85fe002
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5888506
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Yuxin Hu <yuxinhu@google.com>
|
|
|
bffcd235
|
2024-09-13T14:58:00
|
|
Vulkan: Consolidate colorspace override states
ColorspaceState struct is now used to cache colorspace related states
and used to determine the colorspace of Vulkan image views.
ImageViewHelper methods are called during initialization and when
colorspace related states are toggled dynamically which in turn process
these states and determine the final read and write colorspaces.
We can now fully support rendering to EGLImages, with colorspace
overrides, via texture or renderbuffer EGLImage targets
Bug: angleproject:40644776
Tests: ImageTest*Colorspace*Vulkan
MultithreadingTestES3.SharedSrgbTextureMultipleContexts*Vulkan
SRGBTextureTest.SRGB*TextureParameter*Vulkan
SRGBTextureTestES3.SRGBDecodeTexelFetch*Vulkan
ReadPixelsPBOTest.SrgbUnorm*Vulkan
Change-Id: I1cc2b5bd834b519b83deab4d80a2fcaabeb271d6
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5841290
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
|
|
|
9685cb96
|
2024-09-17T11:41:28
|
|
Vulkan: Clean up PackedClearValuesArray::store
The code was a bit confusing, raising question why there is check of
aspectFlags != VK_IMAGE_ASPECT_STENCIL_BIT. I believe this was
originally from
https://chromium-review.googlesource.com/c/angle/angle/+/2142711, and
then followed by
https://chromium-review.googlesource.com/c/angle/angle/+/2410366. The
code seems to having some special logic to handle packed depth stencil
clear value. This code may have been changed a bit. When I am looking at
current code base, I am not seeing good reason doing it this way. Caller
is handling the packed format by reading out depth value and pack them
together and then store. This CL replaces store/storeNoDepthStencil
pair to storeColor/storeDepthStencil.
Bug: b/167301719
Change-Id: I40cfca1e51654f5ddaf4b2e8460ae5a26c656f2b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5870921
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
1b4d6185
|
2024-09-12T09:18:46
|
|
Vulkan: Cleanup sRGB related code
Image and image view code is littered with sRGB related enums, even
in places that don't deal with sRGB. Remove sRGB related parameters
from initLayerImageView and getLevelLayerDrawImageView methods, which
now assume default values. Add dedicated methods that allow overriding
sRGB state values.
Also introduce ColorspaceState struct that consolidates all sRGB
related states, this will be used in follow up changes to track
and infer colorspace of image views
Bug: angleproject:40644776
Change-Id: Ifb366db48043e376f9ff6c30c852c44dd96562a1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5860808
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
|
|
|
22ed9877
|
2024-03-07T15:52:13
|
|
Vulkan: Generate fragment shading rates with compute
Generating fragment shading rates on the CPU could cause avoidable
stalls or increased latencies due to host<->device synchronization.
Instead generate the rates using a compute shader.
Optimize foveated rendering by treating a foveated draw with focal
points whose gainX or gainY is 0 as if it were an un-foveated draw
Bug: angleproject:42266906
Change-Id: If8c5504087997666c7d0c1cae8dcc5fab847187e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5754322
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
|
|
|
1db80b88
|
2024-07-10T12:47:42
|
|
Reland "Vulkan: Use VK_KHR_dynamic_rendering[_local_read]"
This is a reland of commit c379ff48043a47e444c388c45270db40d3172d50
Original change's description:
> Vulkan: Use VK_KHR_dynamic_rendering[_local_read]
>
> Bug: angleproject:42267038
> Change-Id: I1f4eb0f309992a9c1c287a69520dadf5eff23b26
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5637155
> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
> Reviewed-by: Charlie Lao <cclao@google.com>
Bug: angleproject:42267038
Change-Id: I083e6963b5421386695e49a9872edbb2016c9763
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5691342
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
1f87cbc9
|
2024-07-15T13:07:35
|
|
Vulkan: Fix late-added resolve attachment tracking
Resolve attachments may be added after the fact to a render pass due to
glBlitFramebuffer or eglSwapBuffer. Previously, only the resolve image
views were tracked by the render pass, and otherwise the state tracking
(layout, content defined, etc) treated the resolve images as generically
written-to by the render pass.
As a result, the render pass was unable to finalize the layout of the
resolve images early. Optimizing the layout of the swapchain image when
the surface is multisampled for example was not done due to this issue.
In this change, when resolve attachments are added late, they are
tracked identically to when they are added at the beginning of the
render pass, fixing the issues described above.
Bug: angleproject:42265625
Bug: angleproject:42266019
Change-Id: I765560762bb8caf39ba1096fb028177201c082d7
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5707470
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
373ac541
|
2024-07-10T11:14:47
|
|
Vulkan: Make surface RP check independent from framebuffer object
With dynamic rendering, there is no framebuffer object, so checking
whether the currently open render pass belongs to the window surface (at
swap time) is made independent from these objects.
Bug: angleproject:42267038
Change-Id: I408e2376ba865b64fa1e8890316e8f57c08c695f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5691345
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
7d461b21
|
2024-07-10T14:11:53
|
|
Revert "Vulkan: Use VK_KHR_dynamic_rendering[_local_read]"
This reverts commit c379ff48043a47e444c388c45270db40d3172d50.
Reason for revert: Regresses CPU perf and memory when _not_ using DR
Original change's description:
> Vulkan: Use VK_KHR_dynamic_rendering[_local_read]
>
> Bug: angleproject:42267038
> Change-Id: I1f4eb0f309992a9c1c287a69520dadf5eff23b26
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5637155
> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
> Reviewed-by: Charlie Lao <cclao@google.com>
Bug: angleproject:42267038
Change-Id: I3865f0d86813f0eeb9085a92875a33bd449b907f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5691337
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
c379ff48
|
2024-06-10T22:01:57
|
|
Vulkan: Use VK_KHR_dynamic_rendering[_local_read]
Bug: angleproject:42267038
Change-Id: I1f4eb0f309992a9c1c287a69520dadf5eff23b26
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5637155
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
8c546d35
|
2024-06-25T12:49:40
|
|
Vulkan: Limit VkEvent for usage matters for Manhattan31 only
If we use VkEvent to track all image operations causes performance
regression on some app traces, including manhattan10 trace. This mainly
because of CPU overhead comes with VkCmdSetEvent, mostly inside vulkan
driver. These app traces likely not benefit from VkEvent because the
specific bubble (false dependency) does not manifest on these app
traces, but the CPU overhead takes a performance toll on it. In order to
strike a balance between benefit and overhead, this CL removes most of
VkEvent usage and only leaves the ones that matters for manhattan31. The
only we still keeps are generateMipmap, dispatchCompute, texture
sampling. We can always add more if more beneficial usage cases comes up
and no regression in other traces.
Bug: b/336844257
Change-Id: I346fe70bc33e57edf04e933a2db0f79738c4481d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5654737
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
d193d51b
|
2024-06-17T22:46:08
|
|
Replace issue ids post migration to new issue tracker
This change replaces anglebug.com/NNNN links.
Bug: None
Change-Id: I8ac3aec8d2a8a844b3d7b99fc0a6b2be8da31761
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5637912
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
06f1b72f
|
2024-06-03T08:59:46
|
|
Vulkan: Bugfix in MSRTT emulation
Transient multisampled images should have no mips. Enforce this
requirement when MSRTT is being emulated
Bug: angleproject:4836
Tests: MultisampledRenderToTexture*MultipleLevelsMultisample*
Change-Id: I6df21bbb49a4c45aa3ee321f7d49b81f55352562
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5601347
Commit-Queue: mohan maiya <m.maiya@samsung.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
d1db33b9
|
2024-05-20T16:49:18
|
|
Vulkan: Cleanup EXT_sRGB_write_control support
Bug: angleproject:5075
Change-Id: I91f40aaeaf5ff661ee2e227b5b1bb30a5b400e46
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5573396
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
|
|
|
3467f0f2
|
2024-05-20T16:24:53
|
|
Vulkan: Cleanup QCOM foveated rendering extensions support
Change removed `ContextVK::updateFoveatedRendering()` method because of
the following:
- Modifying `mGraphicsPipelineDesc` without also updating
`mGraphicsPipelineTransition` may case usage of incorrect PSO.
- Despite of the above, there is no bug, because the update itself
is redundant. In all cases, where `updateFoveatedRendering()` was
called, there also will be `onDrawFramebufferRenderPassDescChange()`
call, that will call `mGraphicsPipelineDesc->updateRenderPassDesc()`.
- The `onDrawFramebufferRenderPassDescChange()` will also call
`invalidateCurrentGraphicsPipeline()` therefore, there is no need for
this call in the `updateFoveatedRendering()`.
- In all cases, the `onRenderPassFinished()` is called before
`updateFoveatedRendering()`, therefore, there is no need to set
`DIRTY_BIT_RENDER_PASS` bit.
- All of the above made `updateFoveatedRendering()` completely
redundant (maybe except for the ASSERT).
Change also removed `mRenderPassDesc` update from
`FramebufferVk::updateFoveationState()`. Note: similar update may be
also removed when handling `shouldUpdateSrgbWriteControlMode`.
Also fixes possible `mFoveationState` and `mCurrentFramebufferDesc`
desynchronization in case if `updateFragmentShadingRateAttachment()`
fails.
Bug: angleproject:8484
Change-Id: If453bb6691e47aac3c11d0a5a6df696e885b64cb
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5573395
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
|
|
|
a96e9197
|
2024-04-25T10:35:02
|
|
Vulkan: Add RefCountedEvent class and VkCmdSetEvent call
This CL defines RefCountedEvent class that adds reference counting to
VkEvent. CommandBufferHelper and ImageHelper each holds one reference
count to the event. Every time an event is added to the command buffer,
the corresponding RefCountedEvent will be added to the garbage list
which tracks the GPU completion using ResourceUse. That event garbage's
reference count will not decremented until GPU is finished, thus ensures
we never destroy a VkEvent until GPU is completed.
For images used by RenderPassCommands, As
RenderPassCommandBufferHelper::imageRead and imageWrite get called, an
event with that layout gets created and added to the image. That event
is saved in RenderPassCommandBufferHelper::mRefCountedEvents and that
VkCmdSetEvents calls are issued from
RenderPassCommandBufferHelper::flushToPrimary(). For renderPass
attachments, the events are created and added to image when attachment
image gets finalized.
For images used in OutsideRenderPassCommands, The events are inserted as
needed as we generates commands that uses image. We do not wait until
commands gets flushed to issue VkCmdSetEvent calls. A convenient
function trackImageWithEvent() is added to create and setEvent and add
event to image all in one call. You can add this call after the image
operation whenever we think it benefits, which gives us better control.
(Note: Even if forgot to insert the trackImageWithEvent call, it is
still okay since every time barrier is inserted, the event gets
released. Next time when we inserts barrier again we will fallback to
pipelineBarrier since there is no event associated with it. But that is
next CL's content).
This CL only adds the VkCmdSetEvent call when feature flag is enabled.
The feature flag is still disabled and no VkCmdWaitEvent is used in this
CL (will be added in later CL).
Bug: b/336844257
Change-Id: Iae5c4d2553a80f0f74cd6065d72a9c592c79f075
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5490203
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
13829f20
|
2024-03-26T23:03:12
|
|
Vulkan: Optimize depth/stencil resolve with glBlitFramebuffer
Like color resolve, depth/stencil resolve is now also possibly done by
modifying the render pass and attaching a depth/stencil resolve
attachment.
Bug: angleproject:7551
Change-Id: I045e3875e24006d2473a55b6c3856dd768fe8b84
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5398004
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
b559efa8
|
2024-03-26T22:02:41
|
|
Vulkan: Allow depth and stencil resolve to be separately added
In preparation for optimizing resolve through glBlitFramebuffer for
depth/stencil attachments.
Bug: angleproject:7551
Change-Id: I57650d82c0cc6e56f44591eadfc42ac794cfef09
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5399140
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
0e9254bd
|
2024-03-25T16:37:51
|
|
Vulkan: Optimize color invalidates
By not flushing the render pass when there is an invalidate.
Previously, the tracking of invalidation, write to attachments,
management of load/store ops, and whether image contents are defined or
not have all been unified between color and depth/stencil images.
As such, it is possible to not close the render pass when a color image
is invalidated just as is not done for depth/stencil images. Together
with the optimization to resolve attachments [1], it is now finally
possible to efficiently do MSAA rendering with ANGLE.
Note that the optimization to use resolve attachments for depth/stencil
is not yet implemented. For color only, the perf test added in [2]
shows the following improvement on Pixel 6:
- Single sampled rendering: ~2.73ms
- Resolve + invalidate (before optimizations): ~3.54ms
- Resolve + invalidate (after this change): ~2.85ms
[1]: https://chromium-review.googlesource.com/c/angle/angle/+/5388492
[2]: https://chromium-review.googlesource.com/c/angle/angle/+/5392548
Bug: angleproject:7551
Change-Id: I008adf9f53df97ab464b0a0399f0b312bf4d0d3f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5391905
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
9475ac40
|
2023-11-15T10:25:06
|
|
Vulkan: Make efficient MSAA resolve possible
Prior to this change, using a resolve attachment to implement resolve
through glBlitFramebuffer was done by temporarily modifying the source
FramebufferVk's framebuffer description. This caused a good deal of
complexity; enough to require the render pass to be immediately closed
after this optimization.
The downsides to this are:
- Only one attachment can be efficiently resolved
- There is no chance for the MSAA attachment to be invalidated
In this change, resolve attachments that are added because of
glBlitFramebuffer are stored in the command buffer, with the
FramebufferVk completely oblivious to them. When the render pass is
closed, either the FramebufferVk's original framebuffer object is used
(if no resolve attachments are added) or a temporary one is created to
include those resolve attachments.
With the above method, the render pass is able to accumulate many
resolve attachments as well as have its MSAA attachments be invalidated
before it is flushed.
For a FramebufferVk that is resolved in this way, there used to be two
framebuffers created each time and thrown away as the code alternated
between starting a render pass without a resolve attachment and then
closing with one. With this change, there is now one framebuffer
(without resolve attachments) that is cached in FramebufferVk (and is
not recreated every time), and only the framebuffer with resolve
attachments is recreated every time.
Ultimatley, when VK_KHR_dynamic_rendering is implemented in ANGLE, there
would be no framebuffers to create and destroy, and this change paves
the way for that support too.
WindowSurfaceVk framebuffers are still imagefull. Making them imageless
adds unnecessary complication with no benefit.
-----------------
To achieve efficient MSAA rendering on tiling hardware, applications
should do the following:
```
glBindFramebuffer(GL_FRAMEBUFFER, msaaFBO);
// Clear the framebuffer to avoid a load
// Or invalidate, if not needed to load:
// glInvalidateFramebuffer(GL_DRAW_FRAMEBUFFER, ...);
glClear(...);
// Draw calls
// Resolve into the single sampled framebuffer
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, resolveFBO);
glBlitFramebuffer(...);
// Immediately discard the contents of the MSAA buffer, to avoid store
glInvalidateFramebuffer(GL_READ_FRAMEBUFFER, ...);
```
The above would translate to the following Vulkan render pass:
- MSAA LOAD_OP_CLEAR/DONT_CARE
- MSAA STORE_OP_DONT_CARE
- Resolve LOAD_OP_DONT_CARE
- Resolve STORE_OP_STORE
This makes sure the MSAA data doesn't leave the tile memory and greatly
reduces bandwidth usage.
Once anglebug.com/4892 is fixed, this would also allow the MSAA image
to never be allocated either.
Bug: angleproject:7551
Bug: angleproject:8625
Change-Id: Ia9f4d20863d76a013d8495033f95c7b39f77e062
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5388492
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
16fef70f
|
2024-03-22T12:09:12
|
|
Vulkan: Refactor imageless framebuffer creation
Bug: angleproject:7551
Change-Id: I6789123d1b854a64ce405dd1e096b9c28a227b5f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5384139
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
efd41bd2
|
2024-03-15T13:25:03
|
|
Vulkan: Rename ResourceVk.* to vk_resource.*
This file adds helpers to namespace vk, so its name is changed for
consistency with other namespace vk files.
Bug: angleproject:8564
Change-Id: I6525e7609eb9385f2a3eecaa7c52b7417fda7f12
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5370108
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
914fe61b
|
2024-03-15T13:20:49
|
|
Vulkan: Rename RendererVk.* to vk_renderer.*
Done in a separate CL from the move to namespace vk to avoid possible
rebase-time confusion with the file name change.
Bug: angleproject:8564
Change-Id: Ibab79029834b88514d4466a7a4c076b1352bc450
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5370107
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
2f934a47
|
2024-03-18T12:53:27
|
|
libstdc++: replace std::powf with std:pow
libstdc++ before GCC 14 does not provide std::powf. So replace the
call with std::pow, that provides an overload for floats.
For reference of the bug tracking the missing methods in libstdc++:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79700
Bug: chromium:41455655
Change-Id: Idfb53fe3c71f4dc0198cf6ba3e26c07895f65bc6
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5379670
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
60aaf4a0
|
2024-03-14T12:58:56
|
|
Vulkan: Move renderer to namespace vk
This class is agnostic of EGL. This change moves it to namespace vk for
use with the OpenCL implementation
Bug: angleproject:8564
Change-Id: I57f7807d6af8b3d5d7f8efbaf8b5d537a930f881
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5371324
Reviewed-by: Austin Annestrand <a.annestrand@samsung.com>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
ecaefce0
|
2024-03-06T14:54:17
|
|
Vulkan: Disable optimizeWithLoadOp if there is unresolve
If there is unresolve operation for MSRTT emulation code path, dont fall
back to loadOp for midRenderPassClear. Otherwise the clear will be lost
due to unresolve.
Bug: b/309355117
Change-Id: Ib39be0c980f663c08e80855ead32f6e0b07e60fc
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5350741
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: mohan maiya <m.maiya@samsung.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
91ddf851
|
2024-03-03T10:57:22
|
|
Vulkan: support QCOM foveated rendering extensions
Add support for foveated rendering in the vulkan backend.
This is done by leveraging the VK_KHR_fragment_shading_rate extension.
Bug: angleproject:8484
Change-Id: I0d01d07583f710b2302ea07b19c9d113c73bfe41
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5269907
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
5c2fc02b
|
2024-01-29T16:49:28
|
|
Vulkan: Bugfix in ImageFormat
FixedVector::operator[] does not update FixedVector::mSize.
Need to call FixedVector::push_back(...) instead.
Bug: angleproject:7553
Change-Id: I544a68276d1635957a27d21c222f50f71d35a609
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5246088
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
43187a24
|
2023-10-25T09:43:56
|
|
Vulkan: remap YUV clearColor component from GL order to vulkan order
For EXT_YUV_TARGET, OpenGL and vulkan uses difefrent mapping between YUV
to RGB. OpenGL spec says "When clearing YUV Color Buffers, clear color
should be defined in yuv color space and so floating point r, g, and b
value will be mapped to corresponding y, u and v value and alpha channel
will be ignored.", but vulkan spec says "Values in the G, B, and R
channels of the color attachment will be written to the Y, CB, and CR
channels of the external format image, respectively.". This CL adjusts
clear color to remap the clear color from GL ordering to vulkan
ordering.
This CL also adds a temporary workaround for ARM driver bug where they
were looking at unused color attachment instead of resolve attachment.
Bug: b/223456677
Change-Id: I9800bffc18ccd9d77b4e86995161cdde06257e1f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4973355
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Commit-Queue: Chris Forbes <chrisforbes@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
889b01ef
|
2023-10-17T12:13:10
|
|
Vulkan: Fix VK_android_external_format_resolve VVL error part 1
VUID-VkSubpassDescription2-nullColorAttachmentWithExternalFormatResolve-09337:
The Vulkan spec states: If the
nullColorAttachmentWithExternalFormatResolve property is VK_TRUE and
pResolveAttachments is not NULL, for each resolve attachment that has a
format of VK_FORMAT_UNDEFINED, the corresponding color attachment must
have the value VK_ATTACHMENT_UNUSED
VUID-VkFramebufferCreateInfo-attachmentCount-00876 The Vulkan spec
states: attachmentCount must be equal to the attachment count specified
in renderPass
Fix assertion in FramebufferVk::getFramebuffer()
Bug: b/223456677
Change-Id: I538a44753a2ba9b432fa3b1814748942cd8a3500
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4948652
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
cfc40d2b
|
2023-07-19T17:47:13
|
|
Vulkan: Adjust clear color precision for GL_RGB5_A1 FBO
When clear color has more precision than the framebuffer
format can hold, dithering is automatically applied on
some hardware.
This issue causes below dEQP tests to fail when the FBO
color attachment format is RGB5_A1:
KHR-GLES31.core.draw_buffers_indexed.color_masks
KHR-GLES32.core.draw_buffers_indexed.color_masks
Adjust the clear color precision for RGB5_A1 format to
workaround the issue.
We can remove this workaround once the vulkan driver
fixes the auto-dithering problem.
Bug: b/292282210
Change-Id: Ic3ffebd2d20c8782612619a60d1ec2cc6d613c22
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4937472
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Roman Lavrov <romanl@google.com>
Commit-Queue: Yuxin Hu <yuxinhu@google.com>
|
|
|
2e11fcc5
|
2023-10-16T16:40:35
|
|
Vulkan: Fix assertion when YUV image attached to resolve attachment
When YUV image attached to resolve attachment, mSamples is 1. Righ now
the code assumes resolve is a MSRT attachment, so it asserts mSamples>1.
This CL adds a new API packYUVResolveAttachment so that we can assert
properly for YUV and MSRT.
Bug: b/223456677
Change-Id: Ib65fd3fe1e6561b85395cc27204bbd85c1f464c3
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4942907
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
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>
|
|
|
adb17c80
|
2023-10-06T10:39:17
|
|
Vulkan: Copy 3D<->2DArray images with vkCmdBlitImage anyway
Despite the validation error, do the copy with vkCmdBlitImage anyway.
Drivers seem to work correctly, and the validation restrictions seem
unintentional.
Bug: angleproject:7291
Change-Id: Ie7a0ecfe559be44738da3eada281ea97424b38ab
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4916359
Reviewed-by: Roman Lavrov <romanl@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
8c341cfd
|
2023-10-04T12:49:59
|
|
Vulkan: Fix blits involving 3D images
The layer vs depth value involved with 3D images when calling
vkCmdBlitImage is fixed in this change.
However, that brought to light that the combination of
VUID-vkCmdBlitImage-srcImage-00240 and
VUID-vkCmdBlitImage-dstImage-00252 make it impossible to blit between 3D
and 2D array images, which is likely a spec oversight.
This change makes 3D<->2DArray blits fall back to draw-based blit. This
in turn exposed the fact that 3D images as src were not handled in
BlitResolve.frag. A new Blit3DSrc.frag shader is added which shares
code with BlitResolve.frag to implement this. This is a separate shader
to avoid creating unnecessary and invalid combinations of shaders.
VK_EXT_image_2d_view_of_3d could have been used to avoid this new
shader, but that is not ubiquitous.
Bug: angleproject:7291
Bug: dawn:1962
Change-Id: I6a96162f95829304b4731d43208d9d054f538105
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4911800
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
6b0ddce0
|
2023-09-22T13:13:38
|
|
Backends need to handle invalid render area during a clear
1. Frontend no longer noops empty scissors during clear
2. FramebufferVk is updated to handle invalid render area by restaging
deferred clears in clearImpl(...) if render area is invalid
Bug: angleproject:8348
Tests: EGLSurfaceTest*WindowThenScissoredClear*
Change-Id: Iec51914a083a59bad7f939798c932dffada56a6c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4867641
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
|
|
|
826e5f95
|
2023-09-24T09:48:55
|
|
Vulkan: Rename redeferClears as restageDeferredClears
This is a simple rename to better reflect implementation
and has no functional changes.
Bug: angleproject:8348
Change-Id: I53ce42e8bb14687a0dda167b8d79eba1eb357254
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4888691
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
430a4f55
|
2023-07-21T13:45:52
|
|
Fix read size validation for RGBX formats.
GL_RGBX8_ANGLE is the only format where the upload format is 3-channel
RGB, whilethe download format is 4-channel RGBX. As such, the internal
format corresponding to format+type expects 3-byte input/output. The
format is fixed here for readPixels to output 4 bytes per pixel.
Bug: chromium:1458046
Change-Id: Iec737ed64bade003cfab50dc5f595eb4875e81e4
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4706957
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
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>
|
|
0e7c79e3
|
2023-06-29T00:00:00
|
|
Vulkan: Fix resolve with multiple targets of different formats
Ensure that the appropriate code path is taken
when resolving into multiple target buffers of
different formats.
Bug: chromium:1123524
Change-Id: Ic25a52ba069a2209c907226613fde1109823c094
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4650561
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
|
|
|
e394cb46
|
2023-06-10T23:12:35
|
|
Vulkan: Refactor framebuffer fetch shader emulation
This change fixes simultaneous usage of EXT_shader_framebuffer_fetch and
ARM_shader_framebuffer_fetch, which previously declared two identical
input attachment variables.
The code is additionally greatly simplified.
Bug: angleproject:8196
Bug: angleproject:8197
Bug: angleproject:8198
Change-Id: Iaaa2a5539a95727e67001a4da1d45092c9db4f2c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4615187
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: mohan maiya <m.maiya@samsung.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
f1e19872
|
2023-06-12T14:38:23
|
|
Vulkan: Fix read pixels with RGBX
Typically, the format used for data uploads and downloads as well as the
storage format are consistent. That is unfortunately not the case for
GL_RGBX8_ANGLE where data uploads are through 3-byte RGB pixels while
downloads are through 4-byte RGBX pixels. This change swaps out RGBX
for RGBA on the read pixels path.
Test credit of Jason Macnak <natsu@google.com>
Bug: b/246008627
Test: atest CtsSkQPTestCases
Change-Id: I531ebd8318bf4fe5ac09c623068b790a7e301428
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4608488
Reviewed-by: Jason Macnak <natsu@google.com>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Geoff Lang <geofflang@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>
|
|
|
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>
|
|
|
96cda1ac
|
2023-03-31T15:08:11
|
|
Vulkan: Switch to modified framebuffer should trigger submit
The feature flag preferSubmitAtFBOBoundary intended to trigger
submitCommands call when FBO is switched. Right now there is a bug that
when FBO is switched, submitCommands did not get called even if feature
is enabled. The reason is that when framebuffer changed, we first get
FramebufferVk::syncState call, and if the FBO that we switched to is
drity, we will end up calling ContextVk::flushCommandsAndEndRenderPass
to immediate end the render pass. The problem with that is that later on
when we get to ContextVk::syncState and saw
DIRTY_BIT_DRAW_FRAMEBUFFER_BINDING dirty bit and try to issue a submit,
we notice render pass already ended, so mHasDeferredFlush never gets
set, which means we never call submitCommands. All apps render to system
framebuffer in the last render pass, and system framebuffer is always
dirty due to swap chain image rotation, we hit this almost with every
app. This CL avoid flushCommandsAndEndRenderPass() call from
FramebufferVk::syncState. We now relies on
ContextVk::onFramebufferChanged (which calls onRenderPassFinished()
which will set DIRTY_RENDER_PASS bit to trigger deferred endRenderPass)
to end the current render pass.
This CL also add a regression test to ensure the submit indeed occur.
Bug: b/275624771
Change-Id: I92b95a7a6c435f242d6684cb7852172cf41896c3
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4390642
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Roman Lavrov <romanl@google.com>
|
|
|
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>
|
|
|
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>
|
|
|
7eb6869a
|
2022-08-30T16:28:08
|
|
Vulkan: Change ResourceAccess::Write to ResourceAccess::ReadWrite
AS a preparation for the next CL which will optimize for WriteOnly
access, this CL changes Write to ReadWrite and adds WriteOnly access
(but not used yet). Mechanical changes only and no function difference
is expected.
Bug: b/243711628
Change-Id: I509d6045ae87635e24076b646af42f35d88d52cf
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3866672
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
3886af6e
|
2023-01-16T15:17:40
|
|
Vulkan: Generalize AHB optimization prohibitions
... to all external images.
Bug: angleproject:7962
Change-Id: Ib8e090b995330b651865953057869adb4d14c83b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4169559
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
90b6d511
|
2023-01-13T10:06:12
|
|
Vulkan: Add support for AHB usage FRONT_BUFFER flag
AHB usage flags have been updated to include front buffer usage.
AHBs tagged with this flag need to be handled similar to single-buffered
window surfaces especially w.r.t glFlush semantics. Account for the
new usage flag when deferring flushes.
Bug: angleproject:7956
Test: Android VTS GraphicsFrontBufferTests.*
Change-Id: I79440d8447ac569c3d785de191815d2d2f3f069f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4167063
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
|
|
|
410d8ba5
|
2022-12-21T13:27:00
|
|
Vulkan: Cleanup ContextVk::hasStartedRenderPass APIs
ContextVk has a few hasStartedRenderPass APIs which interpret "start"
inconsistently. A RenderPassCommands' life should be notStarted,
started, requestEnd, and end (which is equivalent to notStarted). When
someone calls onRenderPassFinished on a started renderpass, it does not
immediate endRenderPass, but it will set DIRTY_BIT_RENDER_PASS dirty bit
so that next draw call will trigger endRenderPass and start a new
renderPass. We do not have a name for this state, which adds some
confusion. This CL renames the stage between start and
onRenderPassFinished to be "active" renderpass, when you have
mRenderPassCommandBuffer pointer being valid and you can actively adding
draw commands into the renderPass. For this purpose, I haves renamed
hasStartedRenderPass to hasActiveRenderPass. This CL also simplifies
hasStartedRenderPass implementation to only check
mRenderPassCommandBuffer and turned mRenderPassCommands.started as
assertion. This CL also changes hasStartedRenderPassWithQueueSerial to
actually check mRenderPassCommands.started instead of being "active", so
that name reflects what it is actually checking. This CL also changed
hasStartedRenderPassWithCommands to hasActiveRenderPassWithCommands to
make name and implementation consistent. One added benefit of this is
that after this CL we now allow load/store optimization on a started but
inactive renderPass as well (for example glInvalidateFramebuffer call
after glFenceSync call, or invalidate after FBO blit as demonstrated by
MultisampleResolveTest.ResolveD32FSamples tests).
Bug: angleproject:7903
Bug: angleproject:7551
Change-Id: I8c8ec4c0d54b9ad0a9e373108dfce6b151c8fe0e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4119693
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
5f1ab1d1
|
2023-01-03T11:48:51
|
|
Fix Deferred Flush Bug On Android Hardware Buffer
When does app read from Android Hardware Buffer
is outside of ANGLE's control. If we defer glFlush,
it is possible that when the app is reading from
AHB, the commands have not been flushed and executed,
causing app to read unexpected data. This change
adds a check to not defer glFlush when the Framebuffer
draw attachment is Android Hardware Buffer.
Bug: b/262886794
Change-Id: Ie0606f71b1a4f4f20511b7327e7ffb8c096ac727
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4126700
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Yuxin Hu <yuxinhu@google.com>
|
|
|
6c41793f
|
2022-12-20T15:20:50
|
|
Vulkan: Use read/write depth/stencil layouts
This allows an application to have depth in read-only feedback loop
while stencil is being written to for example.
Bug: angleproject:7899
Bug: b/192477489
Change-Id: Ic2e11d32da7c7e3a7f3cd86dbafc5c56a0dbbfd7
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4116730
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
412dd368
|
2022-10-05T23:51:52
|
|
Vulkan: Use vkCmdClearAttachments for unmasked scissored clears
Building on work by Tim Van Patten <timvp@google.com>
In https://chromium-review.googlesource.com/c/angle/angle/+/3388635, not
only were unmasked scissored clears made to use vkCmdClearAttachments,
but also scissored clears could use loadOp=Clear. While this is
potentially faster, it comes with a number of complications.
This change only does the former. Unfortunately, due to a Qualcomm
driver bug that forces ANGLE to avoid vkCmdClearAttachments, code
simplification in the draw path cannot be made.
Bug: angleproject:5194
Change-Id: Iec4184a09ca7fd09e3e8148c53db503512e6b8f0
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3935893
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
8181c056
|
2022-11-22T15:34:48
|
|
Vulkan: Remove RenderPassSerial
RenderPassSerial was introduced to uniquely identify a
RenderPassCommands. With the work of per current context queue serial,
now every started RenderPassCommands already have a unique QueueSerial.
This CL removes RenderPassSerial and use renderPass's queueSerial
instead.
Bug: b/255414841
Change-Id: Id0a87319a9132cdb74aba195f1f05aa31454592b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4049966
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
2dde7357
|
2022-11-16T10:39:32
|
|
Vulkan: `const` render passes
Bug: angleproject:7369
Change-Id: I1ee1449bd8ea8c6a3e26e50a7f3734fad91dc911
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4031488
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
fbd7d5fa
|
2022-10-17T17:20:09
|
|
Move thread pool classes to common/
In preparation for access by image_util files.
Bug: b/250688943
Change-Id: I24777269a5071eae9a60f939635d01ed7246461f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3961454
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
9b5fff82
|
2022-10-05T21:56:00
|
|
Vulkan: Emulate shader stencil export for MSRTT
The MSRTT emulation code had one corner case issue that could lead to
performance and memory inefficiencies. That is when stencil needs to be
unresolved and VK_EXT_shader_stencil_export is not supported.
This change adds a path to emulate VK_EXT_shader_stencil_export and
removes this inefficiency.
This should help Chromium on older Android devices that lack both this
and the recent VK_EXT_multisampled_render_to_single_sampled extensions.
Chromium frequently breaks the render pass (crbug.com/1336981), which
easily leads to this situation.
Bug: angleproject:4836
Change-Id: Ifceec43f7f3807b7e32f4b379edcd4351ae76414
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3935892
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
c19ec948
|
2022-08-23T10:43:59
|
|
Vulkan: Implement imageless framebuffers
* Added the attachment image and create info objects to be used
for imageless framebuffers created in getFramebuffer().
* New helper class for framebuffers in RenderPassCommandBufferHelper:
MaybeImagelessFramebuffer, which includes a framebuffer object, if
the framebuffer is imageless, and the image views. This is to make
sure that the args for render pass begin info will be correctly set
up according to the status of the used framebuffer.
* Refactored the collection of attachments in getFramebuffer() into
a new function, getAttachmentsAndImagesFromRenderTargets(). It also
returns their corresponding ImageHelper* objects used to create the
framebuffer (from their image properties).
* New struct: RenderTargetInfo; which keeps track of render targets
and whether resolve image should be used for the render pass in the
form of the enum class RenderTargetImage.
* Added a new arg to getFramebuffer(): resolveRenderTargetIn; to use
when there is a valid resolveImageViewIn.
* Without using the framebuffer cache, we would require to handle
the framebuffer destruction by adding it to the garbage instead
of releasing it. For example, FramebufferVk::destroy() now adds
mCurrentFramebuffer to the garbage.
* Added new framebuffer unit tests.
* Added tests where two textures with different attributes are bound
to the same framebuffer before drawing, one after another.
* Added test where a blit occurs from a multisample texture into a
non-zero level of a resolve texture, each bound to a separate FBO.
* Added a new perf test to compare performance for enabled imageless
framebuffers vs disabled. (Credit: cclao)
Bug: angleproject:7553
Change-Id: Iacdbd73aaa01cbb0e37abf01ae4892bdfdd4b12f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3827644
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
06d0389a
|
2022-10-04T19:26:48
|
|
Remove leftover code regarding render pass serial
* Removed the render pass serial reset in the function where the
current framebuffer is released. (left over from a prior CL.)
Bug: angleproject:7553
Change-Id: I61b4a12ac8957f6e1dcd4bf0f4e233c068736dff
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3931901
Auto-Submit: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
5d7c4eca
|
2022-10-02T02:27:27
|
|
Vulkan: Don't flush depth/stencil on color blit
When syncing the read framebuffer for blit, deferred clears are picked
up for the attachments that are not being synced. They are then
redeferred so a future command would pick them hopefully as loadOp.
This change improves the frame time of Pretty Derby on Pixel 6 by ~23%.
Bug: angleproject:7727
Change-Id: Ie7d84c58315cd09204e5229f1ec73605d5a7f639
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3931973
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Cody Northrop <cnorthrop@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
836cc5e2
|
2022-09-09T22:06:22
|
|
Vulkan: add etc to bc compute transcoding.
use compute shader to transcode etc format to bc format.
Bug: b/243398683
Change-Id: Idbd0820a2df8d92fe690055dae2933bc559e9bfd
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3888501
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Hailin Zhang <hailinzhang@google.com>
|
|
|
053c6a06
|
2022-09-20T15:17:28
|
|
Vulkan: Add more tests for attachmentless framebuffer
This CL adds below test scenarios for attachmentless framebuffer:
1. Create first attachmentless framebuffer with larger size,
and create second attachmentless framebuffer with smaller size.
2. Create an attachmentless framebuffer with smaller size,
and grow its default width and height.
3. Create an attachmentless framebuffer with larger size,
and shrink its default width and height.
4. Create an attachmentless framebuffer with larger size,
given it an attachment with a medium size,
and shrink its default width and height.
This CL also splits the test failure bugs on different
vendor and renderer to different bug tickets.
This CL addresses a bug on vulkan backend:
only skip onFramebufferChange()
if the framebuffer has at least one attachment,
and mCurrentFramebufferDesc equals to priorFramebufferDesc.
Otherwise in test scenario 2 and 3 above,
we will use the wrong scissor size,
because the FramebufferDesc remains the same before and after
changing the default width and height,
and we will wrongly skip onFramebufferChange() where we update scissor
area to match with the new default width and height.
Bug: angleproject:7666
Bug: angleproject:7697
Bug: angleproject:7699
Bug: angleproject:7700
Bug: angleproject:7705
Change-Id: Ieb143b27f8c1a229dab8f43d0a16e3e871185941
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3908332
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
b9cd542e
|
2022-09-15T17:31:35
|
|
Vulkan: Use serial to check which FBO has open RP
In preparation for the scenario where an imageless framebuffer is
shared, checking whether the started render pass belongs to a certain
framebuffer is tweaked to use a serial-based method instead of checking
the framebuffer handle.
* Added the last render pass serial to ContextVk, which increments
every time a render pass begins. The serial is also stored in the
FramebufferVk object invoking it.
* Added the type RenderPassSerial for this purpose.
* Serials are generated through a serial factory in ContextVk.
* Updated hasStartedRenderPassWithSerial() to match the serials
instead of the handles.
* Removed the getFramebuffer() calls from FramebufferVk and UtilsVk
that are now unused.
Bug: angleproject:7553
Change-Id: Id60dcbf7973558d35e55ff4af4c71e50c6853bba
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3897970
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
0fefbe83
|
2022-09-14T15:20:00
|
|
Vulkan: Do not cache the FramebufferHelper with no attachment
If two FBOs don't have any attachments,
and their GL_FRAMEBUFFER_DEFAULT_WIDTH
and GL_FRAMEBUFFER_DEFAULT_HEIGHT are
different, there is no difference in
their cache key (vk::FramebufferDesc).
Therefore the Vulkan backend is not able
to distinguish between the two FBOs.
This can create issues when we
1. create first FBO with a smaller size, renders to it
2. create second FBO with a bigger size, renders to it
The second renderpass will use the FBO created
in the first renderpass, because it managed to
retrieve the first FBO from the cache with
the same cachekey. This triggers the
vulkan validation error:
VUID-VkRenderPassBeginInfo-pNext-02853,
saying the render area exceeds the
framebuffer size.
This CL fixed it by not adding the FramebufferHelper
to the cache, if it doesn't have any attachment.
These framebufferHelpers are cheap, without
cache there should not be much performance
drop.
Bug: angleproject:3579
Bug: angleproject:7351
Bug: angleproject:7666
Bug: b/246334302
Change-Id: Iddecafddb042bd16401f983f9ee1a021b845d8bb
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3891543
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
79aa846e
|
2022-08-17T13:40:33
|
|
Reland "Not recreate Framebuffer for eglMakeCurrent() call"
This is a reland of commit bf9c815263455403e587a9d2b0fdb9fb8e964208
Original change's description:
> Not recreate Framebuffer for eglMakeCurrent() call
>
> Right now, in eglMakeCurrent() call, ANGLE always release the
> default framebuffer object associated to the current context,
> and create a new default framebuffer object for the new current
> context. It impacts chrome performance, since chrome call
> eglMakeCurrent() a lot. With this CL, the default framebuffer
> will be created with gl::Context. When the surface is changed
> by eglMakeCurrent() call, ANGLE will detach the previous surface
> from the associated framebuffer, and attach the new surface to
> the next current context's default framebuffer.
>
> Bug: chromium:1336126
> Change-Id: Iaa747669250ae250245db383a716b4634df59ea4
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3827751
> Commit-Queue: Peng Huang <penghuang@chromium.org>
> Reviewed-by: Jamie Madill <jmadill@chromium.org>
> Reviewed-by: Geoff Lang <geofflang@chromium.org>
Bug: chromium:1336126
Change-Id: Iade19004a4335ac7bc6ca176a3c14d34afff8c9e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3877405
Auto-Submit: Peng Huang <penghuang@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|