|
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>
|
|
|
914fe61b
|
2024-03-15T13:20:49
|
|
Vulkan: Rename RendererVk.* to vk_renderer.*
Done in a separate CL from the move to namespace vk to avoid possible
rebase-time confusion with the file name change.
Bug: angleproject:8564
Change-Id: Ibab79029834b88514d4466a7a4c076b1352bc450
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5370107
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
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>
|
|
|
5c04f18a
|
2023-04-24T16:18:24
|
|
Vulkan: Remove DisplayVk param from ToEGL
It's no longer used
Bug: angleproject:3041
Change-Id: I5063152d1598aa5d40d94bbf5c643a1288589037
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4470387
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Igor Nazarov <i.nazarov@samsung.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
f1872822
|
2022-12-22T17:17:37
|
|
Vulkan: Fix imageless framebuffer VVL issue
In some tests, including some blink tests, there were cases of VVL
messages spamming the output log, even though they did not always
cause a failure. Investigation showed that in some cases, the call
to EGL_CreateImageKHR() was not setting all the attributes in the
ImageHelper object that is used later for an imageless framebuffer,
specifically the one created in VkImageImageSiblingVk::initImpl().
* Added the usage flags and view formats in the new image created in
VkImageImageSiblingVk.
* Added a Vulkan image test to make sure the error is fixed.
Bug: b/261473248
Bug: angleproject:7845
Change-Id: I1874b2930e9ce62e5b603cf7acff6fd78b957d5b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4117584
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
02cc4cd5
|
2022-12-07T12:03:26
|
|
Vulkan: Remove ImageHelper::mImageAndViewGarbage
This was introduced in crrev.com/c/3449450. At that time this is
necessary, because we can not copy mUse for immediate view garbage
collection. Now with recent work, mUse is copyable, we no longer need to
accumulate the view garbage. They can be released immediately with a
copy of image's mUse.
Bug: b/261737134
Change-Id: Ic4393f8c4ee7c0e3be4669a0a557507c909a77ab
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4087323
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
c649979b
|
2022-05-17T20:53:16
|
|
Create EGLImage from VkImage correctly with non sized format
Sometime, client may pass in non-sized internal formats
(GL_BGRA, GL_RED and GL_RG) for creating EGLImage from VkImage.
For those formats, angle::Format::InternalFormatToID(internalFormat)
can not return valid result. Fix the problem, by converting
internalFormat to sized format first.
Bug: chromium:1326658
Change-Id: Id88e0614a2a9f55aabac116ea95ed8cec02672a3
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3652741
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Peng Huang <penghuang@chromium.org>
|
|
|
bd7915fd
|
2022-04-04T10:02:29
|
|
Use provided format as intended format for EGLImage from VkImage
The problem is because VkImage is created with R8G8B8A8 format,
and then imported into ANGLE as EGLImage with GL_RGB format,
however ANGLE doesn't set intended format correctly (ANGLE uses
R8G8B8A8 instead of R8G8B8X8). So when clients use glReadPixels()
to get pixels, the alpha channel is filled with incorrect value.
Bug: chromium:1312490
Change-Id: Ief5b87ec5eb03c9cb37f10b2c20b5caf3013262d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3569481
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Peng Huang <penghuang@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>
|
|
|
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>
|
|
|
706f8a31
|
2022-02-04T04:22:10
|
|
Support gl internal format for creating EGLImage from VkImage
Bug: chromium:1290638
Change-Id: I5c9815b727497f63b9f04ecbd8c27deef4b929c8
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3438666
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Peng Huang <penghuang@chromium.org>
|
|
|
32f572b7
|
2021-12-03T17:58:51
|
|
Support creating EGLImage from VkImage
Bug: chromium:1264439
Change-Id: I520182143e748f25b44d0725f3f171b7b33a85d8
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3311131
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Peng Huang <penghuang@chromium.org>
|