Vulkan driver bug: vkCreateDescriptorSetLayout fails when bindingCount=0 & flags=VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR

[AKapo3]

The spec doesn't seem to suggest that creating empty descriptor set layouts is invalid when using push descriptors; it's mostly pointless but should still work.

On Intel Vulkan drivers, this does work when *not* using push descriptors, but when push descriptors are enabled with the VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR flag, descriptor set layout creation fails with error -1. FWIW the driver throws VK::Exception object during this call, which I'm guessing is caught and converted to a return code.

This happens with driver 15.60 on Intel HD Graphics 520; Vulkan-reported driver version is 0x10002, DXDiag reported version is 23.20.16.4901 (12/17/2017).

[AKapo3]

Also, attempting to work around this by using one binding with stageFlags=0 (binding = 0, descriptorCount = 1, descriptorType = VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER) crashes during vkCreateDescriptorSetLayout inside igvk32.dll when dereferencing a NULL pointer.

[idata]

zeuxcg: Thank you very much for contacting the Intel® Graphics communities. We will do our best to assist you with this scenario.

We will try to replicate this issue in our lab, in order for us to be able to do that, please provide the information requested on the link below:/message/319025 https://communities.intel.com/message/319025 Any further questions, please let me know. Regards,Alberto R

[AKapo3]

Alberto, please find the requested files attached.

[idata]

zeuxcg: Thank you very much for providing that information.

Could you please fill the chart as well with the steps we need to follow so we can try to replicate the issue? Any questions, please let me know. Regards,Alberto R

[AKapo3]

To reproduce the first (main) problem, it should be sufficient to run this code:

VkDescriptorSetLayoutCreateInfo layoutInfo = {};

layoutInfo.sType = VK_STRUCTURE_TYPE_DESCRIPTOR_SET_LAYOUT_CREATE_INFO;

layoutInfo.flags = VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR;

VkDescriptorSetLayout result = 0;

VkResult result = vkCreateDescriptorSetLayout(device, &layoutInfo, nullptr, &result);

This will fail whereas it should succeed; the instance/device needs to be initialized with VK_KHR_push_descriptor and VK_KHR_get_physical_device_properties2 extensions.

To reproduce the second problem - which was my attempt to work around this; I *believe* this should be valid but not 100% sure about this one - it should be sufficient to run this code:

VkDescriptorSetLayoutBinding binding = {};

binding.binding = 0;

binding.descriptorCount = 1;

binding.descriptorType = VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER;

binding.stageFlags = 0;

VkDescriptorSetLayoutCreateInfo layoutInfo = {};

layoutInfo.sType = VK_STRUCTURE_TYPE_DESCRIPTOR_SET_LAYOUT_CREATE_INFO;

layoutInfo.flags = VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR;

layoutInfo.bindingCount = 1;

layoutInfo.pBindings = &binding;

VkDescriptorSetLayout result = 0;

VkResult result = vkCreateDescriptorSetLayout(device, &layoutInfo, nullptr, &result);

[idata]

zeuxcg: Thank you very much for sharing all those details. We will do further research on this matter, as soon as I get any updates I will post all the details on this thread.

Any questions, please let me know. Regards,Alberto R

[RonaldM_Intel]

Hello zeuxcg

Thank you for all your feedback. I would like to confirm that an internal bug report has been filed [Bug ID 1406773539]

I'll post here as soon as I have any news or updates.

Best Regards,

Ronald M.

[RonaldM_Intel]

Hello zeuxcg,

Thank you for your patience. I have an update from our development team.

We successfully reproduced the first(main) issue, and I can confirm it will be fixed in a future driver release.

We couldn't reproduce the second issue i.e. workaround - vkCreateDescriptorSetLayout() does not crash for us (creates valid object and returns VK_SUCCESS). However, setting stage flag to 0 is incorrect, specification says that: "If descriptorCount is not 0, stageFlags must be a valid combination of VkShaderStageFlagBits values".

Could you please provide us the exact block of code (with fixed stage flags) that causes the crash on your machine? This should help us debug it further.

Best Regards,

Ronald M.

[AKapo3]

Hi Ronald,

My understanding is that 0 is a valid combination of bit flag values. For example, in vkCmdSetEvent VU you can find:

• stageMask must be a valid combination of https://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.html# VkPipelineStageFlagBits VkPipelineStageFlagBits values
• stageMask must not be 0

Note that it explicitly spells out 0 as an invalid value to use. Additionally, in VkDescriptorLayoutBinding VU, you can see:

• If descriptorCount is not 0, stageFlags must be a valid combination of https://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.html# VkShaderStageFlagBits VkShaderStageFlagBits values
• If descriptorType is VK_DESCRIPTOR_TYPE_INPUT_ATTACHMENT and descriptorCount is not 0, then stageFlagsmust be 0 or VK_SHADER_STAGE_FRAGMENT_BIT

Note the last point - it says 0 is valid as well.

I will try to make a standalone repro for this and get back to you.

[AKapo3]

Hi Ronald,

I am indeed unable to reproduce the driver crash for stageMask=0 Unfortunately I don't have the original workaround source code and in a standalone sample layout creation with 1 stageMask=0 descriptor works as expected with or without push descriptors. Let's assume for now that this was a user error; if we hit it again I can create another thread.

[RonaldM_Intel]

Hi again,

Thank you for your help. I passed on your feedback to our development team.

As soon as I have details on the next driver that includes the fix for this issue I'll update this thread.

Best Regards,

Ronald M.

[RonaldM_Intel]

Hello zeuxcg,

I would like to let you know that the fix for this issue is already included in driver https://downloadcenter.intel.com/download/27650 15.65.5.4982 and any newer.

In case you try it out and have any feedback we'll surely appreciate it.

Best Regards,

Ronald M.