Creating VK Device fails on a vkEnumeratePhysicalDeviceGroups() call

[maaxxaam]

Tried to compile the library with validation layers on Linux with GCC 14.2.1 and kept running into the following error during device creation:

nri::ERROR (DeviceVK.hpp:1249) - VK::Unknown - Validation Error: 
[ VUID-VkPhysicalDeviceGroupProperties-sType-sType ] | MessageID = 0xc9edee8b | 
vkEnumeratePhysicalDeviceGroups(): pPhysicalDeviceGroupProperties[0].sType must be VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_GROUP_PROPERTIES. 
The Vulkan spec states: sType must be VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_GROUP_PROPERTIES 
(https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-VkPhysicalDeviceGroupProperties-sType-sType)

that happens on line 415 in DeviceVK.hpp:

/* 411 */ uint32_t deviceGroupNum = 0;
/* 412 */ m_VK.EnumeratePhysicalDeviceGroups(m_Instance, &deviceGroupNum, nullptr);
/* 413 */ 
/* 414 */ Scratch<VkPhysicalDeviceGroupProperties> deviceGroups = AllocateScratch(*this, VkPhysicalDeviceGroupProperties, deviceGroupNum);
/* 415 */ VkResult result = m_VK.EnumeratePhysicalDeviceGroups(m_Instance, &deviceGroupNum, deviceGroups);
/* 416 */ RETURN_ON_FAILURE(this, result == VK_SUCCESS, GetReturnCode(result), "vkEnumeratePhysicalDevices returned %d", (int32_t)result);

As far as I understand, that seems to happen because memory allocated on line 414 is not default constructed and thus filled with garbage data, causing validation layers to throw an error when checking their contents (despite those values not being used since they're about to be overriden anyway?). Manually settings sType and pNext fields in an array before the call seems to fix the issue:

            uint32_t deviceGroupNum = 0;
            m_VK.EnumeratePhysicalDeviceGroups(m_Instance, &deviceGroupNum, nullptr);

            Scratch<VkPhysicalDeviceGroupProperties> deviceGroups = AllocateScratch(*this, VkPhysicalDeviceGroupProperties, deviceGroupNum);
+           uint32_t i = 0;
+           for (; i < deviceGroupNum; i++) {
+               deviceGroups[i].sType = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_GROUP_PROPERTIES;
+               deviceGroups[i].pNext = NULL;
+           }
            VkResult result = m_VK.EnumeratePhysicalDeviceGroups(m_Instance, &deviceGroupNum, deviceGroups);

However, I have not encountered such an error while using the library before and other machines seem to work fine... Could it be a some sort of misconfiguration on my part? Might there be a better solution?

[dzhdanNV]

(sorry, was on vacation) It's a strange situation, because EnumeratePhysicalDeviceGroups actually initializes passed memory, including sType and pNext. Why does it happen? What's the problematic config - Windows or Linux? Which VK SDK version?

P.S. Wanna understand better the context. I don't mind to just take "the fix", but it should be unnecessary.

[dzhdanNV]

OK, I have convinced myself that sType and pNext must be initialized by looking at the doc for VkPhysicalDeviceGroupProperties and some random repos. But why does it work without the fix almost everywhere? :)

[dzhdanNV]

Fixed in two places and committed. Thanks!

[maaxxaam]

Which VK SDK version?

It's a bit harder to make sense of it on Arch, but I believe its 1.3.295. Here are the versions for the vulkan-devel packages:

[maaxxaam@Maaxxaam ~]$ pacman -Qs vulkan-devel
local/spirv-tools 2024.2-1 (vulkan-devel)
    API and commands for processing SPIR-V modules
local/vulkan-extra-layers 1.3.250.0-1 (vulkan-devel)
    Extra layers for Vulkan development
local/vulkan-extra-tools 1.3.250.0-1 (vulkan-devel)
    Vulkan lunarg tools
local/vulkan-headers 1:1.3.295-1 (vulkan-devel)
    Vulkan header files
local/vulkan-html-docs 1:1.3.279-1 (vulkan-devel)
    Vulkan html documentation
local/vulkan-tools 1.3.269-1 (vulkan-devel)
    Vulkan Utilities and Tools
local/vulkan-utility-libraries 1.3.295-1 (vulkan-devel)
    Vulkan Utility Libraries
local/vulkan-validation-layers 1.3.290-2 (vulkan-devel)
    Vulkan Validation Layers

Should you need any additional information, let me know.

[dzhdanNV]

I see. Thanks. No additional info needed. Really, looks like violation of the spec.