Vulkan-docs: Optionalness and validity in VkAccelerationStructureBuildGeometryInfoKHR

[expipiplus1]

• Should VkAccelerationStructureBuildGeometryInfoKHR->mode be marked as optional? It is ignored when this structure is passed to getAccelerationStructureBuildSizesKHR so it seems a little odd to require a value there. There is precedent for this "conditional" optional, for instance in the same struct only one of srcAccelerationStructure and dstAccelerationStructure can be VK_NULL_HANDLE yet they're both marked as optional.

• Should the (implicit) valid usage statements on nullability for srcAccelerationStructure and dstAccelerationStructure (If {src,dst}AccelerationStructure is not NULL_HANDLE, {src,dst}AccelerationStructure must be a valid AccelerationStructureKHR handle) include language excluding this statement if the structure is being passed to getAccelerationStructureBuildSizesKHR?

[dgkoch]

Should VkAccelerationStructureBuildGeometryInfoKHR->mode be marked as optional?

What would that mean? It's not a pointer, so it must be _some_ value.

I'm not sure I see the benefit of allowing random uninitialized values to be provided for mode / srcAccelerationStructure / dstAccelerationStructure. If you zero init your VkAccelerationStructureBuildGeometryInfoKHR structure declaration with {}, you'll should automatically get mode = 0 (which is VK_BUILD_ACCELERATION_STRUCTURE_MODE_BUILD_KHR -- a valid mode ) and VK_NULL_HANDLE for both acceleration structures.

[expipiplus1]

True, in fact there's only one place in the spec so far when an enumeration is marked optional VkDeviceMemoryReportCallbackDataEXT->objectType, and I suppose in that case it means VK_OBJECT_TYPE_UNKNOWN.

You've convinced me that this issue is unproductive pedantry :) Thanks for taking the time to explain.

[oddhack]

True, in fact there's only one place in the spec so far when an enumeration is marked optional VkDeviceMemoryReportCallbackDataEXT->objectType, and I suppose in that case it means VK_OBJECT_TYPE_UNKNOWN.

I'll take a look at that. "optional" is only defined (in the registry schema document) to be meaningful for pointer, handle, bitmask, and array size parameters so this sounds like a mistake or unsanctioned assumption.

[oddhack]

There are some changes in the optional / noautovalidity attributes in the 1.2.165 spec update that hopefully will address the immediate problem. There are some pending updates to the description of optional that should help clarify its meaning and applicability, although that's backed up behind a bunch of minor tweaks to the XML and VUs needed to be consistent with that language so may take a while.