Vulkan的render pass理解

Vulkaning

已于 2024-03-16 14:04:58 修改

阅读量1.1k

点赞数 15

分类专栏： Vulkan 文章标签：图形渲染

于 2024-03-04 14:29:09 首次发布

本文链接：https://blog.csdn.net/hua_matlab_learn/article/details/136450687

版权

Vulkan 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

关键词：

RenderPass
SubPass
Attachment
Framebuffer
Subpass Dependency

RenderPass概念

RenderPass 是 Vulkan 图形 API 中的一个核心概念，它定义了一个渲染流程的完整步骤，包括在这个流程中将要使用的资源和操作。RenderPass 本身不包含实际的图形数据，而是包含了如何渲染这些数据的元数据和指令。以下是 RenderPass 的一些关键特性：

渲染流程的定义：RenderPass 描述了一个渲染流程，这个流程可能包括多个子步骤（SubPasses），每个 SubPass 都可以执行一系列的渲染操作。
资源的描述：在 RenderPass 中，你会定义将要使用的资源，如颜色附件（Color Attachments）、深度/模板附件（Depth/Stencil Attachments）、解析附件（Resolve Attachments）以及输入附件（Input Attachments）。这些资源在 Vulkan 中被称为 Attachments。
Attachment 的作用：Attachment 是 RenderPass 中的一个资源描述，它定义了资源的加载和存储操作，以及资源的格式。Attachment 不是实际的图形数据，而是关于如何使用这些数据的元数据。
Framebuffer 的使用：RenderPass 通过与 Framebuffer 的关联来获取实际的图形数据。Framebuffer 包含了一系列的 ImageViews，这些 ImageViews 指向实际的图形资源。RenderPass 通过这些 ImageViews 来渲染到颜色和深度/模板缓冲区。
子步骤（SubPasses）：每个 RenderPass 可以包含一个或多个 SubPass。每个 SubPass 都可以执行渲染操作，如绘制几何体、执行计算着色器等。SubPass 之间可以有依赖关系，这些依赖关系定义了它们之间的数据传递和同步。
渲染通道兼容性：在 Vulkan 中，后续的 RenderPass 可以使用与前一个 RenderPass 兼容的 Framebuffer 来渲染。这意味着只要满足 Vulkan 定义的兼容性要求，就可以在不同的 RenderPass 之间共享资源，而不需要重新创建或销毁资源。
渲染的控制：RenderPass 提供了对渲染过程的精细控制，允许开发者优化渲染性能，减少资源浪费，并确保渲染的正确性。

RenderPass 的设计使得 Vulkan 能够提供高性能的渲染，同时给予开发者对渲染过程的深入控制。这种设计有助于实现更复杂的渲染效果，同时保持对资源的高效管理。

设计RenderPass原因

RenderPass 在 Vulkan 中的设计是为了提供一种更高效、更有序的方式来处理渲染操作。以下是为什么需要设计 RenderPass 的几个关键原因：

优化GPU状态管理：在传统的图形API中，开发者可能不会意识到GPU状态的频繁切换会导致性能下降。Vulkan 通过 RenderPass 暴露了GPU的真实工作方式，允许开发者在渲染之前优化状态，从而减少状态切换的开销，提高性能。
并行处理和同步：Vulkan 允许在多个线程上并行构建 CommandBuffer，这需要一种机制来确保渲染命令的正确执行顺序。RenderPass 提供了这种同步机制，确保渲染命令按照预期的顺序执行。
适应Tile-Based渲染架构：移动设备上的GPU通常采用Tile-Based渲染架构，这种架构通过将帧缓冲区分割成多个Tile来优化渲染过程。RenderPass 允许开发者明确地定义渲染步骤，帮助Tile-Based GPU驱动程序更有效地管理On-Chip内存，减少不必要的数据移动和带宽损耗。
减少CPU开销：通过RenderPass，Vulkan 能够减少CPU到GPU的通信次数，因为RenderPass内部的命令可以批量处理。这样可以降低CPU的负担，提高整体的渲染效率。
提高帧时间的一致性：RenderPass 通过预定义的渲染步骤，有助于减少帧时间的波动，使得游戏和应用的帧率更加稳定。
更好的资源管理：RenderPass 允许开发者在渲染过程中更精细地控制资源的使用，例如，可以决定何时加载或卸载资源，以及何时进行内存分配和释放。

总的来说，RenderPass 是 Vulkan 提供的一种机制，它使得开发者能够更好地控制渲染过程，优化性能，同时适应现代GPU架构的特点。这种设计使得 Vulkan 能够在多种平台上，特别是移动设备上，提供高性能的图形渲染。

IMR架构的RenderPass

对于 Immediate Mode Rendering (IMR) 架构的GPU来说，RenderPass 同样带来了一系列的好处，这些好处主要体现在以下几个方面：

