|
21d747de
|
2024-11-20T11:54:15
|
|
Vulkan: Use vk::SharedPtr for SharedDescriptorSetCacheKey
This CL switches SharedDescriptorSetCacheKey from using c++
std::shared_ptr to our internal version of vk::SharedPtr. Also get rid
of an extra pointer indirection that SharedDescriptorSetCacheKey is a
reference counted of actual cache key instead of std::unique_ptr of
cache key.
Bug: angleproject:372268711
Change-Id: Id9af5070d24f67711d6decc3a30a260b8d4062d9
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6036302
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
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>
|
|
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>
|
|
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>
|
|
74816e9e
|
2024-08-29T15:58:22
|
|
Vulkan: Cleanup RenderTargetVk release/destroy methods
Current implementation of `release()` and `destroy()` methods does not
actually invalidate state of the object. All they do is manage the
Framebuffer cache.
The `release()` method renamed to `releaseFramebuffers()` to match its
behavior.
Added new `releaseImageAndViews()` method that calls
`releaseFramebuffers()` and also null the pointers in order to catch
invalid usage in ASSSERTs (for example: usage of
`SurfaceVk::mColorRenderTarget` after swapchain recreation but before
ANI processing).
`destroy()` is updated to also call `reset()`.
`releaseFramebuffers()` is only used in `TextureVk` class. In case of
`releaseImageViews()`, arrays are cleared, so there is no point calling
`releaseImageAndViews()`. In case of `refreshImageViews()`, render
targets may be reused, since all pointers remain valid.
`RenderbufferVk` and `WindowSurfaceVk` are using new
`releaseImageAndViews()` and updated `destroy()` methods.
Other changes:
- Replace clearing of RT arrays in `TextureVk::setImageHelper()` with
ASSERTs.
- Fix ASSERT in `TextureVk::releaseImageViews()`, but it seems that this
code path is impossible.
Bug: b/234769934
Change-Id: I431d25b81dd4dd343149c12e680e5c997aa18436
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5822575
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.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>
|
|
|
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>
|
|
|
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>
|
|
|
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>
|
|
|
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>
|
|
|
9298baa9
|
2023-10-20T10:26:00
|
|
Vulkan: Fix ImageTestES3.RenderToYUVAHB assertion
The bug here is that for YUV resolve, we always set mTransience to
YuvResolveTransient. And isImageTransient() returns true if mTransience
!= Default. And if image is transient, we will do unresolve, which is
incorrect here. For nullColorAttachmentWithExternalFormatResolve() case,
the image is actually not transient. This CL will only set transience to
YuvResolveTransient if we need to create a transient color attachment.
This CL looks at mImage->getExternalFormat() as the answer for
isYUVResolve instead of rely on transience.
Bug: b/223456677
Change-Id: I1bc176df22b0abc91d668a178e48d6b90eacbdd7
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4959194
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Chris Forbes <chrisforbes@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>
|
|
|
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>
|
|
|
233c128b
|
2023-01-17T19:21:58
|
|
Vulkan: Fix UBs when deleted attachment is used in a RenderPass.
Problem:
- "RenderbufferVk"/"TextureVk" with "mOwnsImage == false" used as
RenderPass attachment.
- "RenderbufferVk"/"TextureVk" deleted.
- Owning resource is destroyed ("EGLImage" and all siblings /
"EGLSurface").
- Crash (UB) may happen when ending RenderPass, flushing or executing
commands.
Fix adds tracking of "vk::ImageSourceID" value in
"vk::RenderPassAttachment" - IDs of objects, that originally provide
"vk::ImageHelper" images. This is necessary, because when using
EGLImage, there may be multiple "TextureVk" objects with same
"vk::ImageHelper", and need to call "finalizeImageLayout()" for the
correct attachment.
Bug: angleproject:8032
Test: angle_end2end_tests --gtest_filter=ImageTest*DeletedWhileInUse*
Test: angle_end2end_tests --gtest_filter=PbufferTest.UseAsFramebufferColorThenDestroy*
Change-Id: I50fdd9d6b6a9677adad2262373303b46de1dee4c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4296014
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
|
|
|
badfeecd
|
2022-08-10T14:38:43
|
|
Vulkan: Destroy fb1 should not affect fb2 with same attachments
If two FBOs has the same attachments. they will share the same
VkFramebuffers. Destroy one fbo should not cause trouble for the other
fbo.
Bug: chromium:1351170
Change-Id: I032da8cc12eb8556c3e325c8fd7a3de9974ae909
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3824302
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
723cc880
|
2022-06-10T17:55:54
|
|
Reland "Reland "Vulkan: Destroy DescriptorSet cache when it becomes invalid""
This is a reland of commit 551a26aeedbfd971d6199c8eddb433a4f4ff871c
Original change's description:
> Reland "Vulkan: Destroy DescriptorSet cache when it becomes invalid"
>
> This is a reland of commit 0779ccbcd427dcb00e53afa6385fb4e8e2377993 with
> the fix for angleproject:7466. When DescriptorPoolhelper gets
> release/destroyed, we ensure all sharedCacheKeys are destroyed.
>
> Original change's description:
> > Vulkan: Destroy DescriptorSet cache when it becomes invalid
> >
> > When a new texture descriptorSet is allocated, we store one reference of
> > the cache key in ProgramExecutableVk and all TextureVks that it
> > associated with. When any of the TextureVk is destroyed or its view
> > destroyed, we immediately erase the descriptorSet from the cache and
> > track GPU progress and free the descriptorSet when it's GPU completed.
> > That way we delete the dead descriptorSet that will for sure never been
> > reused ASAP so that its space is avialable for reuse.
> >
> > Bug: b/235523746
> > Change-Id: Ib1b9662a254eea5a3f410dc6d5d89fca6727a647
> > Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3700226
> > Reviewed-by: Lingfeng Yang <lfy@google.com>
> > Commit-Queue: Charlie Lao <cclao@google.com>
> > Reviewed-by: Ian Elliott <ianelliott@google.com>
> > Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
>
> Bug: b/235523746
> Bug: angleproject:7466
> Change-Id: I4413bec27ea0ca830010e2ca15036c2e667141c0
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3726964
> Reviewed-by: Ian Elliott <ianelliott@google.com>
> Commit-Queue: Charlie Lao <cclao@google.com>
> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Bug: b/235523746
Bug: angleproject:7466
Change-Id: I6b88b884841c5dbc625ee7e0c52c45af09dec199
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3741027
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Ian Elliott <ianelliott@google.com>
|
|
4b745c2b
|
2022-07-01T01:25:36
|
|
Revert "Reland "Vulkan: Destroy DescriptorSet cache when it becomes invalid""
This reverts commit 551a26aeedbfd971d6199c8eddb433a4f4ff871c.
Reason for revert: Blink test failures at: https://ci.chromium.org/ui/p/chromium/builders/ci/WebKit%20Linux%20MSAN/15546/overview
Original change's description:
> Reland "Vulkan: Destroy DescriptorSet cache when it becomes invalid"
>
> This is a reland of commit 0779ccbcd427dcb00e53afa6385fb4e8e2377993 with
> the fix for angleproject:7466. When DescriptorPoolhelper gets
> release/destroyed, we ensure all sharedCacheKeys are destroyed.
>
> Original change's description:
> > Vulkan: Destroy DescriptorSet cache when it becomes invalid
> >
> > When a new texture descriptorSet is allocated, we store one reference of
> > the cache key in ProgramExecutableVk and all TextureVks that it
> > associated with. When any of the TextureVk is destroyed or its view
> > destroyed, we immediately erase the descriptorSet from the cache and
> > track GPU progress and free the descriptorSet when it's GPU completed.
> > That way we delete the dead descriptorSet that will for sure never been
> > reused ASAP so that its space is avialable for reuse.
> >
> > Bug: b/235523746
> > Change-Id: Ib1b9662a254eea5a3f410dc6d5d89fca6727a647
> > Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3700226
> > Reviewed-by: Lingfeng Yang <lfy@google.com>
> > Commit-Queue: Charlie Lao <cclao@google.com>
> > Reviewed-by: Ian Elliott <ianelliott@google.com>
> > Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
>
> Bug: b/235523746
> Bug: angleproject:7466
> Change-Id: I4413bec27ea0ca830010e2ca15036c2e667141c0
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3726964
> Reviewed-by: Ian Elliott <ianelliott@google.com>
> Commit-Queue: Charlie Lao <cclao@google.com>
> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Bug: b/235523746
Bug: angleproject:7466
Change-Id: Icdde2752c462b7ebbb51d46fd35ce749b5caf377
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3739585
Reviewed-by: Ian Elliott <ianelliott@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Ian Elliott <ianelliott@google.com>
Commit-Queue: Ian Elliott <ianelliott@google.com>
|
|
|
551a26ae
|
2022-06-10T17:55:54
|
|
Reland "Vulkan: Destroy DescriptorSet cache when it becomes invalid"
This is a reland of commit 0779ccbcd427dcb00e53afa6385fb4e8e2377993 with
the fix for angleproject:7466. When DescriptorPoolhelper gets
release/destroyed, we ensure all sharedCacheKeys are destroyed.
Original change's description:
> Vulkan: Destroy DescriptorSet cache when it becomes invalid
>
> When a new texture descriptorSet is allocated, we store one reference of
> the cache key in ProgramExecutableVk and all TextureVks that it
> associated with. When any of the TextureVk is destroyed or its view
> destroyed, we immediately erase the descriptorSet from the cache and
> track GPU progress and free the descriptorSet when it's GPU completed.
> That way we delete the dead descriptorSet that will for sure never been
> reused ASAP so that its space is avialable for reuse.
>
> Bug: b/235523746
> Change-Id: Ib1b9662a254eea5a3f410dc6d5d89fca6727a647
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3700226
> Reviewed-by: Lingfeng Yang <lfy@google.com>
> Commit-Queue: Charlie Lao <cclao@google.com>
> Reviewed-by: Ian Elliott <ianelliott@google.com>
> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Bug: b/235523746
Bug: angleproject:7466
Change-Id: I4413bec27ea0ca830010e2ca15036c2e667141c0
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3726964
Reviewed-by: Ian Elliott <ianelliott@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
f8690429
|
2022-06-27T13:50:44
|
|
Revert "Vulkan: Destroy DescriptorSet cache when it becomes invalid"
This reverts commit 0779ccbcd427dcb00e53afa6385fb4e8e2377993.
Reason for revert: crashes in blink_web_tests on linux-rel
https://ci.chromium.org/ui/p/chromium/builders/try/linux-rel/1051045/overview
Original change's description:
> Vulkan: Destroy DescriptorSet cache when it becomes invalid
>
> When a new texture descriptorSet is allocated, we store one reference of
> the cache key in ProgramExecutableVk and all TextureVks that it
> associated with. When any of the TextureVk is destroyed or its view
> destroyed, we immediately erase the descriptorSet from the cache and
> track GPU progress and free the descriptorSet when it's GPU completed.
> That way we delete the dead descriptorSet that will for sure never been
> reused ASAP so that its space is avialable for reuse.
>
> Bug: b/235523746
> Change-Id: Ib1b9662a254eea5a3f410dc6d5d89fca6727a647
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3700226
> Reviewed-by: Lingfeng Yang <lfy@google.com>
> Commit-Queue: Charlie Lao <cclao@google.com>
> Reviewed-by: Ian Elliott <ianelliott@google.com>
> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Bug: b/235523746, angleproject:7466
Change-Id: I7e5067de2f2add08af1f9804cc2e952238b2e942
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3726097
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Yuly Novikov <ynovikov@chromium.org>
|
|
|
0779ccbc
|
2022-06-10T17:55:54
|
|
Vulkan: Destroy DescriptorSet cache when it becomes invalid
When a new texture descriptorSet is allocated, we store one reference of
the cache key in ProgramExecutableVk and all TextureVks that it
associated with. When any of the TextureVk is destroyed or its view
destroyed, we immediately erase the descriptorSet from the cache and
track GPU progress and free the descriptorSet when it's GPU completed.
That way we delete the dead descriptorSet that will for sure never been
reused ASAP so that its space is avialable for reuse.
Bug: b/235523746
Change-Id: Ib1b9662a254eea5a3f410dc6d5d89fca6727a647
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3700226
Reviewed-by: Lingfeng Yang <lfy@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Ian Elliott <ianelliott@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
72e457fe
|
2022-06-03T15:36:01
|
|
Vulkan: Promptly destroy cached framebuffer when it becomes invalid
When Texture gets respecified, the VkFramebuffer cache created out of it
becomes invalid and will never possibly get used. Before this CL, we
never clear such invalid framebuffer objects from the cache. This CL
keeps a reference to the cache key in each attachment and will
immediately destroy the cached VkFramebuffer object when one of the
attachment has become invalid.
Bug: b/234769934
Change-Id: Ib01f6dffe9211084b1ada340081daf905e3f1bef
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3682164
Reviewed-by: Ian Elliott <ianelliott@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
20e7bbb7
|
2022-03-18T17:03:18
|
|
Vulkan: Fix invalidate of attachments with emulated format
Some image formats may be emulated such that the emulated format has
more channels than the original. ANGLE clears the image once so that
these extra channels contain valid values, and carefully ensures they
are never modified.
For swapchain images with such formats, as they are automatically
invalidated at the end of the frame, a workaroud was added to make sure
they are re-cleared in the beginning of the next frame. This however
doesn't fix the issue of glInvalidateFramebuffer resulting in the
contents of attachments with such formats to be discarded (even if the
following render pass clears it, the contents are invalid in between).
This change instead makes sure invalidate of images with emulated
formats that have extra channels are handled appropriately:
- On IMR hardware, the invalidate is dropped altogether as it provides
little to no benefit.
- On TBR hardware, a clear is automatically staged on the invalidated
image.
The latter replaces the workaround that was added to make the following
render pass use loadOp=CLEAR, by adding a clear that's respected
regardless of what the future usage is.
This change also paves the way for a future change where the invalidate
of color attachments is tracked in render passes similarly to how
depth/stencil currently is. With this change, the image is no longer in
an inconsistent state where its contents are considered invalid, even
though some channels are meant to remain valid.
Bug: angleproject:6860
Change-Id: Iec5b4854dfbe3a0bf93cd5aa82c19fe116065744
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3536389
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
e8ee847d
|
2022-02-23T12:25:39
|
|
Vulkan: Add UpdateDescriptorSetsBuilder.
This helper class encapsulates the vkUpdateDescriptorSets caching.
As part of the refactor, we switch passing a ContextVk to passing
a vk::Context with some mutable variables. This helps encapsulate
ContextVk. Since we use the perf counters in many places, this CL
moves the perf counters to vk::Context, so we can access them
everywhere.
Refactoring change only.
Bug: angleproject:6776
Change-Id: Id529962b2f425bece6f9b3bd0cd1698c692e58cb
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3484980
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
|
1cef917c
|
2022-03-02T23:50:11
|
|
Reland "Remove ImageViewHelper from ResourceUseList"
This is a reland of 126e967de3978f0dc4f6cf0fa3f9749366ea39ba
Original change's description:
> Remove ImageViewHelper from ResourceUseList
>
> Instead of keeping a dedicated SharedResourceUse mUse for
> ImageViewHelper, let ImageViewHelper take ImageHelper.mUse
> for lifetime tracking. ImageViewHelper no longer needs to
> add its' own mUse in the ResourceUseList through retain()
> calls, and this should cut the ResourceUseList size by
> almost half. For instance, in the trace aztec_ruins,
> the maximum ResourceUseList size before the change is 3643,
> and the maximum ResourceUseList size after the change is 1694.
> Since ImageViewHelper no longer needs to keep SharedResourceUse
> mUse as a class memberWe can remove the inheritance from
> Resource class, and make ImageViewHelper simply a NonCopyable class.
> Bug: angleproject:6717
> Change-Id: I460e83f5f3c1d6ef9722b9f3c9a5ba9552563cb9
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3449450
> Reviewed-by: Charlie Lao <cclao@google.com>
> Reviewed-by: Jamie Madill <jmadill@chromium.org>
> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
> Commit-Queue: Yuxin Hu <yuxinhu@google.com>
Bug: angleproject:6717
Change-Id: I3aa9785d7dcdc8db82847f1586f8cd7d5c838d7c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3501194
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Yuxin Hu <yuxinhu@google.com>
|
|
5749ec7d
|
2022-03-01T02:14:42
|
|
Revert "Vulkan: Move mid-RP color clear to loadOp if content undefined"
This reverts commit cfe5a1735a934cc83133bb6c69d19aa27278a270.
Reason for revert: https://bugs.chromium.org/p/angleproject/issues/detail?id=5048#c7
@timvp That change just caused a regression in my project. I clear the color + depth buffer before drawing, but initially draw only to the depth buffer. It seems that it decided to ignore the color buffer clear as a result of that.
Original change's description:
> Vulkan: Move mid-RP color clear to loadOp if content undefined
>
> Instead of using vkCmdClearAttachments, if the color attachment has not
> been written to, modify the loadOp of the currently open renderpass to
> CLEAR.
>
> Bug: angleproject:5048
> Test: VulkanPerformanceCounterTest.MidRenderpassClear
> Change-Id: Ida47e6ac7d0f29e2c49bdf2e74c1d876a5d7c223
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3381912
> Reviewed-by: Jamie Madill <jmadill@chromium.org>
> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
> Commit-Queue: Tim Van Patten <timvp@google.com>
Bug: angleproject:5048
Change-Id: Iec5c73632429a80f955f7d659cf670f9cbb6c9b7
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3496662
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Tim Van Patten <timvp@google.com>
|
|
|
cfe5a173
|
2022-01-11T19:26:42
|
|
Vulkan: Move mid-RP color clear to loadOp if content undefined
Instead of using vkCmdClearAttachments, if the color attachment has not
been written to, modify the loadOp of the currently open renderpass to
CLEAR.
Bug: angleproject:5048
Test: VulkanPerformanceCounterTest.MidRenderpassClear
Change-Id: Ida47e6ac7d0f29e2c49bdf2e74c1d876a5d7c223
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3381912
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Tim Van Patten <timvp@google.com>
|
|
|
8390196a
|
2022-02-26T02:36:22
|
|
Revert "Remove ImageViewHelper from ResourceUseList"
This reverts commit 126e967de3978f0dc4f6cf0fa3f9749366ea39ba.
Reason for revert: Hits an ASSERT about too much garbage being accumulated. anglebug.com/7063
Original change's description:
> Remove ImageViewHelper from ResourceUseList
>
> Instead of keeping a dedicated SharedResourceUse mUse for
> ImageViewHelper, let ImageViewHelper take ImageHelper.mUse
> for lifetime tracking. ImageViewHelper no longer needs to
> add its' own mUse in the ResourceUseList through retain()
> calls, and this should cut the ResourceUseList size by
> almost half. For instance, in the trace aztec_ruins,
> the maximum ResourceUseList size before the change is 3643,
> and the maximum ResourceUseList size after the change is 1694.
> Since ImageViewHelper no longer needs to keep SharedResourceUse
> mUse as a class memberWe can remove the inheritance from
> Resource class, and make ImageViewHelper simply a NonCopyable class.
>
> Bug: angleproject:6717
> Change-Id: I460e83f5f3c1d6ef9722b9f3c9a5ba9552563cb9
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3449450
> Reviewed-by: Charlie Lao <cclao@google.com>
> Reviewed-by: Jamie Madill <jmadill@chromium.org>
> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
> Commit-Queue: Yuxin Hu <yuxinhu@google.com>
Bug: angleproject:6717
Change-Id: Iea3d40458e2cc5be6ab0257ba6df8b82a4eeecda
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3491345
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
126e967d
|
2022-02-09T01:46:25
|
|
Remove ImageViewHelper from ResourceUseList
Instead of keeping a dedicated SharedResourceUse mUse for
ImageViewHelper, let ImageViewHelper take ImageHelper.mUse
for lifetime tracking. ImageViewHelper no longer needs to
add its' own mUse in the ResourceUseList through retain()
calls, and this should cut the ResourceUseList size by
almost half. For instance, in the trace aztec_ruins,
the maximum ResourceUseList size before the change is 3643,
and the maximum ResourceUseList size after the change is 1694.
Since ImageViewHelper no longer needs to keep SharedResourceUse
mUse as a class memberWe can remove the inheritance from
Resource class, and make ImageViewHelper simply a NonCopyable class.
Bug: angleproject:6717
Change-Id: I460e83f5f3c1d6ef9722b9f3c9a5ba9552563cb9
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3449450
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Yuxin Hu <yuxinhu@google.com>
|
|
|
8ea87a67
|
2021-08-17T18:46:36
|
|
Vulkan: Avoid texture format fallback when possible
Some texture formats are not renderable on some hardware. For example,
R4G4B4A4 are not renderable on nvidia and not blendable on ARM.
R5G5B5A1 are also not blendable on nvidia. Right now when we generate
format table, we are being most conservative, picking an actual format
that is always renderable and blendable. This means when R4G4B4A4 is
used on one of these GPUs, we are always falling back to R8G8B8A8
regardless if the texture is actually being used as color attachment or
not. This CL adds a actualRenderableImageFormatID field in vk::Format.
Initially we will pick actualImageFormatID which only ensures texture
sample capability. If later on the texture is being attached to FBO,
then we will switch to actualRenderableImageFormatID and do data copy if
necessary. This way we save memory and reduce texture bandwidth for most
usage of these textures. For renderBuffer and surfaces and EGLImages, we
always pick the renderable textures.
Bug: b/196456356
Change-Id: I02eec3365c2a317b0d1bad6dbdc3e741114c5bba
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3104514
Reviewed-by: Ian Elliott <ianelliott@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
e98539f0
|
2021-08-17T14:42:26
|
|
Vulkan: Add ImageHelper::getIntendedFormatID()
This adds helper API to return intendedFormat directly from ImageHelper
object instead of vk::Format, to make API symmetrical. It is also
necessary. It is also needed in some places where we no longer have
access to vk::Format any more due to refactoring.
Bug: b/196456356
Change-Id: Ie0502793623138ded28c3f01320c57ffea2d93df
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3101925
Reviewed-by: Ian Elliott <ianelliott@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
cf24931a
|
2021-08-17T10:48:23
|
|
Vulkan: Add ImageHelper::getActualFormat()
This is preparation for future CLs. In the future vk::Format may not
tell you what actual format is. This CL adds a new method of
ImageHelper::getActualFormatID() and ImageHelper::getActualFormat() so
that we can use these two APIs and avoid using vk::Format, thus reduce
reliance on vk::Format.
Bug: b/196456356
Change-Id: Ic50e664e033feb5e066f40269c33cffe96024172
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3100319
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Ian Elliott <ianelliott@google.com>
|
|
|
da437f26
|
2021-03-08T19:08:14
|
|
Vulkan: Defer color image layout changes at endRenderPass time
Right now color render target's image's layout change are done at
beginRenderPass time. The problem is that the layout also depends on
whether texture is also being used as a sampler or not. That information
is not known when renderpass starts. We did some special treatment for
depth stencil attachment so that its layout determination is deferred
until endRenderPass time. This CL expands that same mechanism to color
attachment as well. Right now the color attachment will still pick the
same ImageLayout::ColorAttachment layout since the logic to detect it is
also used for texture sampling is not there yet.
Bug: b/175584609
Change-Id: Id7486174d475f894461578b31d0d40fdd90e808a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2744121
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
81dcf078
|
2021-03-08T11:21:31
|
|
Reland "Vulkan: Support EXT_sRGB_write_control"
This is a reland of 6073af536cf627742696823edc82c9b0a481a8bc
with 2 changes -
1. Don't enable the extension even in nonConformant mode
2. Don't enable VK_KHR_image_format_list for swiftshader
Original change's description:
> Vulkan: Support EXT_sRGB_write_control
>
> Implement support for EXT_sRGB_write_control. This extension
> requires VK_KHR_image_format_list to be supported.
>
> The spec requires this functionality to work with glBlitFramebuffer
> as well but support for that will be added in a follow up change.
> As such, this extension is only exposed in non-conformant mode.
>
> Bug: angleproject:5075
> Tests: SRGBFramebufferTest.*Vulkan*
> Change-Id: I59b38f6cd810a3d0d67ec29f4f19c25f65f70862
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2617243
> Commit-Queue: Mohan Maiya <m.maiya@samsung.com>
> Reviewed-by: Jamie Madill <jmadill@chromium.org>
> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Bug: angleproject:5075
Change-Id: I8e149d196a39c3c4769bfa8690792f3c53831299
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2762647
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Mohan Maiya <m.maiya@samsung.com>
|
|
b27740f3
|
2021-03-09T16:15:15
|
|
Revert "Vulkan: Support EXT_sRGB_write_control"
This reverts commit 6073af536cf627742696823edc82c9b0a481a8bc.
Reason for revert: crbug.com/1186140
Original change's description:
> Vulkan: Support EXT_sRGB_write_control
>
> Implement support for EXT_sRGB_write_control. This extension
> requires VK_KHR_image_format_list to be supported.
>
> The spec requires this functionality to work with glBlitFramebuffer
> as well but support for that will be added in a follow up change.
> As such, this extension is only exposed in non-conformant mode.
>
> Bug: angleproject:5075
> Tests: SRGBFramebufferTest.*Vulkan*
> Change-Id: I59b38f6cd810a3d0d67ec29f4f19c25f65f70862
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2617243
> Commit-Queue: Mohan Maiya <m.maiya@samsung.com>
> Reviewed-by: Jamie Madill <jmadill@chromium.org>
> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Bug: angleproject:5075,chromium:1186140
Change-Id: Ib0d4d60fe7434fb950f99db2c210aab9af7d2d0e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2743663
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Peng Huang <penghuang@chromium.org>
|
|
|
6073af53
|
2021-03-08T11:21:31
|
|
Vulkan: Support EXT_sRGB_write_control
Implement support for EXT_sRGB_write_control. This extension
requires VK_KHR_image_format_list to be supported.
The spec requires this functionality to work with glBlitFramebuffer
as well but support for that will be added in a follow up change.
As such, this extension is only exposed in non-conformant mode.
Bug: angleproject:5075
Tests: SRGBFramebufferTest.*Vulkan*
Change-Id: I59b38f6cd810a3d0d67ec29f4f19c25f65f70862
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2617243
Commit-Queue: Mohan Maiya <m.maiya@samsung.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
60b03e62
|
2021-02-16T14:31:19
|
|
Create getRotatedExtents() and related methods
Created:
- WindowsSurfaceVk::getRotatedWidth()
- WindowsSurfaceVk::getRotatedHeight()
- RenderTarget::getRotatedExtents()
- ImageHelper::getRotatedExtents()
- ImageHelper::getRotatedLevelExtents2D()
Note: The FramebufferVk class doesn't use any of these methods
Bug: b/175793022
Change-Id: I64395688bfdb172d32853763743fc5f266a6b792
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2686102
Commit-Queue: Ian Elliott <ianelliott@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
|
|
|
56330564
|
2020-12-10T00:46:04
|
|
Vulkan: Support layered framebuffers
This feature is introduced by geometry shaders, where all the layers of
a texture can be attached to a framebuffer. The geometry shader would
use gl_Layer to decide which layer the primitive should be rendered to.
Bug: angleproject:3571
Change-Id: Ib2ae8e227b226295f9e2f62f6b230839070bc95c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2582711
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
|
|
|
86d7e4d8
|
2020-11-10T15:55:34
|
|
Vulkan: Support texture buffers
Texture buffers are placed in the same descriptor set with the rest of
the textures. However, the different code paths that handle textures
have special cases for texture buffers as they create a different
descriptor type (texel buffer instead of combined image sampler). Image
view serials are used to track the buffer view serials as well so the
texture descriptor cache can handle texture buffers as well.
This CL is missing storage texel buffer support.
Bug: angleproject:3573
Change-Id: Iff80ca22ff9b9957a0c9a3c7aaada1fa54b24ec8
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2532653
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
|
|
|
68bd685a
|
2020-10-10T22:58:41
|
|
Reland: "4 Vulkan content defined CLs."
Reland "Vulkan: Avoid content restore by detecting no-op stencil"
This relands commit 243d0f899e443cd931c78aba7489382dff79edbb.
Reland "Vulkan: Restore at the end of RP if write-after-invalidate"
This relands commit e5d52ac3b9a00656acdd912ee8cd62dd14784075.
Reland "Vulkan: Invalidate/restore depth/stencil separately."
This relands commit 61fa0878964a796f6d3b3c13bc3a3849403ecdbd.
Reland "Vulkan: Move content-defined tracking to ImageHelper"
This relands commit 2392e6b34c0ddfbfd7b4c3cb67323ba463e11a57.
Reason for revert: Caused crashes in Fuchsia x64 and on ARM.
Reland fixes content defined for external images.
Original CL message:
Content-defined tracking was done in render targets prior to this
change. This had multiple drawbacks:
- When a framebuffer attachment is changed (including the first time
it's set), it's unknown whether the contents of the attachment is
defined.
- Invalidate takes effect at the end of render pass, at which point the
render target objects may be gone. Attachment ImageHelpers are
however correctly tracked.
This change moves content-defined tracking to the ImageHelper itself,
and tracks it per subresource. ImageHelper::onWrite() now receives the
subresource that is being written, and marks it as having defined
content.
A future optimization can make use of this change to
ImageHelper::onWrite to track "dirty" subresources. This can lead to
the removal of unnecessary barriers when same-kind writes are done on
different subresources of the image. See http://anglebug.com/3347#c15
Bug: b/167275320
Bug: angleproject:4836
Bug: angleproject:5159
Change-Id: If5c1ae7152657fd7c94db7d55bea4fb9ddf835ba
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2464825
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
d6b1c17b
|
2020-10-10T14:29:15
|
|
Revert 4 Vulkan content defined CLs.
Revert "Vulkan: Avoid content restore by detecting no-op stencil"
This reverts commit 243d0f899e443cd931c78aba7489382dff79edbb.
Revert "Vulkan: Restore at the end of RP if write-after-invalidate"
This reverts commit e5d52ac3b9a00656acdd912ee8cd62dd14784075.
Revert "Vulkan: Invalidate/restore depth/stencil separately."
This reverts commit 61fa0878964a796f6d3b3c13bc3a3849403ecdbd.
Revert "Vulkan: Move content-defined tracking to ImageHelper"
This reverts commit 2392e6b34c0ddfbfd7b4c3cb67323ba463e11a57.
Causes crashes in Fuchsia x64 and on ARM.
Original CL message:
Content-defined tracking was done in render targets prior to this
change. This had multiple drawbacks:
- When a framebuffer attachment is changed (including the first time
it's set), it's unknown whether the contents of the attachment is
defined.
- Invalidate takes effect at the end of render pass, at which point the
render target objects may be gone. Attachment ImageHelpers are
however correctly tracked.
This change moves content-defined tracking to the ImageHelper itself,
and tracks it per subresource. ImageHelper::onWrite() now receives the
subresource that is being written, and marks it as having defined
content.
A future optimization can make use of this change to
ImageHelper::onWrite to track "dirty" subresources. This can lead to
the removal of unnecessary barriers when same-kind writes are done on
different subresources of the image. See http://anglebug.com/3347#c15
Bug: b/167275320
Bug: angleproject:4836
Bug: angleproject:5159
Change-Id: I93d9dfe973caa7ce70aefa46b5b7d04a8637efb3
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2464822
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
|
61fa0878
|
2020-10-08T11:35:48
|
|
Vulkan: Invalidate/restore depth/stencil separately.
Depth/stencil content defined is already tracked separately in the
ImageHelper. This change exposes this tracking from RenderTargetVk.
Bug: b/167275320
Bug: angleproject:4836
Change-Id: Ie6520e7a4ab557eb233c60c6ab0d4a8f8f098bf6
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2462039
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Ian Elliott <ianelliott@google.com>
|
|
|
2392e6b3
|
2020-10-07T23:59:43
|
|
Vulkan: Move content-defined tracking to ImageHelper
Content-defined tracking was done in render targets prior to this
change. This had multiple drawbacks:
- When a framebuffer attachment is changed (including the first time
it's set), it's unknown whether the contents of the attachment is
defined.
- Invalidate takes effect at the end of render pass, at which point the
render target objects may be gone. Attachment ImageHelpers are
however correctly tracked.
This change moves content-defined tracking to the ImageHelper itself,
and tracks it per subresource. ImageHelper::onWrite() now receives the
subresource that is being written, and marks it as having defined
content.
A future optimization can make use of this change to
ImageHelper::onWrite to track "dirty" subresources. This can lead to
the removal of unnecessary barriers when same-kind writes are done on
different subresources of the image. See http://anglebug.com/3347#c15
Bug: b/167275320
Bug: angleproject:4836
Change-Id: Iabd1dace4eae9eb379453a9eb7ec6eafc9db1aef
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2462036
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Ian Elliott <ianelliott@google.com>
|
|
|
77e3d0ae
|
2020-09-25T14:12:04
|
|
Vulkan: Defer the depthStencil buffer layout change to endRenderPass
Depth stencil layout may change while we build the render pass,
depending on the read/write access been made. Right now we are always
inserting a layout change barrier at the start of render pass. Later on
when the read/write property changes, we insert another layout change
barrier. Similarly, we maintain the attachmentOps and
RenderPassDesc::mPackedColorAttachmentRangeAndDSAccess as we changes
read/write access. This makes code quite commplicated. This CL moves
mReadOnlyDepthStencilMode from FramebufferVK to CommandBufferHelper
object and we only maintain that boolean while we updating the
read/write access. Then at the end of render pass or when depthStencil
image is deleted, we update attachmentOps and mRenderPassDesc and layout
transition all at once and only done once. This simplifies the read only
depth stencil mode implementation a lot.
Bug: b/168953278
Change-Id: Ie263b4526c82a9858e5d1f141ea58f499187a3ca
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2432075
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
a76b6836
|
2020-09-17T22:40:42
|
|
Vulkan: Support MSRTT depth/stencil resolve
VK_KHR_depth_stencil_resolve is used by this change to resolve
depth/stencil multisampled-render-to-texture renderbuffers.
This extension is not widely supported yet. If it's not present, the
depth/stencil resolve operation is silently ignored and the renderbuffer
acts as a normal multisampled one. This is not correct, but our primary
user (Chrome), and most applications don't care for the resolved
depth/stencil data. In fact, it's recommended for the depth/stencil
attachment to be invalidated after rendering.
Exposing EXT_multisampled_render_to_texture even in the absence of
depth/stencil resolve allows the majority of the applications to still
take advantage of MSRTT color attachments.
Bug: angleproject:4836
Change-Id: I6ba4187344a0c9330d2c77bdc5e2c6fc5483c299
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2417645
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
|
|
|
edc0d2ee
|
2020-09-15T16:02:05
|
|
Vulkan: Disallow loadOp=LOAD for MSRTT depth/stencil textures
EXT_multisampled_render_buffer2 specifies that depth/stencil textures
are expected to be in a perpetual state of invalidated, except during
rendering. This change makes sure that they never use loadOp=LOAD.
Additionally fixes a bug where clears applied to MSRTT depth/stencil
textures didn't take effect because they were applied to the
multisampled image (since the resolved image was not given to the render
target).
Bug: angleproject:4836
Bug: angleproject:5063
Change-Id: I4506f4de415dca6c222111a1ae62017d2fb1e2b1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2412848
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
|
|
|
a0d048a4
|
2020-08-27T12:03:02
|
|
Vulkan: Fool-proof usage of GL and VK level indices
Using boxed types, this change allows the compiler to catch errors when
a level index in one space (e.g. GL) is mistakenly used in another space
(e.g. VK).
This change uncovered a number of bugs due to such mistakes which are
fixed.
Mistakes are still possible when the index is explicitly extracted, for
example to be given to a Vulkan command, or when it's created, for
example when retrieved from gl::ImageIndex::getLevelIndex. Future work
can include using gl::LevelIndex in gl::ImageIndex directly to alleviate
the latter at least.
Bug: angleproject:4880
Change-Id: I6427c68c3bc096f771402f51c8554d8171758aa9
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2380232
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
296d3bfd
|
2020-08-21T10:38:32
|
|
Vulkan: do not end render pass when invalidating
Initially, FramebufferVk::invalidateImpl() was very conservative and
always ended a render pass (if the framebuffer is part of the current
render pass). This adversely affects PUBG Mobile, which invalidates
the depth buffer every frame, causing the render pass to be split.
Test: PUBG MOBILE on Android
Test: angle_white_box_tests --gtest_filter=VulkanPerformanceCounterTest.InvalidatingAndUsingDepthDoesNotBreakRenderPass/*
Test: angle_deqp_gles3_tests --gtest_filter=dEQP.GLES3/functional_fbo_invalidate_* --use-angle=vulkan
Bug: b/163854287
Change-Id: I343dee1db3ebaf039ff92557f9ef25b24bcdcc93
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2352627
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Ian Elliott <ianelliott@google.com>
|
|
|
e689d316
|
2020-08-14T22:51:03
|
|
Vulkan: Don't end RenderPass on DS feedback loops.
Instead of always switching the Framebuffer to mask out depth/stencil
loops we now switch the RenderPass to a "read-only" depth/stencil mode.
Reduces the RenderPass count in Manhattan from 18->15. There are still
a couple extra RenderPasses inserted that we can get rid. We can merge
a few RenderPasses by retroactively changing a started RenderPass to
"read-only" when there are no prior recorded depth writes or clears.
Also adds a test to count the number of RenderPasses ANGLE generates in
DS feedback loop situaions.
Bug: angleproject:4959
Change-Id: I1855a45959655fc27ccd47a3469c1c672fc8fd9e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2357973
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Tim Van Patten <timvp@google.com>
|
|
|
dff47d5f
|
2020-07-14T19:10:12
|
|
Vulkan: Optimize MSAA using subpass resolve attachments
If a user is performing a blit to resolve a multisample color buffer
into a single attachment, ANGLE can use subpass resolve attachments to
resolve directly into the destination buffer as part of the render pass.
This allows the data to remain in tiler memory and reduce the extra
bandwidth required to write the multisampled data back to perform the
copy.
This work also requires restoring/reopening a render pass if it has been
finished already, assuming the finished render pass was started and for
the framebuffer that is the source for the blit command. Other objects
that were created when the render pass was started need to be updated as
well, such as the source FramebufferVk's resolve attachment, the
CommandBufferHelper's vk::Framebuffer and vk::RenderPassDesc, etc.
While this is better than performing vkCmdResolveImage(), there is still
another major part of optimizing MSAA using resolve attachments not
implemented here: discarding the multisampled image rather than writing
it to GMEM, which requires the user to invalidate the read FBO after the
blit.
This CL was verified with AGI to make sure there are no explicit blits
to resolve the multiple sampled image.
Bug: b/159903491
Test: FramebufferTest_ES31.*Blit*
Test: VulkanPerformanceCounterTest_ES31.MultisampleResolveWithBlit
Change-Id: I320a26088d8f614a295e7feec275d71310391806
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2298663
Commit-Queue: Tim Van Patten <timvp@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
5921a040
|
2020-08-06T17:39:56
|
|
Vulkan: Refactor image dependency commands.
Uses commands similar to the Buffer APIs. Also updates docs.
Bug: angleproject:4911
Change-Id: I1f2ec9bdd1d725d4ec3d6601e63bcb0c045e2121
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2342287
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
adc250c3
|
2020-07-31T21:11:05
|
|
Vulkan: Refactor ImageViewHelper serials.
Instead of storing a dictionary of serials to specific image views
we now store a single 32-bit serial combined with subresource info.
The serials combined with a subresource info (level/layer) gives a
unique identifier for each ImageView in the ImageViewHelper for the
descriptor set cache and the Framebuffer cache.
Also moves ImageView serial allocation to initialization and release.
This means we no longer need to use "getAssign" methods and instead
we use a few init methods to ensure the serials stay allocated.
Bug: angleproject:4911
Change-Id: Ia6af76ae16b3ff5d4a83974bde05cc704064b079
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2333395
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
|
|
|
22e6fc03
|
2020-07-31T15:58:28
|
|
Vulkan: Move Resource Serial gen into Renderer.
Putting Serial allocation in the Renderer allows the Helper
classes to manage allocating its own Serial. The init functions for
ImageViewHelper only have access to a vk::Context/RendererVk, not a
ContextVk. This will be updated in a future CL.
Re-uses the Serial Type X-Macro to do more code generation.
Serial allocation now uses an atomic because of its now Renderer
shared location.
Bug: angleproject:4911
Change-Id: I2d5d3d0bbf613d5468de795a700f66164291bc79
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2332884
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
dcc56215
|
2020-07-19T01:12:09
|
|
Vulkan: Implement GL_EXT_multisampled_render_to_texture
This change allows the use of resolve attachments in the Vulkan backend.
GL_EXT_multisampled_render_to_texture is implemented using this feature.
The infrastructure for specifying resolve attachments is designed with
eventual support for GL_EXT_multisampled_render_to_texture2 in mind as
well as optimizations to glBlitFramebuffer() and multisampled
backbuffers.
Proper support for glRenderbufferStorageMultisampledEXT is still missing
from this change. All tests use this for the depth/stencil attachment
and don't read back the data. Currently, the depth/stencil attachment
is created as a normal multisampled image.
Bug: angleproject:4836
Change-Id: I110a7f63312ae61a657b6094adf7d97c92bd5843
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2304170
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
|
|
|
68791f89
|
2020-07-20T17:42:23
|
|
Vulkan: Fix sub invalidate marking render targets undefined
When glInvalidateSubFramebuffer is called, the framebuffer is only
partially invalidated. FramebufferVk::invalidateImpl was nevertheless
marking the render targets as undefined, which would lead the subsequent
render pass have loadOp=DONT_CARE. This is not correct, as the rest of
the framebuffer is expected to still be valid.
Bug: angleproject:4859
Change-Id: I2e64baa32b1fc84beb8008411b564cd7619af962
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2309111
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
|
|
|
248119b3
|
2020-07-20T16:05:45
|
|
Vulkan: Fix render target's tracking of content defined
Imagine the following scenario:
1. Clear draw framebuffer
2. Invalidate draw framebuffer
3. Update texture attached to draw framebuffer
4. Draw again into draw framebuffer
Step 3 could be a number of things, such as glCopyTex[Sub]Image,
glBlitFramebuffer, glTex[Sub]Image2D, glGenerateMipmap etc.
In the above scenario, at step 2, the framebuffer's render target
remembers it being invalidated (mContentDefined = false). This is used
to set the loadOp of the next render pass to DONT_CARE.
However, mContentDefined was implemented for a very specific
optimization regarding the swapchain's depth buffer. The reuse of this
variable for glInvalidateFramebuffer was erroneous as this variable
didn't track whether the contents are defined for the general case.
With this change, mContentDefined is set to true during
FramebufferVk::syncState for each render target whose contents are
marked dirty.
This change additionally makes glBlitFramebuffer signal the contents of
the blit targets as dirty, as well as textures that are used as storage
images.
Bug: angleproject:4859
Change-Id: I68c829f75ff4a3d03bb293ec72c609384983026d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2309110
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
d9818fd6
|
2020-07-19T00:37:21
|
|
Vulkan: Improve RenderTargetVk's getImage interface
Prior to this change, RenderTargetVk had getImage() and
getImageForWrite(). This change introduces getImageForCopy() and
renames getImage() to getImageForRenderPass().
Currently, all three functions do the same thing. However, with
upcoming changes the semantics will be different:
- getImageForRenderPass(): This is the image used as the non-resolve
attachment. When resolve attachments are introduced, there will be a
corresponding getResolveImageForRenderPass().
- getImageForCopy(): When GL_EXT_multisampled_render_to_texture is
implemented, this will return the image that owns the data.
- getImageForWrite(): Similar to getImageForCopy(), but should set
mContentDefined. This is currently missing, and is a bug that will be
resolved in a follow up.
This split change gets the mechanical rename out of the way to make
future changes simpler.
Bug: angleproject:4836
Bug: angleproject:4859
Change-Id: I5f7657cc049c0e1772a7c510e74289e685ba93c3
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2306516
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
|
|
9a9ef0ae
|
2020-07-15T16:50:32
|
|
Vulkan: Fix RTs attached to textures with non-0 mip
Cleared confusion between GL level indices and VK level indices by
adding the corresponding suffix to variables and function arguments. A
handful of places that sent one index and expected the other are fixed.
A couple more places needed this adjustment that were missed in the
first CL. Also included a test to provoke those situations.
The conversion between the two is given by:
levelIndexGL = levelIndexVk + baseLevel;
Bug: angleproject:4695
Change-Id: I3b8e5699abee1b011e52b666e6e245f44cb8ad6f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2302549
Reviewed-by: Cody Northrop <cnorthrop@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Courtney Goeltzenleuchter <courtneygo@google.com>
|
|
|
67980f13
|
2020-07-08T08:51:02
|
|
Vulkan: add Buffer/Texture/ImageViewSerial class
In a few places we need a unique ID to represent that object and use
that to compute hash key. Right now we are using Serial for that purpose
but it creates confusion with QueueSerial which we are using Serial to
track GPU progress. This CL changes these usage of Serial to
TextureSerial, SamplerSerial, ImageViewSerial type so that compiler can
perform type checking. It also adds BufferSerial in preparation for next
CL.
Bug: b/159457348
Change-Id: I8e2da69c2029e4ddbcf163981ae46f85e19f751b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2287426
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
34ca1ac7
|
2020-06-16T12:05:12
|
|
Vulkan: Fix FramebufferVk cache
Migrate Serial from Image to ImageView.
Imageviews are what are utimately used in FramebufferVk, so move
the Serials into the ImageViewHelper class. Since that class also
knows the level/layer of the imageView, we can revert to using a
single Serial per ImageView instead of the AttachmentSerial that
included the layer and level.
ImageViewHelper caches Serials per layer/level combo.
Bug: angleproject:4651
Change-Id: I3741d7d03523eada84295cb712c1cc1e6e3c3867
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2248203
Commit-Queue: Tobin Ehlis <tobine@google.com>
Reviewed-by: Mohan Maiya <m.maiya@samsung.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
e7ae237e
|
2020-06-12T23:52:09
|
|
Vulkan: ANGLE_copy_texture_3d support
Bug: angleproject:4748
Test: CopyTexImage*Vulkan:Texture3DCopy*Vulkan:Texture2DArrayCopy*Vulkan
Test: dEQP.KHR_GLES3/copy_tex_image_conversions_required_cubemap*cubemap*
Change-Id: Ifdc3d455ca8c9e732d0adf4afa9e2809d780ae18
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2246320
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
13816d2d
|
2020-06-16T14:27:04
|
|
Move vulkan_headers/entry_points to common/vulkan
This will allow us to move common headers, such as extension headers, to
common/vulkan.
Bug: b/159027603
Bug: b/154620295
Change-Id: I1ff73dc5b7ee8f7dfb3ac0c5f30bd4b3a8183aeb
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2248205
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Antonio Maiorano <amaiorano@google.com>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
d657e1d7
|
2020-04-24T13:13:18
|
|
Vulkan: Defer framebuffer clears.
This works by storing the deferred clears in the ImageHelper's staging
buffers. We apply the deferred clears onto the RenderPass right before
we begin to draw. Storing the clears in the ImageHelper solves problems
where we clear GL Textures in a Framebuffer and then unbind the
Textures and sample from them. Or do other commands like CopyTexImage.
Note that because the staging buffer clears only handle full-image
clears we need to immediately apply some scissored clears where before
we would use the RP. This should be a pretty rare occurrence and it is
possible to optimize that in the future.
Reduces the RenderPass count in the Manhattan "frame 10" trace from max
22 to max 20. May improve perf slightly on Android or may have effects
too small to measure. Should not regress performance.
Bug: angleproject:4517
Change-Id: I02150d531022afb903f1058f070937ec6337bd88
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2142711
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
3cb9c4be
|
2020-03-13T13:56:47
|
|
Statically link vulkan-loader on Mac
Disable angle_shared_libvulkan on Mac since we are the only client.
Re-add codepaths to support this.
Bug: angleproject:4477
Change-Id: Ie128c83adaae741636541bbfd6105d160d874a8d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2102954
Commit-Queue: Jonah Ryan-Davis <jonahr@google.com>
Reviewed-by: Tobin Ehlis <tobine@google.com>
|
|
|
03c18fbd
|
2020-04-13T16:01:01
|
|
Vulkan: Skip load if depth/stencil value are undefined
EGL1.5 spec says depth/stencil data are undefined after swap. This CL
will track the depth/stencil data and mark it as undefined and skip the
load if it is undefined.
Bug: b/153885625
Change-Id: Ifb3d88d442da547fa78c1eae091cbae08a20d0ab
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2148179
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
a741abb9
|
2020-02-21T16:37:37
|
|
Vulkan: Rename CommandGraphResource to Resource.
Also renames the h and cpp files to ResourceVk (to keep distinct from
other resource.h/cpp files) and renames 'onResourceAccess' to 'retain'.
Cleans up a few remaining mentions of the command graph in comments.
Bug: angleproject:4029
Change-Id: Ifc8e880c8cea3fc48a4aec4730191c88aa35a076
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2065920
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
|
|
|
c58458e6
|
2020-02-19T14:51:41
|
|
Vulkan: Remove CommandGraph code.
Also updates relevant comments to no longer refer to a graph.
Bug: angleproject:4029
Change-Id: Ic29716e9ae4926870f902947d49d8fee7af98662
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2057804
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
|
|
|
cf2ec3b1
|
2020-01-31T16:55:50
|
|
Vulkan:Add FramebufferVk cache
This adds a FramebufferVk cache. Cache signature is based on unique Serial
values that are assigned to ImageHelper objects backing all color and DS
rendertargets as well as level/layer values unique to the imageView.
Update the Serials and cache signature at FramebufferVk::syncState() time.
L0 cache is a currently active framebuffer.
L1 cache retrieves previously created framebuffer from new cache.
If neither of those hit, create new FramebufferVk and add to L1.
Bug: angleproject:4322
Change-Id: I3f585271798ddfb9e5f194020adca8cf8a6b19dd
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2033869
Commit-Queue: Tobin Ehlis <tobine@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com>
|
|
|
579c5940
|
2020-01-17T13:20:21
|
|
Vulkan: Rename onGraphAccess to onResourceAccess.
Clarifies the function for the upcoming command graph linearization.
Bug: angleproject:4029
Change-Id: Ib50997c007053757de533f69c155a92d7555e0b2
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2003235
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
|
|
|
5fd73782
|
2019-08-09T11:46:46
|
|
Vulkan: Use volk to load vk* func ptrs
Thanks to Jamie Madill for some fixes to get all CI test passing w/ volk.
This change updates all ANGLE targets that use Vulkan to dyanmically
link all of the VK entrypoints using the volk OSS library from
https://github.com/zeux/volk.
It's only two source files so baking them directly into ANGLE repo.
Also it's used in both the tests and libANGLE trees so added to
src/common/third_party/volk dir.
Updated volk and the renderer to track latest instance and device
that were loaded and renderer will refresh vk* function pointers if
the current and previous device and/or instance don't match. This
prevents errors in the test framework as we transition between
backends, especially between VK HW & SwiftShader ICDs.
This change rolls the Vulkan Loader forward to use the latest loader
version which no longer allows static linking but requires dynamic
linking.
Bug: angleproject:3740
Bug: angleproject:4092
Bug: angleproject:4162
Bug: angleproject:4210
Bug: angleproject:4225
Change-Id: I8a0b7d24c9545bbfdfaa4b9357a9bfe6793e0140
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1965640
Commit-Queue: Tobin Ehlis <tobine@google.com>
Reviewed-by: Tobin Ehlis <tobine@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
68591eff
|
2019-10-13T15:05:23
|
|
Vulkan: Store ImageView access in the graph.
This will ensure we don't destroy the image views when they are still
in use by other Contexts.
Bug: angleproject:2464
Change-Id: I1d3ba2ad241250e31ea32873446c4cb23971750d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1843236
Reviewed-by: Tim Van Patten <timvp@google.com>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
|
a14555a7
|
2019-10-13T15:05:22
|
|
Vulkan: Refactor RenderTargetVk ImageViews.
Instead of storing a pointer to an ImageView, store a
pointer to an ImageViewHelper. The level and layer index
are all that's needed to pull the right image view from
the ImageViewHelper.
Will make it easier to store ImageView references in the
graph to track lifetime.
Bug: angleproject:2464
Change-Id: I773fa79a89ceefc99ff70e4eed4985f9f01fe26a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1857549
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Ian Elliott <ianelliott@google.com>
Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com>
|
|
|
0b9ebe58
|
2019-10-15T11:15:42
|
|
Vulkan: Add "ImageViewHelper".
This allows views to track a different lifetime than vk::ImageHelper.
This in turn will fix the race condition on ContextVk destruction when
releasing ImageViews owned by TextureVk and RenderbufferVk. For now
this is a refactoring change only.
Bug: angleproject:2464
Change-Id: I9581975bd5d4913233bbed8439dd4a632cc78a2a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1843231
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Ian Elliott <ianelliott@google.com>
|
|
|
88bc4d3d
|
2019-10-04T20:41:24
|
|
Vulkan: Get rid of "fetch" level/layer image views.
Instead always use 2D array views when rendering to cube maps. We need
to keep the "fetch" image view for the main image for emulating
seamless cube map textures on GL 2.0. We also use it for some texture
copying init. These uses could potentially be replaced with sample
instructions if we wanted to remove this last "fetch" view.
Bug: angleproject:3975
Change-Id: I90f9be9fc6542d8ec27f6722132c1b27acf72176
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1842226
Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com>
Reviewed-by: Cody Northrop <cnorthrop@google.com>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
|
d7f28aae
|
2019-09-19T14:19:10
|
|
Vulkan: Pass CommandGraph when updating serials.
This is in preparation for storing a pointer to a shared resource use
structure.
Bug: angleproject:2464
Change-Id: I8f4ba1c71de6ad6a27ac06fc8012a0e94267cc16
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1785988
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
|
0b1fbcff
|
2019-08-30T15:05:12
|
|
Vulkan: Make vk::ImageView pointers const
Bug: angleproject:3563
Change-Id: I8b6415dd9508941d093f36e7ded72d25f571b6f3
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1779204
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
7e48c9eb
|
2019-08-06T17:17:19
|
|
Add explicit integer casts
WebKit uses the -Wshorten-64-to-32 flag which warns on these cases.
Bug: 3439
Change-Id: I8c1de60da0f173ca2036e2120e79b857f5f2775f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1740866
Commit-Queue: James Darpinian <jdarpinian@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
|
|
|
ce9be8c7
|
2019-05-24T09:35:06
|
|
Vulkan: Have a cubemap as 2D-array view handy
Previously, only texture copies used a shader that performed
texelFetch(). To support cubemaps, a hack was used to temporarily
create a 2D array view.
With upcoming support for multisample resolve, more shaders will be
using texelFetch() all requiring this workaround. This change instead
makes sure that a separate view is created for cubemaps for the purpose
of being used with these shaders. As a result, we have three logical
views on textures and render targets:
- Draw: a view that can be used as a color/depth/stencil attachment
- Read: a view that can be used to sample from
- Fetch: a view that can be used to fetch from
The fetch view is generally the same as the read view, except for cube
maps.
Bug: angleproject:3200
Change-Id: I21547f728c16f0aa8f0fcae152c400b5cc1565da
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1628585
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
|
6722009e
|
2019-05-20T11:12:53
|
|
Vulkan: Handle dirty RTs with state messages.
Prior to this CL we were handling dirty state change notifications by
flushing the RT Images just prior to use or just after they were
changed. This could lead to a few redundant checks in several places.
It also meant we needed an owner pointer from the RT to the parent
Image. This pointer would be null for Surfaces and Renderbuffers.
This cleans up the image flushing logic to be handled by dirty bit
notifications. When an app updates an attached Texture with TexSubImage
or related calls it will send a notification to the Framebuffer. The
Framebuffer then sets a dirty contents bit that is handled in the
implementation. In Vulkan this means flushing the dirty bits.
Requires adding a flag to the FramebufferImpl class to determine if we
need to syncState before we checkStatus. Adding the option allows us to
only call syncState for the GL back-end. Not calling syncState allows
the robust resource init operation to happen *before* we syncState.
Which in turn allows FramebuffeVk to initialize the VkImages in one go.
Added new regression tests for Texture updates. This might not cover
all cases. I found it was very hard to trigger some of the resource
update staging in TextureVk.
Bug: angleproject:3427
Change-Id: Idfa177436ba7fcb9d398f2b67922e085f778f82a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1601552
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
9fa248e1
|
2019-05-06T14:55:18
|
|
Vulkan: Implement EXT_draw_buffers
In GLES, color attachments are referenced by their indices. These
indices match between the API and GLSL. For example, if a shader has:
layout(location=0) out color;
layout(location=3) out roughness;
Then GLES would bind and enable GL_COLOR_ATTACHMENT0 and
GL_COLOR_ATTACHMENT3.
In Vulkan, the framebuffer object and the corresponding renderpass
define the color attachments, and they don't allow gaps in color
attachments as GLES does. A render subpass creates the mapping between
the color attachments as defined in the framebuffer and the attachments
used by the shader (with possible gaps).
This change packs the enabled GL color attachments for the sake of the
framebuffer, and sets the subpass up in such a way that the shaders
continue to use the same color output indices as GLES.
In the example above, we have the attachment indices as follows:
Status | GLES | GLSL | RenderPass | Subpass
enabled 0 0 0 0
disabled 1 - VK_ATTACHMENT_UNUSED
disabled 2 - VK_ATTACHMENT_UNUSED
enabled 3 3 1 1
That is, the array of color attachments in the Vulkan
framebuffer/renderpass is:
[0] = GL color attachment 0
[1] = GL color attachment 3
And the array of color attachment references in the Vulkan render
subpass is:
[0] = 0 (index 0 of the renderpass attachment array)
[1] = VK_ATTACHMENT_UNUSED
[2] = VK_ATTACHMENT_UNUSED
[3] = 1 (index 1 of the renderpass attachment array)
Bug: angleproject:2394
Change-Id: Ib6cd2b60882643ea152986eee453270d09cd4aed
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1595442
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
5a604a5f
|
2019-03-27T14:22:50
|
|
Ensure framebuffer is up-to-date before drawing
The dEQP-GLES2.functional.fbo.render.texsubimage.between_render_tex2d*
test was failing because a TexSubImage call modifying the framebuffer
wasn't being applied before a subsequent DrawElements call and thus
getting an incorrect result.
Bug: angleproject:3249
Test: angle_deqp_gles2_tests --gtest_filter=dEQP.GLES2/functional_fbo_render_texsubimage_between_render_tex2d_rgb --use-angle=vulkan
Change-Id: I90f791957e6536c5c62fb731d52cd486ab5c05c1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1542361
Commit-Queue: Courtney Goeltzenleuchter <courtneygo@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
6854940d
|
2019-03-25T23:30:49
|
|
Vulkan: Correct RenderTargetVk extents to image mip
RenderTargetVk::getImageExtents() was always returning the base level
extents of the image it was viewing. This resulted in incorrect extents
being provided to various framebuffer- and renderpass-related
declarations. The function is renamed to `getExtents()` and returns the
appropriate mip extents.
Bug: angleproject:2361
Change-Id: I059a8d19fcb140c9095107d935aa3e5cb1852fc2
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1537327
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
|
2660b503
|
2019-03-21T12:08:40
|
|
Vulkan: Restore CommandBuffer to namespace vk
Moved vk::CommandBuffer and vk::SecondaryCommandBuffer to vk::priv:: and
aliased vk::CommandBuffer to one or the other. This allows the rest of
the classes to continue seeing vk::CommandBuffer as they used to do.
Used a special alias for the primary command buffer that gets submitted
(vk::PrimaryCommandBuffer).
Bug: angleproject:3136
Change-Id: I61236fd182230991db7395d05e3da3be5e3f45be
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1534456
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
134425c7
|
2019-03-15T17:02:17
|
|
Vulkan:Integrate SecondaryCommandBuffers
Integrate the custom SecondaryCommandBuffer type into the CommandGraph
nodes by adding new ANGLE_USE_CUSTOM_VULKAN_CMD_BUFFERS define that can
be set in the BUILD gn args with angle_enable_custom_vulkan_cmd_buffers
set to "true."
Initially the custom cmd buffers are disabled by default.
This adds some support functions to SecondaryCommandBuffer to make the
integration easier by matching the wrapped cmd buffer interface:
initialize(), end(), valid().
Bug: angleproject:3136
Change-Id: Ib910554583192550757bb8ce89914e3ea8737988
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1526556
Commit-Queue: Tobin Ehlis <tobine@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
4a298703
|
2019-01-18T10:49:36
|
|
Vulkan: Support creating EGL images from non-zero mipmaps of textures.
Store a mip offset in TextureVK to apply to all operations on the ImageHelper.
There is no need to store the mip offset in RenderbufferVk because it creates
the resource with the mip offset on the call to setStorageEGLImageTarget.
Store a mipmap level in the RenderTargetVk object so that clear operations
will target the correct mipmap of the image.
BUG=angleproject:2668
Change-Id: Ie976e3dd3a8de8135a7fbb8c84bd51eec0dddce8
Reviewed-on: https://chromium-review.googlesource.com/c/1422059
Commit-Queue: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
7dafe3eb
|
2019-01-28T11:39:15
|
|
Vulkan: optimize image memory barriers
Each image was tracking its current layout, but not the pipeline stage
it was used. Additionally, the barrier access masks were inferred from
the layout. This incurred two inefficiencies:
- The src pipeline stage mask often included all stages, causing
unnecessarily heavy barriers.
- The access masks included all possible accesses by a layout, which in
some cases was overkill, like VK_ACCESS_MEMORY_WRITE_BIT for
VK_IMAGE_LAYOUT_GENERAL (which will eventually used for compute shader
output).
This change instead creates an enum where each element represents the
layout, the stage and access masks when transitioning into the layout
and the stage and access masks when transitioning out of that layout.
The image will instead track a value of this enum (instead of
VkImageLayout), which allows it to create the layout transition barriers
as tight as possible, since it includes all the necessary information.
Bug: angleproject:2999
Change-Id: I91535ce06d10530a6fc217ad3b94b7e288521e25
Reviewed-on: https://chromium-review.googlesource.com/c/1440074
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
f3e823db
|
2019-01-14T12:40:34
|
|
Vulkan: Store ImageHelper as a pointer in TextureVk and RenderbufferVk
Storing ImageHelper as a pointer allows the storage to be swapped or shared
with other objects.
BUG=angleproject:2668
Change-Id: I2e51f24737be59ffe9f472e9b0b592774a792cd1
Reviewed-on: https://chromium-review.googlesource.com/c/1409404
Commit-Queue: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
c81e7bfe
|
2019-01-18T15:35:55
|
|
Vulkan: refactor CommandGraphResource
Merged back RecordableGraphResource into CommandGraphResource. Queries
didn't really need to be a resource, as they always inserted separate
single-command nodes in the graph. The CommandGraph class is augmented
with a few functions that generate such nodes.
This is in preparation for debug markers, as they too require such
nodes.
Bug: angleproject:2853
Change-Id: I5251a0e0fdd42ed1126921b4acc13687a14af9cd
Reviewed-on: https://chromium-review.googlesource.com/c/1422549
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
ab2bfa81
|
2019-01-15T19:06:47
|
|
Enable Chromium clang style plugin for libANGLE.
This fixes a few style warnings:
* auto should not deduce to raw pointer type
* inlined virtual methods are not allowed
* non-trivial constructors and destructors should be explicit
* inlined non-trivial constructors should not be in-class
* missing override keywords
Bug: angleproject:3069
Change-Id: I3b3e55683691da3ebf6da06a5d3c729c71b6ee53
Reviewed-on: https://chromium-review.googlesource.com/c/1407640
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
|
|
|
29b49417
|
2019-01-07T14:03:06
|
|
Make copy texture test more extensive
By doing the copy multiple times, we exercise both paths where the
destination is already initialized and when it's not.
This adds tests for all combinations of formats and flags.
Bug: angleproject:2958
Change-Id: I56afb44496acd1b4d5a8527f4dbee29afbac9c81
Reviewed-on: https://chromium-review.googlesource.com/c/1398643
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
|
f83a28a6
|
2018-12-09T03:48:34
|
|
Vulkan: Shader path for framebuffer-to-texture copy
Part 1 in a series of changes to perform image copies on the GPU.
Bug: angleproject:2958
Change-Id: I6264a880865c4738c0866f2dc71af63425fc4118
Reviewed-on: https://chromium-review.googlesource.com/c/1370724
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
b980c563
|
2018-11-27T11:34:27
|
|
Reformat all cpp and h files.
This applies git cl format --full to all ANGLE sources.
Bug: angleproject:2986
Change-Id: Ib504e618c1589332a37e97696cdc3515d739308f
Reviewed-on: https://chromium-review.googlesource.com/c/1351367
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
193a284d
|
2018-10-30T17:28:41
|
|
Vulkan: Split vk::CommandGraphResource.
This adds two subclasses: RecordableGraphResource and
QueryGraphResource. Each specializes for Buffer/Image/Frambuffer use
cases and Query use cases respectively. No virtual functions are added
to keep best performance.
We also change the CommandGraph API slightly to optimize away the check
for a barrier resource. This requires exposing the set current barrier
API on the CommandGraph.
Bug: angleproject:2828
Change-Id: I1c23f52bfe04cc682a00b245d63c3ac9a651615d
Reviewed-on: https://chromium-review.googlesource.com/c/1305994
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
|
2d03ff4a
|
2018-09-27T15:04:26
|
|
Vulkan: Make Buffer/Image be CommandGraphResources.
Don't make TextureVk/RenderbufferVk/SurfaceVk/BufferVk own the
manipulation of the command graph. Instead put the operations close to
the buffers and images used to render.
This will lead towards implementing implicit barriers on the command
graph resources.
Bug: angleproject:2828
Change-Id: I07b742b6792c60285b280d6454f90e963d667e0e
Reviewed-on: https://chromium-review.googlesource.com/1246983
Reviewed-by: Frank Henigman <fjhenigman@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
|
3f3b358f
|
2018-09-14T10:38:44
|
|
Vulkan: Fix cube map attachment clears and readpixels.
These were both missing the correct layer offset. Cache the layer
inside the RenderTargetVk for easy access.
Bug: angleproject:2470
Change-Id: I690dbf0702d7ec52f44ba0a9429b6ef0e51baf6b
Reviewed-on: https://chromium-review.googlesource.com/1225910
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
|
|
|
71bb0267
|
2018-09-12T11:09:42
|
|
Vulkan: Implement cube map render targets.
Each TextureVk now stores vectors of RenderTargetVks and ImageViews
associated with the image faces. They are initialized lazily when the
RenderTarget is queried in getAttachmentRenderTarget.
There's still one missing edge case for handling clear with the
Framebuffer when using cube maps. Also one additional test failure on
Android.
Bug: angleproject:2470
Change-Id: Ib959a3434a992cef010a11940cf2ee49e118ac17
Reviewed-on: https://chromium-review.googlesource.com/1220727
Reviewed-by: Frank Henigman <fjhenigman@chromium.org>
Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
1617e69e
|
2018-07-11T11:08:19
|
|
Vulkan: Implement depth/stencil blit with flip of the viewport
- This makes all end2end tests pass successfully on Win/Nvidia
with viewport flipping enabled.
Bug: angleproject:2673
Change-Id: I031c0a0f5fb0aede58b59479e57c2c127bcb964c
Reviewed-on: https://chromium-review.googlesource.com/1133703
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Luc Ferron <lucferron@chromium.org>
|
|
|
e4e2d0c5
|
2018-06-22T08:25:05
|
|
Vulkan: Add RenderTargetVk::getImageForRead.
This helper method will also transition the Image to the correct read
layout. We will need to revisit the implementation when working on
simulatenous read.
Bug: angleproject:2539
Change-Id: Id61404460f3ef0dbb054e6ac2dfc0b59adb78402
Reviewed-on: https://chromium-review.googlesource.com/1108378
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Luc Ferron <lucferron@chromium.org>
|
|
|
a5e06071
|
2018-05-18T14:36:05
|
|
Vulkan: Move the CommandGraphNode class to the cpp.
This totally hides the details of the CommandGraphNode implementation
from the rest of the back-end. This continues the simplification of
the graph/resource APIs.
Refactoring change only.
Bug: angleproject:2539
Change-Id: I7e0f286c387599624cfdff6c8972a8e082fe05d3
Reviewed-on: https://chromium-review.googlesource.com/1052069
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Luc Ferron <lucferron@chromium.org>
Reviewed-by: Frank Henigman <fjhenigman@chromium.org>
|
|
|
316c6065
|
2018-05-29T10:49:45
|
|
Vulkan: Call GraphResource instead of GraphNode.
We don't need to use the CommandGraphNode class directly. This CL
consolidates our code so we never call the GraphNodes class directly.
Instead we call operations on GraphResource. This should simplify the
interaction with APIs from the various graph and dependency management
classes in the Vulkan back-end.
A new concept of 'starting' vs 'appending' commands is introduced.
Appending tries to avoid starting new command buffers when possible.
Should not change how the graphs are constructed, and mostly be a
refactoring change. There may be minor behaviour changes to some
commands.
Bug: angleproject:2539
Change-Id: Ia971e5cacb1164b9b3b22fa4a0a55b954d81f10e
Reviewed-on: https://chromium-review.googlesource.com/1052068
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Frank Henigman <fjhenigman@chromium.org>
|