Input attachment and descriptor binding

Hi all. I am a beginner in graphics API and I’m learning vulkan. I have a few questions please help

1.about Vulkan input attachments and sub passes
If there is only the sample1 and in shader code i can get the color.view by layout (binding = 0) .It is ok.

        VkFramebufferCreateInfo frameBufferCI{};
		frameBufferCI.renderPass = renderPass;
		frameBufferCI.attachmentCount = 3;
		frameBufferCI.pAttachments = views;
		frameBufferCI.width = width;
		frameBufferCI.height = height;
		frameBufferCI.layers = 1;

		for (uint32_t i = 0; i < frameBuffers.size(); i++)
			views[0] = swapChain.buffers[i].view;
			views[1] = attachments[i].color.view;
			views[2] = attachments[i].depth.view;
			VK_CHECK_RESULT(vkCreateFramebuffer(device, &frameBufferCI, nullptr, &frameBuffers[i]));

If there is only the sample2 and in shader code i can get the color.view by layout (input_attachment_index = 0) .It is ok too.


std::vector<VkDescriptorImageInfo> descriptors = {
			vks::initializers::descriptorImageInfo(VK_NULL_HANDLE, attachments[index].color.view, VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL),
			vks::initializers::descriptorImageInfo(VK_NULL_HANDLE, attachments[index].depth.view, VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL)

But when these two pieces of code are put together and the shader code is as follows, I get very confused. Why specify the same underlying resource twice in different ways. This feels repetitive and increases the chance of errors due to inconsistent parameters.

shader code

layout (input_attachment_index = 0, binding = 0) uniform subpassInput inputColor;
layout (input_attachment_index = 1, binding = 1) uniform subpassInput inputDepth;

2.When we wrote code in the past, if we needed a member already included in the parameter, we would try to get this member from the parameter through the interface instead of specifying the same parameter again, so as to avoid repetition and potential inconsistency. But in the process of learning vulkan, I often encounter situations where I need to repeatedly set certain parameters, which makes me feel very distressed, because sometimes I don’t understand the intention.

Long version

Short version: Different hardware may access input attachments through different means. Some hardware may not treat it as a sampler (and therefore it doesn’t count against sampler limits); other hardware may treat it as a sampler. And sometimes what turns one into the other isn’t hardware; it’s some arbitrary rendering pattern that there’s no way to effectively communicate to the user. That is, what and how much you render might switch from one to the other.

So the system has to be designed to account for this, and it does so by making you specify both.

Vulkan is an explicit API; it doesn’t (generally) remember stuff. It’s your job to remember stuff and tell that to Vulkan whenever it may be relevant.

Thanks, it became clear for me to understand the problem.