Why do input attachments need a descriptor set to be bound?

VkRenderPassCreateInfo contains the attachment indices used for Depth, Color and Input attachments. The corresponding image views are referenced in VkFramebufferCreateInfo in pAttachments. In the shader “input_attachment_index” identifies which input attachment the shader is using. Given that the framebuffer is bound during rendering, which should allow identification of the image view to be used for the input attachment, the same way it does for depth and color attachments.

I do not understand why Vulkan also requires mentioning the input attachment (but not other attachments) in descriptor set layouts and consequently in the bound descriptor set.

I feel like I am missing something here? What is it about input attachments that necessitates binding descriptors?

The same question was also asked here, I’ll try to mirror whatever comes out of it: https://stackoverflow.com/questions/43632903/vulkan-why-do-input-attachments-need-a-descriptor-set-to-be-bound

I believe it’s because some drivers treat input attachments exactly like normal images to be read while others (tile based renderers) treat it specially.

So the first type of driver can ignore the input attachments of the subpass and only look at the descriptor sets for image samplers.

The stackoverflow link contains a fairly extensive answer now. My takeaway is that set layouts should include input attachments to prevent compatibility of descriptor sets across pipelines with different numbers of input attachments. Since passing descriptors may incur costs of some kind, this is interesting for hardware that would otherwise have to autogenerate descriptors to implement input attachments.