Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Specify that the stored size of headerVersion in VkPipelineCacheHeaderVersionOne is 4 bytes #2477

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

elasota
Copy link

@elasota elasota commented Jan 2, 2025

Pedantic fix. C/C++ allow enums to be larger than 4 bytes. This specifies that the stored VkPipelineCacheHeaderVersion in VkPipelineCacheHeaderVersionOne is exactly 4 bytes.

@CLAassistant
Copy link

CLAassistant commented Jan 2, 2025

CLA assistant check
All committers have signed the CLA.

@@ -7838,10 +7838,10 @@ with identical pipeline identifiers in the same pipeline cache.

Unlike most structures declared by the Vulkan API, all fields of this
structure are written with the least significant byte first, regardless of
host byte-order.
host byte-order, and the headerVersion field is written as exactly 4 bytes.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the SC-specific version of the structure (which should be updated as well). The vulkan version is at line 7793.

And we suspect there might be other structures which need similar language.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • VkDeviceFaultVendorBinaryHeaderVersionOneEXT the same language and should be updated as well.
  • VkValidationCacheHeaderVersionEXT has a table which explicitly lists the offsets, so it might be ok.
  • VulkanSC also has VkPipelineCacheHeaderVersionSafetyCriticalOne structure and the validationVersion field needs the same handling.

Feels like maybe we should make a common include for two paragraphs that are replicated numerous places. (Might need to parameterize it by the intended structure size).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Feels like maybe we should make a common include for two paragraphs that are replicated numerous places. (Might need to parameterize it by the intended structure size).

No need for a separate include - write it in one place then use asciidoc transclusion like we do for boilerplate in the limits and features structs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants