Skip to content

Add VK_KHR_dynamic_rendering Support #32

@SpinnerX

Description

@SpinnerX

Background

This task is to keep track of the progress of providing vulkan-cpp to support dynamic rendering capabilities.

To learn more in-depth information refer to this link.

The tl;dr is dynamic rendering remove the need to bake in the renderpass handle into the graphics pipeline. This also removes the need to rely on the application developer to manage the renderpass states.

Which has been a known issue regarding setting up and extra requirements of the developer who may not need specific configurations.

Here are issues addressed (copied from that link):

  • Other APIs have much more flexible APIs for the same functionality
  • Most of the render pass API in Vulkan goes unused
  • Most applications do not or cannot use subpasses, but still pay the cost of setting them up
  • The API does not fit into most existing software architectures
  • Fundamentally, other than load/store actions, they do not address real issues for IHVs or ISVs
  • When teaching Vulkan as an API, this is a huge place where people trip up

About Dynamic Rendering

Dynamic rendering is part of the modern Vulkan API's. Which addresses some of the notable API designs which is to be less invasive to other handles.

Focusing in decoupling from having an invasive requirement of the renderpass handle and only have the renderpass handle be effective when you need to record information to the command buffer.

Before vs After Dynamic Rendering Workflow Comparison

Traditionally

This is how you'd have to keep track of the renderpass handle. This means for every renderpass, you'd need to keep track of the VkFramebuffer handle as well.

If your renderpass ever becomes invalidated, then the framebuffer and the pipeline with that specific renderpass baked into it needs to be invalidated altogether.

1.) Create RenderPass Handle: Define color/depth attachments, subpass dependencies.
2.) Create FrameBuffer Handle: Uses RenderPass
3.) Create Pipeline -- Bake RenderPass Handle: Bakes rendepass to graphics pipeline
4.) vkCmdBeginRenderPass: Finally, invoking begin API to record using those objects.

Using Dynamic Rendering

Dynamic rendering would remove the need to manage so many states (VkFrameBuffer, VkRenderpass). Rather to be supplied to the VkRenderingInfo struct to perform the same operation just removing managing those different states.

Providing a simpler workflow.

1.) VkRenderingInfo Struct: Remove any need of the VkRenderPass handles
2.) vkCmdBeginRendering

Dynamic Rendering Setup in Vulkan

This is a brief of how the setup for dynamic rendering would work in Vulkan.

// specify color and depth attachments (if we did for layout = 0 and layout = 1)
std::array<VkAttachmentReference, 2> color_attachments = {...};

VkAttachmentReference depth_attachment = {....}

// specifying the rendering attachment
VkRenderingAttachmentInfo rendering_attachment = {
    .renderArea = {},
    .layerCount = 1,
    .colorAttachmentCount = static_cast<uint32_t>(color_attachments.size()),
    .pColorAttachments = color_attachments.data(),
    .pDepthAttachments = &depth_attachment,
    .pStencilAttachment = nullptr
};

// this is to bind and make draw calls between these API calls
vkCmdBeginRendering(command, &render_attachment);

Proposal API

This is what I have plans for what the API support for dynamic rendering looks like.

vk::command_buffer current = /* .... */;

std::array<vk::rendering_attachment, 1> render_attachments = {
     vk::rendering_attachment{
          .image_view = /* specify */,
          .load = /* specify */,
          .store = /* specify */,
          .clear = /* specify */
     },
};

std::array<vk::rendering_attachment, 1> depth_attachments = {
     vk::rendering_attachment{
          .image_view = /* specify */,
          .load = /* specify */,
          .store = /* specify */,
          .clear = /* specify */
     },
};

// Configuring renderpass instances (color/depth attachments)
vk::rendering_begin_parameters rendering_params= {
     . render_area = /* specify */, // {x, y}
     .layout_count = 1,
     .color_attachments  = color_attachments,
     .depth_attachments = depth_attachments,
     .stencil_attachments = {}, // just add this because its optional; default to nothing
};

// vk::command_buffer::begin_rendering
current.begin_rendering(rendering_params);



current.end_rendering(rendering_params);

Metadata

Metadata

Assignees

Labels

💠coreCritical tasks are reserved for maintainers during fundamental architectural changes.📐designTasks that involve the core systems. Highly involve in API design.
No fields configured for Feature.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions