Descriptor layout and update after bind validation issue

[tiago-rodrigues]

Hi,

I'm having the following error, when creating a pipeline layout which does not specify VkDescriptorSetLayoutBindingFlagsCreateInfoEXT:
"Error Code 266344388: vkCreatePipelineLayout(): sum of storage image bindings among all stages (1) exceeds device maxDescriptorSetUpdateAfterBindStorageImages limit (0). "

It looks like some HW is quite limited on 'maxDescriptorSetUpdateAfterBindStorageImages ', however still since I'm not passing VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT, it shouldn't assume it to be on.

A quick look at the core_validation.cpp shows that it is erroneously considering all sets as "update after bind" when 'false' is passed in to GetDescriptorSum().

I think what we want is something like:

bool needs_update_after_bind = (dsl->GetCreateFlags() & VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT) != 0x0;
if ( (skip_update_after_bind && needs_update_after_bind) || (only_update_after_bind && !needs_update_after_bind) ) {
            continue;
}

thanks.

[jeffbolznv]

Hi Tiago,

This code is all protected by "if (dev_data->extensions.vk_ext_descriptor_indexing)" so the extension should be enabled, and if it's enabled then it doesn't make sense for that limit to be zero. Can you confirm whether this is happening on a driver that claims to support descriptor indexing, and that the limit it reports is actually zero? Or, there might be a problem with how the extension is enabled or the limits are queried within the validation layer.

[tiago-rodrigues]

Hi Jeff,

VK_EXT_descriptor_indexing is being requested and the driver does report all members of VkPhysicalDeviceDescriptorIndexingFeaturesEXT as all '1's except for 'shaderInputAttachmentArrayDynamicIndexing' and 'shaderInputAttachmentArrayNonUniformIndexing'.

I do find that limit a bit odd (it's the only one reported as 0, at the same time as 'maxPerStageDescriptorUpdateAfterBindStorageImages' is reported as 4294967295), so maybe I'll take it up the with IHV to check if this is an expected value.
FYI the driver on another vendor is reporting that limit as '1048576'.

thanks.

[mark-lunarg]

@tiago-rodrigues, from @jeffbolznv's comment, it seems like this might be a driver issue, zero is not a valid minimum for this limit if enabled. If you feel comfortable with this, please feel free to close this issue. Thanks!

[tiago-rodrigues]

Hi Mark,

I think this is a validation issue exposed by a driver issue. I still think the validation is not doing the right thing. The validation code is indeed protected by "if (dev_data->extensions.vk_ext_descriptor_indexing)", but as it stands, the validation code assumes "VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT" is set. My initial report is for a descriptor set that has not enabled that flag.

thanks,
Tiago

[jeffbolznv]

The UpdateAfterBind limits are supposed to count sets created with or without VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT set. e.g.

  * [[features-limits-maxDescriptorSetUpdateAfterBindStorageImages]]
    pname:maxDescriptorSetUpdateAfterBindStorageImages is similar to
    pname:maxDescriptorSetStorageImages but counts descriptors from
    descriptor sets created with or without the
    ename:VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT_EXT bit
    set.

[tiago-rodrigues]

Oh my bad, missed that part in the spec, naming of that max param is a bit confusing.
I'll close this and will wait for a new driver with the correct max value.
thank you.