|
2f3d18f2
|
2020-10-01T05:58:44
|
|
Vulkan: Fix unresolve disagreement between FB and RP
FramebufferVk::updateRenderPass reset the render pass description, but
not the framebuffer description. This caused a disagreement between the
two regarding which attachments need to be unresolved. Later,
FramebufferVk::startNewRenderPass could miscalculate whether a new
framebuffer needs to be generated based on changes in unresolve
attachments.
For example:
- say in the first render pass color needs to be unresolved. Both RP
and FB desc would remember this (each being keys for their respective
caches).
- A following operation triggers syncState such that FB desc changes
(for example rebind of attachment), which cleared RP desc but not FB
desc's unresolve attachment state.
- If the next render pass does not require an unresolve (for example due
to a clear or invalidate), then the framebuffer is not recreated
because according to RP desc at the start and end of
FramebufferVk::startNewRenderPass there has been no change in
unresolve mask.
* At start there's no unresolve because of syncState clearing it.
* At end there's no unresolve because there's no need for unresolve.
- In the end, the framebuffer used for the first render pass would be
used for the second render pass as well. Note that:
* The first render pass included an unresolve, i.e. two subpasses.
* The second render pass requires one subpass according to its RP
desc.
It's quite easy to accidentally have the framebuffer correctly recreated
(based on the reset RP desc) before FramebufferVk::startNewRenderPass.
Note that since syncState has called updateRenderPass, FB desc has
necessarily changed, and mFramebuffer is nullptr, so any call to
FramebufferVk::getFramebuffer would recreate the framebuffer.
Both clear and invalidate call FramebufferVk::getFramebuffer.
The issue is reproducible in situations where clear/invalidate has been
called before the framebuffer is modified, and then draw is issued after
the modification. An ASSERT is added to catch discrepencies between RP
desc and FB desc to catch bugs even when the issue doesn't manifest
itself as a VVL error.
Bug: angleproject:4836
Change-Id: I8a0d116402a6c298377d03e0908baa942019ccd5
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2442379
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
01641c7a
|
2020-09-30T15:25:28
|
|
Vulkan: Fix UtilsVk clear in non-zero subpass
Mid-render-pass clears (through UtilsVk) run on the current subpass,
which in the presence of multisampled-render-to-texture unresolve
would be subpass 1. The graphics pipeline for that draw call should
set the correct subpass index.
Bug: angleproject:4836
Change-Id: Iba4a03ea96a63b0f5d09c27e5283ff8a8b534e05
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2441509
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
a8872e6d
|
2020-10-01T15:54:25
|
|
Skip MSRTT tests on Nvidia/Windows7
These bots don't have VK_EXT_depth_stencil_resolve.
Bug: chromium:1134286
Change-Id: I4cc5a627996139bf03dc3cc334435d08876a0a8a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2443584
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
43163491
|
2020-09-22T11:45:06
|
|
Vulkan: Unresolve depth/stencil MSRTT attachments
Using the same shader that unresolves color, this change allows
depth/stencil to be unresolved as well.
In turn, this allows the depth and stencil loadOp/storeOp of the
implicit multisampled image associated with a
multisampled-render-to-texture renderbuffer to be set to DONT_CARE.
Stencil unresolve depends on VK_EXT_shader_stencil_export. In the
absence of this extension, the stencil aspect is not unresolved and must
continue to use loadOp=LOAD and storeOp=STORE. This is not ideal, but
the expected use-case of depth/stencil MSRTT renderbuffers is that they
get invalidated, so that load and store wouldn't happen in practice.
Bug: angleproject:4836
Change-Id: I9939d1e15e10fa8ed285acdd6fe6edb42c59054f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2427049
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
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>
|