Thu
06
Apr 2017
One of the reasons why new generation graphics APIs (DirectX 12 and Vulkan) are so complicated, is that they have so many levels of indirection in referring to anything. For example, when you render pixels to a color attachment (also known as “render target” in other APIs), the path is as follows:
outColor = vec4(1.0, 0.0, 0.0, 1.0);
layout(location = 0) out vec4 outColor;
VkSubpassDescription::pColorAttachments
- member of the structure that describes rendering subpass.VkAttachmentReference::attachment
provides another INDEX, this time to an array pointed by VkRenderPassCreateInfo::pAttachments
- member of the structure that describes rendering pass.VkAttachmentDescription
provide just few parameters, like format.VkFramebufferCreateInfo::pAttachments
- member of a structure filled when creating a framebuffer that is going to be pointed by VkRenderPassBeginInfo::framebuffer
when starting actual execution of the render pass.VkImageView
, so each of them is a VIEW to an image, pointed by VkImageViewCreateInfo::image
- member of a structure used when creating the view.VkImage
) is either obtained from swap chain using function vkGetSwapchainImagesKHR
, or created manually using function vkCreateImage
.VkDeviceMemory
) with function vkAllocateMemory
and bind its fragment to the image using function vkBindImageMemory
. This is the memory that will be actually written.Yeah, Vuklan is hard…
Comments | #vulkan #graphics Share