VK_IMAGE_CREATE_EXTENDED_USAGE_BIT not referenced in VU checks

[karl-lunarg]

Issue by cdwfs (MIGRATED)
Tuesday May 08, 2018 at 22:37 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#2658

---

I don't have a specific error in mind here, but it seems alarming that VK_IMAGE_CREATE_EXTENDED_USAGE_BIT isn't used in any image / image view validation checks.

For reference, here's the entirety of what the spec says about this bit:

Definition:

VK_IMAGE_CREATE_EXTENDED_USAGE_BIT specifies that the image can be created with usage flags that are not supported for the format the image is created with but are supported for at least one format a VkImageView created from the image can have.

Before VUs for VkImageCreateInfo:

• For images created without VK_IMAGE_CREATE_EXTENDED_USAGE_BIT a usage bit is valid if it is supported for the format the image is created with.
• For images created with VK_IMAGE_CREATE_EXTENDED_USAGE_BIT a usage bit is valid if it is supported for at least one of the formats a VkImageView created from the image can have (see Image Views for more detail).

Based on that second quote, it sounds like the bit should be used to select which usage flags are checked further down the line.

[karl-lunarg]

Comment by daveh-lunarg (MIGRATED)
Tuesday May 08, 2018 at 23:38 GMT

---

I'm a bit confused by this. There was some minimal support for EXTENDED_USAGE as of PR #2567, but it looks like it was stripped out by the 1.1.73 header change PR #2585. Looking into it.

[daveh-lunarg]

The two bullets above are placed to modify this statement: To determine the set of valid usage bits for a given format, call vkGetPhysicalDeviceFormatProperties. To validate the EXTENDED_USAGE bit would require computing the list of all possible ImageView-compatible formats and running each through vkGPDFP.

The language also seems too loose. Suppose the the usage field contains bitA and bitB which are not supported by the supplied format. If EXTENDED_USAGE is set, we would compute and query all the possible view formats, and could find a formatA that supports bitA and formatB that supports bitB. This would pass the check as described, but it seems unlikely to be the intent. It's probably intended that there be an ImageView format that supports both bitA and bitB.

I don't see any valid usage statements that qualify image usage bits by image format, and no valid usage statements that mention EXTENDED_USAGE at all, so I don't think this is a validation bug, just an incomplete at most.

[mark-lunarg]

Folding into #1495. Will address it through that issue.