Creating pipeline layouts with descriptors fails on Raspberry Pi 4 and 5 when Vulkan 1.2 is used

[dbartussek]

The Raspberry Pi 4 and 5 are one of the very few devices that support Vulkan 1.2, but do not support UpdateAfterBind and have maxDescriptorSetUpdateAfterBind* = 0 as a result.

The pipeline layout validation currently assumes that the maxDescriptorSetUpdateAfterBind limits must always be respected in addition to the base limits if they are reported:

vulkano/vulkano/src/pipeline/layout.rs

Line 781 in 6ff349a

let limit_all = match (limit.get_limit_all)(properties) {

As a result, creating a PipelineLayout with any descriptors always fails this check when using Vulkan 1.2 or above on a Raspberry Pi.

[Rua]

In the Vulkan spec, VkPipelineLayoutCreateInfo doesn't make any allowance for these values being 0. That means that technically Vulkano is correct in applying this rule, and it's really the Vulkan drivers on the Pi that are not compliant.

[marc0246]

I think the issue is about the fact that these devices don't support any of the descriptor indexing features, yet we are validating their limits (it wasn't really clear from the issue description).

[Rua]

VkPhysicalDeviceDescriptorIndexingProperties is supported for Vulkan 1.2, so Vulkano is querying the properties. The problem is that the driver is actually returning VkPhysicalDeviceDescriptorIndexingProperties with zero values, which is not a case that the Vulkan spec accounts for. For example, VUID-VkPipelineLayoutCreateInfo-pSetLayouts-03036 says that this limit must always be respected if available, there is nothing that says it can be ignored if a feature isn't supported or used.

[marc0246]

Then that sounds like an issue to be filed for the spec to clarify that.

[marc0246]

Issue: KhronosGroup/Vulkan-Docs#2515

[dbartussek]

Based on how I am reading the required limits section, where Table 69 has a footnote 9 on each of the minimum values for each maxPerStageDescriptorUpdateAfterBind*, I'd say that the devices reporting 0 are already wrong because the footnote says The UpdateAfterBind descriptor limits must each be greater than or equal to the corresponding non-UpdateAfterBind limit..

So now I agree with Rua that the spec is already clear on this and it is a driver bug. I also think however that working around this won't break any compliant devices (because these limits should really always be at least as much as the normal ones) and hoping that Broadcom and ImgTec fix their drivers isn't a practical solution. We should definitively still report it to them through Khronos, but using the workaround will get vulkano running on the affected devices today instead of hopefully in some years after a driver update that may never be installed.

[marc0246]

We're not in the business of fixing driver bugs. There's a huge number of them and imagine if we humored everyone. If you want to work around it, you can use PipelineLayout::new_unchecked.

[marc0246]

The verdict was that this is a spec bug and the limits should only apply if the layout enables update after bind (which makes more sense than what I thought the spec bug was), but I'm still unclear on the concrete wording.