v1.2.180 vk.xml extends unknown VkPipelineLayoutCreateFlagBits enum type
#1549
Comments
It is unlikely that disabled, reserved extensions (without naming whatsoever) are used through Ash bindings generated from Vulkan-Headers releases, and are best ignored to reduce diff noise and spurious issues [1] with unfinished extension definitions. [1]: KhronosGroup/Vulkan-Docs#1549
It is unlikely that disabled, reserved extensions (without naming whatsoever) are used through Ash bindings generated from Vulkan-Headers releases, and are best ignored to reduce diff noise and spurious issues [1] with unfinished extension definitions. [1]: KhronosGroup/Vulkan-Docs#1549
It is unlikely that disabled, reserved extensions (without naming whatsoever) are used through Ash bindings generated from Vulkan-Headers releases, and are best ignored to reduce diff noise and spurious issues [1] with unfinished extension definitions. [1]: KhronosGroup/Vulkan-Docs#1549
|
We'll address that in the next update, but I believe you've found the correct solution already. As the registry schema documentation notes, "When the extension tag is just reserving an extension number, and no interfaces are yet defined, use |
It is unlikely that disabled, reserved extensions (without naming
whatsoever) are used through Ash bindings generated from Vulkan-Headers
releases, and are best ignored to reduce diff noise and spurious issues
[1] with unfinished extension definitions.
This approach matches what is defined in the registry spec for
`supported="disabled"` [2]:
use `supported="disabled"` to indicate this extension should never
be processed.
[1]: KhronosGroup/Vulkan-Docs#1549
[2]: https://github.com/KhronosGroup/Vulkan-Docs/blob/b4e8cd820b2487bc892b391fb26b49501473a6a6/registry.txt#L1302-L1306
|
@oddhack Sounds good, added a reference to the registry spec in the fix just in case - ignoring these all seems like the right thing to do (it's just diff-noise for the time being). |
|
Also, as a futureproofness warning, eventually there are likely to be multiple API variants defined in the XML and the 'supported' tag will be a way that extensions are associated with the API variants that can support them. 'supported="vulkan"' isn't just semantic noise, it's a filter that identifies stuff belonging to the current Vulkan API. We do similar things in the OpenGL gl.xml already for interfaces or extensions that are specific to OpenGL, OpenGL ES, or both. |
|
This should be fixed in the 1.2.181 spec update. |
|
Is this comment out of date now? https://github.com/KhronosGroup/Vulkan-Docs/blob/ee9ed265a687fc31837081c6594530c6979235a4/xml/vk.xml#L10764 <type name="VkPipelineLayoutCreateFlags" comment="Will need FlagBits type eventually"/> |
No - it will require it "eventually", but "eventually" won't be until the first extension is published using a reserved bit (currently one disabled extension has reserved a bit, and presumably will eventually be published by that vendor). |
It is unlikely that disabled, reserved extensions (without naming
whatsoever) are used through Ash bindings generated from Vulkan-Headers
releases, and are best ignored to reduce diff noise and spurious issues
[1] with unfinished extension definitions.
This approach matches what is defined in the registry spec for
`supported="disabled"` [2]:
use `supported="disabled"` to indicate this extension should never
be processed.
[1]: KhronosGroup/Vulkan-Docs#1549
[2]: https://github.com/KhronosGroup/Vulkan-Docs/blob/b4e8cd820b2487bc892b391fb26b49501473a6a6/registry.txt#L1302-L1306
It is unlikely that disabled, reserved extensions (without naming
whatsoever) are used through Ash bindings generated from Vulkan-Headers
releases, and are best ignored to reduce diff noise and spurious issues
[1] with unfinished extension definitions.
This approach matches what is defined in the registry spec for
`supported="disabled"` [2]:
use `supported="disabled"` to indicate this extension should never
be processed.
[1]: KhronosGroup/Vulkan-Docs#1549
[2]: https://github.com/KhronosGroup/Vulkan-Docs/blob/b4e8cd820b2487bc892b391fb26b49501473a6a6/registry.txt#L1302-L1306
It is unlikely that disabled, reserved extensions (without naming
whatsoever) are used through Ash bindings generated from Vulkan-Headers
releases, and are best ignored to reduce diff noise and spurious issues
[1] with unfinished extension definitions.
This approach matches what is defined in the registry spec for
`supported="disabled"` [2]:
use `supported="disabled"` to indicate this extension should never
be processed.
[1]: KhronosGroup/Vulkan-Docs#1549
[2]: https://github.com/KhronosGroup/Vulkan-Docs/blob/b4e8cd820b2487bc892b391fb26b49501473a6a6/registry.txt#L1302-L1306
It is unlikely that disabled, reserved extensions (without naming
whatsoever) are used through Ash bindings generated from Vulkan-Headers
releases, and are best ignored to reduce diff noise and spurious issues
[1] with unfinished extension definitions.
This approach matches what is defined in the registry spec for
`supported="disabled"` [2]:
use `supported="disabled"` to indicate this extension should never
be processed.
[1]: KhronosGroup/Vulkan-Docs#1549
[2]: https://github.com/KhronosGroup/Vulkan-Docs/blob/b4e8cd820b2487bc892b391fb26b49501473a6a6/registry.txt#L1302-L1306
It is unlikely that disabled, reserved extensions (without naming
whatsoever) are used through Ash bindings generated from Vulkan-Headers
releases, and are best ignored to reduce diff noise and spurious issues
[1] with unfinished extension definitions.
This approach matches what is defined in the registry spec for
`supported="disabled"` [2]:
use `supported="disabled"` to indicate this extension should never
be processed.
[1]: KhronosGroup/Vulkan-Docs#1549
[2]: https://github.com/KhronosGroup/Vulkan-Docs/blob/b4e8cd820b2487bc892b391fb26b49501473a6a6/registry.txt#L1302-L1306
b4e8cd8#diff-ea2b2280eacdf0647fff0571d64126ecfa6ddb10cc488ecf38c98869254658ceR15625
VK_AMD_extension_319adds an enum flag bit toVkPipelineLayoutCreateFlagBits, but this type has not been declared to exist anywhere - in turn breaking certain code generators that rely on types to be defined.The text was updated successfully, but these errors were encountered: