Vulkan Standard Validation Layer Error - VK_IMAGE_TILING_OPTIMAL does not support usage...

[mitchmindtree]

The following standard lunarg validation layer errors shows up when running the simple_window.rs example with validation layers enabled:

VUID-VkImageViewCreateInfo-usage-02275(ERROR / SPEC): msgNum: 0 - vkCreateImageView(): pCreateInfo->format VK_FORMAT_B8G8R8A8_SRGB with tiling VK_IMAGE_TILING_OPTIMAL does not support usage that includes VK_IMAGE_USAGE_STORAGE_BIT. The Vulkan spec states: If usage contains VK_IMAGE_USAGE_STORAGE_BIT, then the image view's format features must contain VK_FORMAT_FEATURE_STORAGE_IMAGE_BIT. (https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VUID-VkImageViewCreateInfo-usage-02275)
    Objects: 1
        [0] 0x3, type: 10, name: NULL
VUID-VkImageViewCreateInfo-usage-02275(ERROR / SPEC): msgNum: 0 - vkCreateImageView(): pCreateInfo->format VK_FORMAT_B8G8R8A8_SRGB with tiling VK_IMAGE_TILING_OPTIMAL does not support usage that includes VK_IMAGE_USAGE_STORAGE_BIT. The Vulkan spec states: If usage contains VK_IMAGE_USAGE_STORAGE_BIT, then the image view's format features must contain VK_FORMAT_FEATURE_STORAGE_IMAGE_BIT. (https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VUID-VkImageViewCreateInfo-usage-02275)
    Objects: 1
        [0] 0x4, type: 10, name: NULL

Not yet certain what the side-effects of the error are but its possible this could be related to the text distortion I'm seeing after applying @freesig's mitchmindtree/vulkano#6 patch.

[mitchmindtree]

Running the vk_debug example gives a little more detail, and reveals the culprit image seems to be the swapchain image (removing the possibility that it might be the intermediary frame image).

[vulkan] Validation information:  [ UNASSIGNED-ObjectTracker-Info ] Object: 0x3 (Type = 27) | OBJ[0x6] : CREATE SwapchainKHR object 0x3
[vulkan] Validation information:  [ UNASSIGNED-ObjectTracker-Info ] Object: 0x4 (Type = 10) | OBJ[0x7] : CREATE SwapchainImage object 0x4
[vulkan] Validation information:  [ UNASSIGNED-ObjectTracker-Info ] Object: 0x5 (Type = 10) | OBJ[0x8] : CREATE SwapchainImage object 0x5
[vulkan] Validation error:  [ VUID-VkImageViewCreateInfo-usage-02275 ] Object: 0x4 (Type = 10) | vkCreateImageView(): pCreateInfo->format VK_FORMAT_B8G8R8A8_SRGB with tiling VK_IMAGE_TILING_OPTIMAL does not suppor
t usage that includes VK_IMAGE_USAGE_STORAGE_BIT. The Vulkan spec states: If usage contains VK_IMAGE_USAGE_STORAGE_BIT, then the image view's format features must contain VK_FORMAT_FEATURE_STORAGE_IMAGE_BIT. (http
s://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VUID-VkImageViewCreateInfo-usage-02275)
[vulkan] Validation information:  [ UNASSIGNED-ObjectTracker-Info ] Object: 0x6 (Type = 14) | OBJ[0x9] : CREATE ImageView object 0x6
[vulkan] Validation error:  [ VUID-VkImageViewCreateInfo-usage-02275 ] Object: 0x5 (Type = 10) | vkCreateImageView(): pCreateInfo->format VK_FORMAT_B8G8R8A8_SRGB with tiling VK_IMAGE_TILING_OPTIMAL does not suppor
t usage that includes VK_IMAGE_USAGE_STORAGE_BIT. The Vulkan spec states: If usage contains VK_IMAGE_USAGE_STORAGE_BIT, then the image view's format features must contain VK_FORMAT_FEATURE_STORAGE_IMAGE_BIT. (http
s://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VUID-VkImageViewCreateInfo-usage-02275)

[mitchmindtree]

