Results 1 to 2 of 2

Thread: What does noautovalidity mean in Vulkan API schema (vk.xml)?

  1. #1

    What does noautovalidity mean in Vulkan API schema (vk.xml)?

    What does noautovalidity mean on a struct member definition in the Vulkan API schema (vk.xml)?

    registry.rnc says "tag stating that no automatic validity language should be generated"

    The Vulkan registry spec says: "prevents automatic validity language being generated for the tagged item. Only suppresses item-specific validity - parenting issues etc. are still captured. It must also be used for structures that have no implicit validity when such structure has explicit validity."

    What is automatic validity language?

    What is an example of something that has noautovalidity, and of that example, what was the item-specific validity that is suppressed? and why was it decided to be suppressed?

    What is an example of a structure that has no implicit validity and has explicit validity? Why?

  2. #2
    In the Vulkan specification, those dark-grey blocks about "valid usage?" Things often have two blocks: "Valid Usage" and "Valid Usage (implicit)". The implicit rules are usually obvious: if a parameter is a `VkDevice`, that must refer to a valid `VkDevice`. And so forth. Because these rules are obvious, there is no need for a human being to go around and write those rules out. Therefore, the system generates those rules directly from the parameters and type information in `vk.xml` itself...

    Unless `noautovalidity` is specified for that item.

    Consider `VkDescriptorImageInfo::sampler`. The normal implicit validity for that item would be that `sampler` will be a valid instance of a `VkSampler` object. But it doesn't have to be; it can be `VK_NULL_HANDLE`. So that item is set to have `noautovalidity="true"`.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
Proudly hosted by Digital Ocean