sType not properly set internally for some functions

[Karvie0]

Context:

• Zig: 0.15.1
• vulkan-zig commit: bef498b (latest as of writing)
• Vulkan headers: v1.4.328 (latest as of writing)
• Instance was created targeting vulkan API v1.2

Calling any of the below functions on an instance proxy results in validation errors:

getPhysicalDeviceQueueFamilyProperties2Alloc errors on every element. I've copied only the first:

vkGetPhysicalDeviceQueueFamilyProperties2(): pQueueFamilyProperties[0].sType must be VK_STRUCTURE_TYPE_QUEUE_FAMILY_PROPERTIES_2.
The Vulkan spec states: sType must be VK_STRUCTURE_TYPE_QUEUE_FAMILY_PROPERTIES_2 (https://docs.vulkan.org/spec/latest/chapters/devsandqueues.html#VUID-VkQueueFamilyProperties2-sType-sType)

getPhysicalDeviceMemoryProperties2 leads to:

vkGetPhysicalDeviceMemoryProperties2(): pMemoryProperties->sType must be VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MEMORY_PROPERTIES_2.
The Vulkan spec states: sType must be VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MEMORY_PROPERTIES_2 (https://docs.vulkan.org/spec/latest/chapters/memory.html#VUID-VkPhysicalDeviceMemoryProperties2-sType-sType)

getPhysicalDeviceProperties2 leads to:

vkGetPhysicalDeviceProperties2(): pProperties->sType must be VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PROPERTIES_2.
The Vulkan spec states: sType must be VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PROPERTIES_2 (https://docs.vulkan.org/spec/latest/chapters/devsandqueues.html#VUID-VkPhysicalDeviceProperties2-sType-sType)

Each of these functions are part of core since Vulkan 1.1, and are recommended against their 1.0 counterparts. These are the only functions with a 2 in the name that I've tried. I imagine this problem exists on other functions as well.

[Karvie0]

when I tried updating vulkan-zig, it made a new entry in my build.zig.zon file, so it was actually still using an older version. I'm going to test with the new version, but I have to install zig master first

Edit: zig master doesn't want to work nicely right now, and opensuse doesn't package lld correctly for me to compile a different version, so this is going to have to wait

[Snektron]

I can reproduce the errors for getPhysicalDeviceMemoryProperties2 and getPhysicalDeviceQueueFamilyProperties2Alloc. I guess problem is that the Alloc-style functions must provide pre-initialized structures to Vulkan. Currently all alloc-style are following the VK1.0 convention for querying parameters. Not really sure what the best solution is, but I guess its to either remove the Alloc-style functions for the VK1.1 style query functions or to use some comptime magic to specify a pNext chain and then return a more informative structure. For now, at least for you, I suggest to use either use the non-alloc variant or to just use the VK1.0 function.

I couldn't reproduce the problem for getPhysicalDeviceProperties2. For this case, make sure that the structure you're passing to getPhysicalDeviceProperties2 is initialized using its default, for example,

var props2: vk.PhysicalDeviceProperties2 = .{
    .properties = undefined,
};
gc.instance.getPhysicalDeviceProperties2(gc.pdev, &props2);

[Karvie0]

For getPhysicalDeviceQueueFamilyProperties2Alloc, adding a line like this between allocating and populating data in the body of the wrapper function seems to work just fine:

@memset(data, vk.QueueFamilyProperties2{ .queue_family_properties = undefined });

This would mean that the p_next value is always set to null. I don't know much about the use cases where p_next should be a non-null value, but it seems to have to do with extension specific structures. Leaving it as null and expecting people to use the non-alloc style function for more advanced use cases seems reasonable to me, but I'm not sure if that's what you're going for or with the design of these helper functions.

And yes, doing a simple init before calling the non-alloc ones like you mentioned also works.