在新的Vulkan API中的所有创建信息结构（vk*CreateInfo）中，总是有一个.sType成员。如果价值只能是一件事，为什么会出现这种情况？此外，Vulkan规范非常明确，您只能使用vk*CreateInfo结构作为其相应vkCreate*函数的参数。这似乎有点多余。我可以看到，如果驱动程序将这个结构直接传递给GPU，你可能需要它（我注意到它总是第一个成员）。但对于应用程序来说，这似乎是一个非常糟糕的主意，因为如果驱动程序这样做，应用程序就不那么容易出错，而且在结构中预加int似乎不是一个计算效率极低的操作。我只是不明白它为什么存在。
TL；DR
nbsp nbsp；为什么vk*CreateInfo结构具有.sType成员？
他们有一个，所以pNext字段实际上可以工作。
是的，API接受一个具有正确C类型的结构，因此调用方和接收方都同意该结构的类型。但尤其是现在，许多这样的结构都有结构的链表，为实现提供额外的信息。这些扩展结构（尽管许多是Vulkan 1.1/2中的核心）与所有其他结构一样，都有自己的sType场。
这些字段至关重要，因为链表是用pNext指针构建的。。。它们是CCD_ 10s。它们没有集合类型。实现通过检查存储在那里的前4个字节来确定非NULL pNext指针指向的内容。这是sType字段；它允许实现知道将指针投射到什么类型。
当然，API采用的主结构并不严格需要sType字段，因为它的类型是API本身的一部分。然而，这样做是有一个假设的原因的（在Vulkan版本中没有得到证实）。
Vulkan的更高版本可以扩展命令缓冲池的创建。但它是怎么做到的呢？他们可以添加一个全新的入口点：vkCreateCommandPool2。但该函数将具有与vkCreateCommandPool几乎完全相同的签名；唯一的区别是它们采用不同的CCD_ 16结构。
因此，您所要做的就是声明一个VkCommandPoolCreateInfo2结构。然后声明vkCreateCommandPool可以取任意一个。实现如何判断您传入了哪一个？
因为任何这样的结构的前4个字节都是CCD_ 19。他们可以测试这个值。如果该值为VK_STRUCTURE_TYPE_COMMAND_POOL_CREATE_INFO，则为旧结构。如果它是VK_STRUCTURE_TYPE_COMMAND_POOL_CREATE_INFO_2，那么它就是新的。
当然，正如前面所说的，这并没有成功；1.0之后的Vulkan版本选择合并扩展结构，而不是替换现有结构。但选择是存在的。