Valid usage of pointer chains

[MaikKlein]

The spec is not completely clear on what is considered valid.

Is the order of pNext important? The spec says what is a valid pNext for a given struct but at one point this has to be broken.

For example:

B extends A
C extends A

A pointer chain could look like

A -> B -> C but the spec for B didn't mention that it can point to C.

Looking at VulkanHpp, it appears that the order is somewhat relevant in that if B extends A then A has to come before B.

Will there ever be a case where C extends B extends A but C doesn't extend A?

For example if I were to remove the following line from vulkan.hpp

template <> struct isStructureChainValid<DeviceCreateInfo, PhysicalDeviceVariablePointerFeatures>{ enum { value = true }; };

This would compile just fine

vk::StructureChain<vk::DeviceCreateInfo, vk::PhysicalDeviceFeatures2, vk::PhysicalDeviceVariablePointerFeatures> c;

but this doesn't compile

vk::StructureChain<vk::DeviceCreateInfo, vk::PhysicalDeviceVariablePointerFeatures,vk::PhysicalDeviceFeatures2> c;

[krOoze]

Is the order of pNext important?

No:

Extensions should be defined to accept any order of chaining, and must define their interactions with other extensions such that the results are deterministic.

A -> B -> C but the spec for B didn't mention that it can point to C.

You have it other way around. What is not forbidden is allowed.
The appropriate VU for the whole chain would be at the topmost struct (A).

E.g. if a struct is both topmost and extension e.g. VkDebugUtilsMessengerCreateInfoEXT might be brittle if later extended though... but that's rare cornercase.

Will there ever be a case where C extends B extends A but C doesn't extend A?

Yes and no. Per the above quote by default A must accept C, except if there was an explicit VU forbiding it.

[oddhack]

@MaikKlein have you referred to the "Valid Usage for Structure Pointer Chains" section of the Vulkan spec? Vulkan-Hpp is just a wrapper, and it doesn't determine what the Vulkan implementation accepts. It sounds like your issue might be with Vulkan-Hpp, not Vulkan itself.

[MaikKlein]

@oddhack I have read through the spec several times and I was unsure about the valid usage. I am one of the authors of ash another vulkan wrapper, and I want to implement pointer chains. I just had a look at VulkanHpp to see how they validate the pointer chains.

@krOoze

Yes and no. Per the above quote by default A must accept C, except if there was an explicit VU forbiding it.

Is there already a case for this in the spec? If not how would something like this behave?

B extends A
C extends A
D extends A

If B forbids C would then A -> C -> D -> B also be invalid? I assume it would be invalid and the order of the chain doesn't matter at all. I would read it as "if B is in the chain, then C can not be in the chain`.

[krOoze]

Is there already a case for this in the spec?

I don't think so. The two debug creation structs are the only ones that come to mind, if they ever got extended.

If B forbids C would then A -> C -> D -> B also be invalid?

That would became obvious from the hypothetical explicit VU wording forbidding it.

[oddhack]

If you have concrete suggestions on phrasing the fundamentals chapter / VU statements differently we will consider them. At present the VU statements for base structures enumerate all the possible valid extension structures in the pNext chain of the base structure, specify that they must be unique in the chain, and impose no further constraints on the chain. The fundamentals section states pretty much the same thing, in a generic fashion.

[oddhack]

Also, if B forbids C, the most likely way for that to be specified is a constraint that extension-that-defines C cannot be enabled if extension-that-defines B is enabled. In that case it would be invalid to pass B and C, because one or the other extension would always have to be disabled at runtime.

If there are concrete examples of subsets of one extension's functionality being incompatible with another extension, they would be helpful to bring up (there might be, I doubt any of us has memorized all the interactions of a couple of hundred extensions - and if so, such an example will drive discussion better than hypotheticals).

[MaikKlein]

If you have concrete suggestions on phrasing the fundamentals chapter / VU statements differently we will consider them.

I think it is already worded pretty well. If anything I would add that the ordering is not important. I am a special kind of user as I generate everything from the vk.xml and I just wanted to make sure that everything that I do is correct.

Also, if B forbids C, the most likely way for that to be specified is a constraint that extension C cannot be enabled if extension B is enabled.

That is what I also assumed.

And thank you for the quick responses, I think we can close this issue.

[oddhack]

Closing per OP.