CODEWITHSUNDEEP
vulkan
alexpanter
alexpanter

Reputation: 1578

Vulkan 1.3 Render Pass Instance clarifications

According to the spec, with Vulkan 1.3 we get access to some new (seemingly quite exciting) features, including two command buffer functions:

void vkCmdBeginRendering(VkCommandBuffer, VkRenderingInfo*);
void vkCmdEndRendering(VkCommandBuffer);

... a new enumeration:

enum VkRenderingFlagBits {
    VK_RENDERING_CONTENTS_SECONDARY_COMMAND_BUFFERS_BIT,
    VK_RENDERING_SUSPENDING_BIT,
    VK_RENDERING_RESUMING_BIT
};

And finally, we get a couple of structs (fields omitted for brevity):

struct VkRenderingInfo;
struct VkRenderingAttachmentInfo;
struct VkPipelineRenderingCreateInfo;

From reading the extension VK_KHR_dynamic_rendering (core since Vulkan 1.3):

This extension allows applications to create single-pass render pass instances without needing to create render pass objects or framebuffers. [...]

My main questions are:

There exists practically no information (that I could find) on these topics.

Upvotes: 2

Views: 624

Answers (1)

Nicol Bolas
Nicol Bolas

Reputation: 473302

The point of dynamic rendering is to be able to bypass the render pass model. So yes, if you use dynamic rendering, you can bypass the render pass model.

The principle downside is that you bypass the render pass model. They didn't create that model for no reason, after all. For tile-based renderers especially, knowing the structure of rendering can significantly improve performance in specific cases. If you're using deferred rendering with a single render pass, the implementation can fully understand how you intend to use the images. It can keep gbuffers in tile memory, sometimes for the entire render pass, which saves performance since you don't have to ever write them out to memory.

But, if you're not working with a TBR of some kind, then that doesn't really matter.

Upvotes: 3

Related Questions