When we have a general layout, we need to always add a barrier even if
leaving the layout in general since we don't know what the use case for
general was with the old layout.
This doesn't seem to fix any of our synchronization issues which makes
sense since we don't really use a general layout much. The only place it
is used is for mipmap generation, but then we add explicit barriers in
that function itself and the first use of the image after mipmap generation
will change the layout to something other than general, usually SHADER_READ.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=
2298483002
Review-Url: https://codereview.chromium.org/
2298483002
SkASSERT(VK_IMAGE_LAYOUT_UNDEFINED != newLayout &&
VK_IMAGE_LAYOUT_PREINITIALIZED != newLayout);
VkImageLayout currentLayout = this->currentLayout();
- // Is this reasonable? Could someone want to keep the same layout but use the masks to force
- // a barrier on certain things?
- if (newLayout == currentLayout) {
+
+ // If the old and new layout are the same, there is no reason to put in a barrier since the
+ // operations used for each layout are implicitly synchronized with eachother. The one exception
+ // is if the layout is GENERAL. In this case the image could have been used for any operation so
+ // we must respect the barrier.
+ if (newLayout == currentLayout && VK_IMAGE_LAYOUT_GENERAL != currentLayout) {
return;
}
VkAccessFlags flags = 0;;
if (VK_IMAGE_LAYOUT_GENERAL == layout) {
flags = VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT |
- VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT |
- VK_ACCESS_TRANSFER_WRITE_BIT |
- VK_ACCESS_HOST_WRITE_BIT | VK_ACCESS_HOST_READ_BIT;
+ VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT |
+ VK_ACCESS_TRANSFER_WRITE_BIT |
+ VK_ACCESS_TRANSFER_READ_BIT |
+ VK_ACCESS_SHADER_READ_BIT |
+ VK_ACCESS_HOST_WRITE_BIT | VK_ACCESS_HOST_READ_BIT;
} else if (VK_IMAGE_LAYOUT_PREINITIALIZED == layout) {
flags = VK_ACCESS_HOST_WRITE_BIT;
} else if (VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL == layout) {