Ok, so my next topic is render passes. As far as I can tell a render pass defines the attachments and their types used in subsequent rendering while the subpasses defines the different subsets of these attachments the render calls might use, right? Some questions:
There are only color and depth stencil attachments, right?
Is there a reason in a pure render application not just to define exactly one render pass that has all the attachments I might ever need and then just select subsets of it using subpasses?
You can use a resolve attachment, but by default color attachment only. For depth stencil resolving should use VK_KHR_depth_stencil_resolve
It depends of your task, any way the current render pass must be compatible with the renderPass member of the VkGraphicsPipelineCreateInfo structure specified when creating the VkPipeline bound to VK_PIPELINE_BIND_POINT_GRAPHICS
I don’t understand your question. You use multiple render passes when a single render pass is insufficient for doing what you’re trying to do. That is, when the limitations of a render pass force you to.
For example, you cannot arbitrarily read from any image attached to a render pass instance during that instance. If that’s something you need to do, and the input attachment mechanism is too limited to do what you need to do, then you must use another render pass.
My scenario is that I set off a number of drawcalls to one texture buffer, then a number of drawcalls to a different texture buffer. Finally, the two texture buffers become inputs to another drawcall that writes into a third texture buffer. A texture buffer is either input or output but never both at the same time.
Is one render pass sufficient for this? If no, at which point would I have to create another render pass to make the adjustments I need?
I don’t know what you mean by a “texture buffer”. Do you just mean a “texture” (aka: a VkImageView)? Or are you referring to the Vulkan equivalent to OpenGL buffer textures (which are VkBufferViews, and cannot be rendered to)?
Also, the specification lays out the various restrictions on render passes. You should look into them and apply them to your situation.
But the validation layer gives the following error:
vkDebug: Validation: 0: Validation Error: [ VUID-vkCmdClearColorImage-image-00002 ] Object 0: handle = 0x40000000004, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0x636f8691 | vkCmdClearColorImage() pRanges[0] called with image VkImage 0x40000000004[] which was created without VK_IMAGE_USAGE_TRANSFER_DST_BIT. The Vulkan spec states: image must have been created with VK_IMAGE_USAGE_TRANSFER_DST_BIT usage flag (https://vulkan.lunarg.com/doc/view/1.2.154.0/linux/1.2-extensions/vkspec.html#VUID-vkCmdClearColorImage-image-00002)
The code for setting up the VkImage objects is the same as for the swapchain images in the Vulkan Tutorial example 15:
Is there any reason why one shouldn’t clear swapchain images this way?
In other words you are using your swapchain image in a way that requires the image to be created with the VK_IMAGE_USAGE_TRANSFER_DST_BIT as a usage. Looking at your swapchain creation there is:
Which is the equivalent of you promising that the only thing you will do with a swapchain image is render into it. If you want to use vkCmdClearColorImage on a swapchain image you need to additionally specify the VK_IMAGE_USAGE_TRANSFER_DST_BIT.
This has nothing to do with render passes, so I don’t know why you asked this question in this thread.
That having been said, swap chain images do not belong to your program. They belong to the OS’s display engine, and you request to be able to use them. But you can only use them in accord with whatever rules the display engine allows you to.
When you called vkGetPhysicalDeviceSurfaceCapabilitiesKHR, among the values you get is the VkSurfaceCapabilitiesKHR::supportedUsageFlags flag field. This is a bitmask of VkImageUsageFlagBits values that informs you of the ways you can use swap chain images.
And the only usage that Vulkan requires that all implementations provide is VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT. That is, if you want to do anything with a swap chain image other than operations with it as a color attachment of a render pass instance, or presenting it to the display device, you must first check this bitmask to see if the implementation allows that usage.
vkCmdClearColorImage requires that the image it is given support the VK_IMAGE_USAGE_TRANSFER_DST_BIT usage. Your implementation clearly does not allow that usage for swap chain images; hence the error.
So you cannot use that command on such swap chain images. You’ll have to clear them the way normal people clear them: as part of the load op for the render pass.
I’m currently learning and I have questions about the steps I work through. I’m concerned that I spam the forum too much if I create a separate topic for every question.
So you think that the person who created that example was just lucky that it worked this way for them?
OK, but it would really be better to take some time to read through the specification. It’s really not a good idea to try to learn Vulkan by grabbing random code online and looking at it.
Nowhere in the code you linked to was the function vkCmdClearColorImage ever called.
As previously stated, you should not post unrelated questions to a thread like this. Also, please read the specification before asking questions that can be answered with a link. Don’t use this forum as an alternative to documentation.