提高渲染效率：在IMR架构中，GPU通常需要等待前一个渲染命令完成后才能执行下一个命令。RenderPass 允许开发者明确地定义SubPass之间的依赖关系，这样驱动程序可以更智能地安排渲染任务，减少不必要的等待时间，提高渲染效率。
减少同步开销：在传统的IMR架构中，为了确保渲染的正确性，驱动程序可能需要在GPU管线中插入同步点，这会导致所谓的“气泡”（pipeline bubbles），从而降低GPU的效率。RenderPass 通过提供清晰的渲染顺序和依赖关系，允许驱动程序避免这些同步点，从而减少气泡，提高GPU的利用率。
优化资源管理：RenderPass 提供了关于Attachment（如纹理和缓冲区）的详细信息，包括是否需要清除、是否关心其内容等。这使得驱动程序可以更有效地管理资源，例如，可以提前安排清除操作，或者智能地选择最合适的清除方法。
状态预设：RenderPass 允许开发者预设每个SubPass的状态，这样GPU可以在开始渲染之前就准备好所有必要的状态，减少了运行时的状态切换，提高了渲染的连续性和效率。
数据布局优化：RenderPass 使得驱动程序可以根据应用程序的需求，更灵活地安排数据布局的变化，如格式转换和解压缩等操作。这样，即使数据在内存中的布局与渲染时的需求不同，也可以通过RenderPass的控制来优化这些操作，减少渲染过程中的延迟。
提高并行处理能力：RenderPass 允许并行或乱序地执行不依赖于彼此的SubPass，这样GPU可以在执行一个SubPass的同时，处理其他不相关的任务，进一步提高了GPU的并行处理能力。
减少未定义数据的影响：如果应用程序声明某个Attachment的内容是不需要的，RenderPass 可以利用这一点，允许驱动程序在渲染过程中使用更高效的渲染状态，即使这意味着Attachment中的数据是未定义的。

总的来说，RenderPass 为IMR架构的GPU提供了一种更高效、更可控的渲染方式，它通过明确渲染流程和优化资源管理，使得GPU能够更加高效地执行渲染任务，无论是在移动端还是桌面端。这种优化对于现代图形渲染来说是至关重要的，因为它有助于实现更高的性能和更低的延迟。

TBDR架构

在TBDR（Tile-Based Deferred Rendering ）架构中，GPU的工作方式是将渲染任务分割成多个Tile，每个Tile包含一定数量的像素（例如16x16或32x32）。每个Tile独立处理，首先执行顶点着色器计算，然后是片段着色器计算。这种处理方式允许GPU高效地利用其硬件资源，特别是在处理大量并行任务时。

SubPass在这个架构中的作用包括：

批处理和排序：SubPass允许开发者对DrawCall进行批处理和排序，这可以减少状态切换的开销，提高渲染效率。
利用共享内存：每个Tile可以访问快速的共享内存（On-Chip Memory），这使得SubPass内的操作可以快速地共享数据，减少了对全局内存的访问需求。
Input Attachment：SubPass允许开发者在片段着色器中访问前一个SubPass的输出，这对于需要依赖前一渲染步骤结果的场景（如延迟着色）非常有用。
内存管理：在SubPass中，开发者可以指定是否需要存储Attachment的内容。如果某个Attachment在渲染结束后不再需要，那么它所占用的内存可以被释放，这对于资源有限的移动设备尤其重要。
减少带宽消耗：由于Tile的局部性，GPU可以在本地处理大部分数据，减少了数据在内存和GPU之间的传输，从而降低了带宽消耗。

在设计针对TBDR架构的渲染管线时，合理利用SubPass可以显著提高渲染性能，尤其是在移动设备上，这种优化对于保持流畅的用户体验和延长电池寿命至关重要。开发者需要深入理解这些架构特性，以便更好地优化他们的渲染代码。

跨Tile问题

Tile-Based Deferred Rendering (TBDR) 架构的一个关键特点是每个Tile的独立性。在这种架构中，每个Tile作为一个独立的渲染单元，其内部的像素处理是并行的，但Tile之间的像素数据是不共享的。这意味着在单个Tile内部，片段着色器可以访问并处理该Tile内的所有像素，但无法直接访问其他Tile的像素数据。

要访问其他Tile的像素，通常需要以下步骤：

渲染完成：首先，必须等待整个图像的所有Tile都渲染完成。这涉及到等待所有并行处理的Tile完成它们的渲染任务。
像素数据合并：一旦所有Tile都渲染完成，GPU需要将这些Tile的像素数据合并起来，形成最终的图像。这个过程涉及到跨Tile的数据传输，可能会增加渲染时间。
额外的渲染步骤：在某些情况下，如果需要跨Tile的像素数据交互，可能需要额外的渲染步骤。例如，使用屏幕空间反射（Screen Space Reflections, SSR）或者后处理效果（如模糊、光晕等）时，可能需要在所有Tile渲染完成后，再进行一次全屏的渲染操作来处理这些效果。

这种设计确实可能导致在需要跨Tile像素数据交互的场景下渲染速度变慢，因为它增加了额外的渲染和数据合并步骤。然而，TBDR架构的优势在于其高效的并行处理能力和对内存带宽的优化，这在大多数情况下可以弥补跨Tile数据交互的延迟。

为了优化性能，开发者通常会尽量避免设计需要跨Tile像素数据交互的渲染效果，或者寻找其他方法来减少这种交互的需求。例如，可以通过预计算和存储跨Tile的共享数据，或者在设计时就考虑到Tile的边界，使得渲染效果在Tile内部就可以完成。