When enumerating the available swapchain formats via the vulkano surface capabilities API for my device (mesa intel on linux), I get the following output:

[
    (
        B8G8R8A8Srgb,
        SrgbNonLinear,
    ),
    (
        B8G8R8A8Unorm,
        SrgbNonLinear,
    ),
]

According to my vulkaninfo output, it looks like neither of these formats seem to support VK_IMAGE_TILING_OPTIMAL (or any tiling for that matter). There's a chance I'm reading this wrong though.

vulkaninfo.txt

I am also currently unsure whether or not vulkano provides a way to check for whether or not a format does or does not support certain kinds of tiling. @freesig are you aware of any I might be missing? I wonder if maybe this is just not exposed from the API yet.

Or maybe it's that vulkano intends to select the tiling kind based on the user's selected format, but this seems incorrect due to the potential for cases like this where there are no compatible tilings?

[freesig]

Yeh I've noticed that this has popped up in vulkano-rs/vulkano#1190 aswell.

I think it's an issue in vulkano because you can query it with vulkan like this:

void vkGetPhysicalDeviceFormatProperties(
    VkPhysicalDevice                            physicalDevice,
    VkFormat                                    format,
    VkFormatProperties*                         pFormatProperties);

Where you get back this struct.

typedef struct VkFormatProperties {
    VkFormatFeatureFlags    linearTilingFeatures;
    VkFormatFeatureFlags    optimalTilingFeatures;
    VkFormatFeatureFlags    bufferFeatures;
} VkFormatProperties;

Where each of those gives back bit flags indicating what is supported.

So it's definitely possible to check.

Just so were on the same page this error is about the combination of image in VK_IMAGE_TILING_OPTIMAL with the format VK_FORMAT_B8G8R8A8_SRGB that is trying to be used as VK_IMAGE_USAGE_STORAGE_BIT.
It's a little odd that something is trying to use some image in simple_window as a storage image as there is no descriptor set using any images as storage that I'm aware of in that example or nannou.
So maybe this is the first thing to confirm. It's also possible that vulkano is mistakenly setting an image to VK_IMAGE_USAGE_STORAGE_BIT.

Looking at vulkano it seems that it does grab the optimal supported features for the swapchains format and stores them in the UnsafeImage but there is no method to check if this is correct.

I think what might be going on is that the storage bit is being mistakenly set somewhere.

[freesig]

Actually I think this is the source of the error.
Here we are saying set the swapchain image to all of the supported usage formats for the window.
This is probably not what we want. Because we are not actually using the swapchain image in all these ways (this is probably a performance hit as well).

I just had a look at how the intermediate image and swapchain image are used and I can't quiet figure out how this works.
Is this about right:
Two renderpasses. The first writes to the intermediate.
The second loads the intermediated into each pixel and then writes to the swapchain.
And the reason for doing this instead of just doing a copy_image(intermediate, swapchain) is because you want the resolve for MSAA?
(There is actually vkCmdResolveImage so we might be able to get rid of this second renderpass and just use a resolve for MSAA or a copy for non-MSAA)

If this is the case then we only need the VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT set for the swapchain image.

The intermediate image though is a little more complex because it also needs to satisfy the same format. I'm not sure the best way to handle this as we don't know ahead of time how people will use it. Most of the time it will just be VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT but sometimes people might want to copy from it (like in the screenshot example I'm trying to build). Then it would need VK_IMAGE_USAGE_TRANSFER_SRC_BIT.

I can't off the top of my head think what other uses anyone would need for the intermediate would be so maybe a good start would be:

ImageUsage {
transfer_source: true,
color_attachmen: true
..ImageUsage::none()
}

Atleast with the intermediate you will get a ImageCreationError::UnsupportedUsage error if the format is not supported because this is actually checked with the AttachmentImage

[freesig]

Actually now that I think about it, it's not the intermediate image that the user would ever need more usage then:

ImageUsage {
color_attachmen: true
..ImageUsage::none()
}

Because its in MSAA form. So we actually need more usages on the swapchain itself. For a start:

ImageUsage {
transfer_source: true,
color_attachmen: true
..ImageUsage::none()
}