vulkan-tutorial | vulkan-tutorial with python | Learning library

A layout transition is exactly what those words mean. It's when you transition the layout of an image sub-resource from one layout to another. So your question really seems to be... what is a layout?

In the Vulkan abstraction, images are composed of sub-resources. These represent distinct sections of an image which can be manipulated independently of other sections. For example, each mipmap level of a mipmapped image is a sub-resource.

At any particular time an image sub-resource is being used by a GPU process, that sub-resource has a layout. This is part of the Vulkan abstraction of GPU operations, so exactly what it means to the GPU will vary from chip to chip.

The important part is this: layouts restrict how you can use an image sub-resource. Or more to the point, in order to use an image sub-resource in a particular way, it must be in a layout which permits that usage.

When a sub-resource is in the VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL layout, you can only perform operations which read from the sub-resource within a shader. The shader cannot write to the image, nor can the image be used as a render target.

Now, the general layout allows pretty much any use. However, this also can represent less optimal performance. Any of the more restricted layouts can make those accesses to the image more performance-friendly (depending on hardware).

So it is your job to keep track of the layout of any image sub-resources you plan to use. Now for most images, you're going to use destination transfer layout to upload to them, and then just leave them as shader read-only, because you don't generally use most images more arbitrarily. So generally, this means keeping track of render targets that you want to read from, as well as swapchain images (you have to transition them to the present layout before presenting them).

Layout transitions typically happen as part of an explicit dependency between two operations. This makes sense; if you're uploading data to an image, and you later want to read from it, you need a dependency between the upload and the read. You may as well do the layout transition then, since the transition can modify the way the bytes of the image are stored, so you need the transfer to be done first.

I finally found the problem: I was destroying the shader modules too early. Looks like you have to keep the shader modules alive ultil after you have created the pipeline.

This is the fixed code

i fixed the problem. problem was that i want to use half float but i was sending float to memcpy function.i searched how can i use half float and i found a solution without using extra library.

what i did add helper functions :

To fix the issue I went into my Linker > Input > Additional Dependencies and checked the box that says "Inherent from parents or project defaults" and it now compiles without any errors.

Sometimes, tutorials do not use proper wording. This is one of those times.

Recall that a pipeline is built against a specific subpass of a specific render pass. Also recall that subpasses have a list of (among other things) color attachments that represent the render targets for rendering operations in that subpass.

What the tutorial means is that VkPipelineColorBlendAttachmentState defines the blend state for a particular attachment in the subpass designated by the pipeline. The array of VkPipelineColorBlendAttachmentState structs mirrors the array of color attachments used in the subpass the pipeline is being built for. So the third element of VkPipelineColorBlendStateCreateInfo::pAttachments corresponds to the third element in VkSubpassDescription::pColorAttachments for the subpass the pipeline is being built for.

For some reason, this tutorial refers to these attachments as "attached framebuffer," as this is absolutely the wrong term to use. They're just attachments.

Framebuffers provide the images that will be used as attachments when you begin a render pass. But the pipeline doesn't (really) care what image object you use. It cares about what color attachment in the subpass you're talking about.

You need a descriptor set layout before you write to a descriptor set for the same reason you need a class before you can instantiate it. You can't do A a; for some type A before you define what A is. VkWriteDescriptorSet is like doing a.x = whatever; it doesn't make sense until you know what a is, and that requires having the class definition for A.

Descriptor set layouts define what a descriptor set looks like. It specifies all of the things that go into one. vkAllocateDescriptorSets is how you create an instance of a descriptor set layout (in our analogy, it's A a;, with the set being a). VkWriteDescriptorSet is how you provide the data that goes into a descriptor set (in our analogy, it's like a.x = whatever;, only potentially for multiple members).

VkWriteDescrptorSet has a lot of data that is redundantly specified in the descriptor set layout so that the implementation does not have to store the set layout as raw data.

Let's say that binding 2 in a descriptor set is a UBO of length X. And you want to attack a buffer range to that UBO descriptor. To do that, the implementation may need to know that it is a UBO descriptor and what its length is. If it does need to know that, then it would also need to store that information inside the descriptor set.

That forces the implementation to store extra data that's only useful for writing to the descriptor. If that descriptor is only set once and never again or otherwise modified infrequently (as descriptors often are), the implementation has to keep a bunch of information around for no reason.

So Vulkan makes you decide whether to keep the information around or not.

A graphic pipeline does not "hold" a render pass at all. It is created with respect to a render pass:

renderPass is a handle to a render pass object describing the environment in which the pipeline will be used; the pipeline must only be used with an instance of any render pass compatible with the one provided.

Specifically, it is created with respect to a subpass of a render pass (also a field of VkGraphicsPipelineCreateInfo). You can only use a graphics pipeline when a render pass instance compatible with renderPass is active and when the given subpass of that render pass is active.

Subpasses determine which render pass attachments will be rendered to by any rendering operation. So the fragment shader outputs are routed to the active attachments, as specified in the render pass's subpass data for that subpass.

Draws happen with respect to whatever graphics pipeline is current, and render to the attachments specified by the graphics pipeline's outputs and routed to the attachments for the current subpass of the current render pass instance.

0 access mask means "nothing". As in, there is no memory dependency the barrier introduces.

Implicit synchronization means Vulkan does it for you. As the tutorial says:

One thing to note is that command buffer submission results in implicit VK_ACCESS_HOST_WRITE_BIT synchronization

Specifically this is Host Write Ordering Guarantee.

Implicit means you don't have to do anything. Any host write to mapped memory is already automatically visible to any device access of any vkQueueSubmit called after the mapped memory write.

Explicit in this case would mean to submit a barrier with VK_PIPELINE_STAGE_HOST_BIT and VK_ACCESS_HOST_*_BIT.

Note the sync guarantees only work one way. So CPU → GPU will be automatic\implicit. But GPU → CPU always need to be explicit (you need a barrier with dst = VK_PIPELINE_STAGE_HOST_BIT to perform memory domain transfer operation).

You are enabling Debug Report extension, but then you try using Debug Utils messenger instead.