|
d59bccb5
|
2020-09-23T10:20:35
|
|
Vulkan: updateRenderPassDesc may lose color attachment data
FramebufferVk::updateRenderPassDesc() is resetting entire
mRenderPassDesc, which may lose color unresolve attachments. This CL
makes sure that when we toggle depth stencil buffer's read/write access,
we do not reset the whole mRenderPassDesc. Instead we only update the
depth stencil attachment's access.
Bug: b/168953278
Change-Id: Ia9df2d8ac81ebf2da8a360ba1293faf6c14b2738
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2426468
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
|
|
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>
|
|
|
f39e0f01
|
2020-09-07T23:07:37
|
|
Vulkan: Use subpass to unresolve render-to-texture attachments
GL_EXT_multisampled_render_to_texture allows singlesampled textures to
be used with multisampled framebuffers in such a way that the final
resolve operation is automatically done. In Vulkan terminology, the
render-to-texture GL attachment is used as a Vulkan subpass resolve
attachment with an implicit (ideally-)lazy-memory multisampled image as
the color attachment.
This extension expects that if the texture is drawn to after the
automatic resolve, the implicit multisampled image would take its
fragment colors from the singlesampled image. In other words, the
opposite of a resolve operation should be automatically performed at the
start of the render pass. This change refers to this operation as
"unresolve".
The goal of this extension is to allow tiling GPUs to always keep
multisampled data on tile memory and only ever load/store singlesampled
data. The latter is achieved by using a subpass resolve attachment and
setting storeOp of the multisampled color attachment to DONT_CARE. This
change achieves the former by using an initial subpass that uses the
resolve attachment as input attachment, draws into the multisampled
color attachment and sets loadOp of said attachment to DONT_CARE.
Bug: angleproject:4881
Change-Id: I99f410530365963567c77a7d62fc9db1500e5e3e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2397206
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
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>
|
|
|
37457d08
|
2020-09-15T14:38:53
|
|
Vulkan: Support MSRTT color renderbuffers
Color renderbuffers are similar to multisampled-render-to-texture
textures, but much simpler. The same mechanism is used to implement
them.
Bug: angleproject:4836
Change-Id: I298529c9fd1b03e78b1e37cdbe595e66166ee130
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2412847
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
|
|
|
91a03bd4
|
2020-08-03T23:24:31
|
|
Vulkan: Fix render-to-texture simultaneously bound to two FBOs
If a texture is simultaneously attached to two FBOs, one where it's a
normal texture and another where it's multisampled-render-to-texture,
different render targets must be created for it.
If a texture is simultaneously attached to two FBOs, both as
multisampled-render-to-texture but with different sample counts, two
implicit multisampled images need to be created as well as different
render targets.
Bug: angleproject:4913
Change-Id: I584ba327e4cb2099ef62f86f5d88719dc156ce13
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2335810
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
f776eb9c
|
2020-08-01T23:45:24
|
|
Vulkan: EXT_multisampled_render_to_texture2 support
The previous change that implemented EXT_multisampled_render_to_texture
already provisioned this extension in the Vulkan backend. This change
implements the front-end for this extension and enables it in the Vulkan
backend.
Bug: angleproject:4836
Change-Id: I7080260972e61727c5716051c236f635668cb67b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2330510
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Jonah Ryan-Davis <jonahr@google.com>
|
|
|
47207e42
|
2020-08-01T23:43:43
|
|
Vulkan: Fix blit/resolve of mixed-samples framebuffers
A framebuffer could contain a mixture of multisampled and
multisampled-render-to-texture attachments. When used as the source of
a glBlitFramebuffer operation, the former requires a resolve while the
latter is a blit. This change fixes this use-case.
Bug: angleproject:4836
Change-Id: I1d39bf25f54df9f8b68304058596a2d1c975f9ba
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2333987
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
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>
|
|
2d0e5b55
|
2019-08-27T13:49:07
|
|
GL_EXT_multisampled_render_to_texture extension. Part 2.
For textures that use this extension, a multisampled texture is
implicitly created for the texture.
Upon write or read, the multisampled texture is either return
to be drawn to or resolved and returned as a single sampled texture.
This is the functionality change with end2end tests.
Bug: angleproject:980428
Change-Id: I5776875a132fed7a3f4f00fb02f9e8e250684630
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1773717
Commit-Queue: Rafael Cintron <rafael.cintron@microsoft.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|