Wording of VUID-VkRenderPassBeginInfo-framebuffer-04627 is confusing

[Ralith]

VUID-VkRenderPassBeginInfo-framebuffer-04627 states:

If framebuffer was created with a VkFramebufferCreateInfo::flags value that included VK_FRAMEBUFFER_CREATE_IMAGELESS_BIT, each element of the pAttachments member of a VkRenderPassAttachmentBeginInfo structure included in the pNext chain must be a VkImageView with an inherited usage equal to the usage member of the corresponding element of VkFramebufferAttachmentsCreateInfo::pAttachmentImageInfos used to create framebuffer

"inherited usage" links to:

... image view creation inherits the implicit parameter usage specifying the allowed usages of the image view that, by default, takes the value of the corresponding usage parameter specified in VkImageCreateInfo at image creation time. The implicit usage can be overriden by adding a VkImageViewUsageCreateInfo structure to the pNext chain

The VUID text therefore appears to specify that the usage specified in VkImageViewUsageCreateInfo is ignored, because specifically the inherited usage, defined as the usage specified for the underlying image, is used. However, discussion in https://github.com/KhronosGroup/Vulkan-Docs/issues/1391 suggests that the intended meaning is the opposite.

The wording should be clarified by removing the use of the word "inherited" to describe the effective usage. For example, "effective usage" could be used instead, perhaps with an explicit definition for that added to the linked section.

[kejran]

Do we have any update on this? The spec still suggests opposite behaviour to https://github.com/KhronosGroup/Vulkan-Docs/issues/1391 and https://github.com/KhronosGroup/OpenXR-Docs/issues/55, and the validation layers even specifically check for the inherited usage: https://github.com/KhronosGroup/Vulkan-ValidationLayers/pull/2480.

From inspecting the validation layer code, it seems that "inherited" usage actually means the image usage described as "implicit" in the spec, further overridden by VkImageViewUsageCreateInfo, if any. It is extremely unintuitive, and should be at least clarified.

[sfricke-samsung]

Sorry for the delay @kejran and @Ralith

(disclaimer, I have no knowledge of the OpenXR part of this) (disclaimer 2... I am very aware this VUID is not friendly to read and is the result of 2 ugly pNext touching each other in a nasty way)

---

Validation Example:

Lets say VkImage a usage flags are COLOR_ATTACHMENT | TRANSFER_SRC

when creating VkImageView b the VkImageViewUsageCreateInfo struct is used so only COLOR_ATTACHMENT is set for the VkImageView b

Now since this is an imageless framebuffer, at vkCreateFramebuffer time there could be a VkFramebufferAttachmentsCreateInfo::pAttachmentImageInfos::usage with both COLOR_ATTACHMENT |TRANSFER_SRC`

At vkCmdBeginRenderPass time there will be a VkRenderPassAttachmentBeginInfo pointing to VkImageView b

In this case we want the VUID-VkRenderPassBeginInfo-framebuffer-04627 to be thrown and the usage flags are not equal between the

---

I know you are now thinking, "ok, but what about the fun spec language?"

So "inherited usage" was given to basically say "by default, an VkImageView and VkImage have the same usage flags

but there is a sentence

The implicit usage can be overriden by adding a VkImageViewUsageCreateInfo structure to the pNext chain, but the view usage must be a subset of the image usage.

This was trying to say it did not inherit all the usage flags because it was explicitly given a subset by the users

added here

---

1. Does this all make sense

2. I'm tainted because I wrote the original spec language change and Validation coverage, so very open to suggestions how to reword the VUID and/or spec text

---

final note, the original language of the VUID said

- of an image created with a value of VkImageCreateInfo::usage equal to the usage...
+ must be a VkImageView with an inherited usage equal to the usage...

[kejran]

Hi @sfricke-samsung, thanks for the reply. Yes, i realise that the inherited usage here allows us to override the image interface to conform to the one used for the renderpass. My issue here is the wording of "inherited" itself (which is, most likely, issue with VkImageView itself than imageless framebuffer specifically) which implies that it ignores the view usage and uses the implied usage instead.

The implicit usage can be overriden

This sentence states that implicit usage can be overriden - but it does not specify that overriden still means inherited.

I would probably want to see the "inherited" usage being renamed, or clarified what exactly it means (in spec and in validation) - because, as I mentioned, I had to dig into validation source to see what it actually does.

By the way, bit of a tangent - it still pains me actually having to create and keep track of redundant image sub-views to pass them as attachments - is there any motivation behind only allowing the exact specified usage instead of any superset that matches? Or are views so cheap and disposable that we can just create appropriate views for a given usage combination where we need them?

[Ralith]

The problem is that "inherited usage" is not defined anywhere, and can easily be read to have the opposite of the intended meaning, especially because it is explicitly stated that usage is "inherited from" the VkImage, suggesting that "inherited usage" means the VkImage's usage is what matters. A different term without that connotation should be used, and that term should probably be explicitly defined, as outlined in the original post.

(disclaimer, I have no knowledge of the OpenXR part of this)

OpenXR relies on the intended semantics, so there's no real problem there except that it's difficult to verify that it's correct without digging through non-normative github discussion.