WEBKT

Vulkan中MSAA配合Subpass与Input Attachment的硬件兼容性及规避方案

15 0 0 0

在现代移动端与桌面端图形渲染中，延迟管线（Deferred Shading）与多重采样抗锯齿（MSAA）的结合一直是性能消耗的大户。Vulkan 引入的 Subpass（子通道） 与 Input Attachment（输入附件） 机制，其核心目的之一就是利用 TBDR（Tile-Based Deferred Rendering）架构的 GPU 瓦片内存（Tile Memory），避免将庞大的 G-Buffer 写入系统显存。

然而，当我们在 Subpass 管线中引入 MSAA 时，硬件架构的差异、Tile Memory 的物理限制以及各家驱动对 Vulkan 规范的实现程度，会导致大量棘手的兼容性与性能骤降问题。本文将深入探讨 MSAA 配合 Subpass 使用时常见的硬件不兼容痛点，并提供在生产环境行之有效的规避与优化方案。

一、 核心痛点：Tile Memory 溢出导致“真·延迟渲染”失效

TBDR 架构（如 ARM Mali、Qualcomm Adreno、Apple Silicon）的优势在于：G-Buffer（位置、法线、材质参数等）只保存在 GPU 芯片上的高速 Tile Memory 中，Subpass 2 直接通过 Input Attachment 读取这些数据，整个过程不发生 VRAM（显存）写回与读取。

一旦启用 MSAA，这个问题就会发生质的变化。

1. 硬件限制

Tile Memory 的容量是极其有限的（通常每个像素分配 128-bit 到 256-bit 的高速缓存）。

  • 非 MSAA 情况下：G-Buffer 占用 $32 \text{bpp} \times 4 = 128 \text{bpp}$，完美容纳在 Tile Memory 中。
  • 4x MSAA 情况下：数据量直接乘以 4，达到 $512 \text{bpp}$。这超出了绝大多数移动端 GPU 的 Tile 缓存物理上限。

2. 兼容性后果

当数据量超出 Tile 限制时，GPU 驱动无法进行片上（On-Chip）合并，被迫执行 Spilling（瓦片内存溢出写回）。多采样的 G-Buffer 会被强制写回到系统显存中，下个 Subpass 再从显存读回。这直接导致 Subpass 失去了省带宽的初衷，性能甚至比传统非 Subpass 的多通路渲染更差。

3. 规避方案

  • 严格限制 G-Buffer 的格式与通道数：
    在 MSAA 开启时，精简 G-Buffer。例如，法线使用 $R11G11B10_UFLOAT$ 或八面体编码（Octahedral Encoding）压缩至 $R8G8_UNORM$；材质参数合并到通道中。
  • 分级降级策略：
    在移动端，检测物理器件的 Tile 限制。若不支持大容量 Tile，将 MSAA 限制为 2x，或者对非关键 G-Buffer 采用不使用 MSAA 的单采样存储，只对深度和几何边缘使用多采样。
  • 合理设置 VkAttachmentDescription 的 Memory Flags：
    对于不需要写回显存的多采样 G-Buffer，其 storeOp 必须设置为 VK_ATTACHMENT_STORE_OP_DONT_CARE，且其 VkImage 创建时必须带有 VK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BIT，内存分配使用 VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT。这能向驱动强力暗示：此贴图无需在物理显存中分配空间。

二、 多数移动端 GPU 不支持多采样深度/模板输入附件的读取

在延迟渲染的第二个 Subpass 中，我们有时需要读取多采样的深度贴图（Depth Input Attachment）来重建世界坐标，或者进行模板测试以排除非光照区域。

1. 硬件限制

部分中低端 Adreno（如 Adreno 610/630 等较老架构）以及部分 Mali GPU，其硬件的光栅化管线在片上无法直接支持对**多采样深度/模板图（Multisampled Depth/Stencil）**作为 subpassInputMS 进行随机采样（Texel Fetch）。驱动在编译 Shader 时，若发现 subpassInputMS 绑定的是 Depth 格式，会直接报错，或者退化为极其低效的软件模拟。

2. 规避方案

  • 深度提前 Resolve（解析）：
    在 Subpass 1 结束时，利用 Vulkan 的 pResolveAttachments 将多采样的 Depth 自动 Resolve 到一张单采样的 Depth 贴图。在 Subpass 2 中，只读取单采样的 Depth Input Attachment。虽然损失了边缘深度的抗锯齿精度，但能保证极高的硬件兼容性。
  • 重建线性深度存储于 Color Attachment：
    如果必须在 Subpass 2 获取高精度深度，可以在 Subpass 1 的 Color G-Buffer 中，用一个单独的 16-bit 通道（如 $R16_UNORM$）存储写入顶点的线性深度。由于 Color 格式的 subpassInputMS 兼容性远好于 Depth 格式，这能绕过硬件对深度读取的限制。

三、 sampleRateShading（样本率着色）的硬件性能断崖

在 Subpass 2 处理多采样输入附件时，Shader 需要决定是以“像素级”（Pixel Rate）还是“样本级”（Sample Rate）运行。

// GLSL 中的多采样输入附件定义
layout(input_attachment_index = 0, set = 0, binding = 0) uniform subpassInputMS u_GBufferColor;

1. 硬件限制

如果我们在 Fragment Shader 中遍历读取所有 Sample（例如循环 4 次执行 texelFetch(u_GBufferColor, ipos, i)），或者开启了 Vulkan 的 sampleRateShading 特性，GPU 将被迫在每个 Sample 点都执行一次 Fragment Shader。
在桌面端（NVIDIA/AMD），这通常能跑，但开销极大；而在移动端，绝大多数 GPU 并不具备高效的物理 Sample Shading 单元。一旦启用，GPU 会关闭几乎所有的 Tile 优化，将渲染管线打回原形。

2. 规避方案

  • 边缘检测与选择性多采样着色（Selective Resolve）：
    不要对全屏像素都执行多采样着色。在 Subpass 2 的 Shader 中，首先通过快速算法（如对比相邻像素的深度或法线差异）检测当前像素是否属于几何边缘（Edge）：
    • 如果是内部像素：只采样 sample = 0 的数据，复制到所有样本，避免循环。
    • 如果是边缘像素：才进入多采样循环进行逐样本着色。
  • 利用 Subpass Resolve 机制：
    尽量利用 Vulkan 渲染通道（RenderPass）底层的 pResolveAttachments。让硬件在 Tiling 结束时通过固定管线进行 Resolve，而不是在 Shader 中手动 texelFetch 再相加取平均。硬件 Resolve 是高度优化的专用电路，性能远超 Shader 手动计算。

四、 驱动 bug：Subpass 依赖关系与 Layout Transition 的不确定性

Vulkan 规范极其严苛，而在处理多采样 Input Attachment 时，不同显卡厂商（尤其是某些非主流移动端 SoC 厂商）的驱动对于子通道依赖（VkSubpassDependency）的边界情况处理存在大量 bug。

1. 典型不兼容现象

  • 画面闪烁/黑屏：当从一个包含 MSAA Color + MSAA Depth 的 Subpass 1 转换到 Subpass 2 且伴随 Resolve 时，若 VkSubpassDependency 的 srcStageMask 或 dstStageMask 设置得过宽（例如直接使用 VK_PIPELINE_STAGE_ALL_GRAPHICS_BIT），部分 Mali 驱动会发生 Barrier 丢失，导致下个 Subpass 读到了未填充完毕的瓦片数据。
  • Layout 冲突：部分旧驱动不支持将同一个多采样 Attachment 同时作为 Subpass 1 的 Color Attachment 和 Subpass 2 的 Input Attachment。

2. 标准且安全的 VkSubpassDependency 配置方案

为了确保在所有硬件上都能正确同步多采样数据的片上读写，应使用最精确的 Stage 和 Access 掩码。以下是一个经受过线上项目验证的典型配置：

VkSubpassDependency dependencies[2];

// 1. 外部到第一个 Subpass 的同步（处理多采样写入准备）
dependencies[0].srcSubpass = VK_SUBPASS_EXTERNAL;
dependencies[0].dstSubpass = 0;
dependencies[0].srcStageMask = VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT;
dependencies[0].dstStageMask = VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT | VK_PIPELINE_STAGE_EARLY_FRAGMENT_TESTS_BIT;
dependencies[0].srcAccessMask = VK_ACCESS_MEMORY_READ_BIT;
dependencies[0].dstAccessMask = VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT | VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT;
dependencies[0].dependencyFlags = VK_DEPENDENCY_BY_REGION_BIT;

// 2. Subpass 0 (G-Buffer) 到 Subpass 1 (Lighting) 的同步
// 注意：必须包含 BY_REGION 以确保在 Tile Memory 内完成同步
dependencies[1].srcSubpass = 0;
dependencies[1].dstSubpass = 1;
dependencies[1].srcStageMask = VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT | VK_PIPELINE_STAGE_LATE_FRAGMENT_TESTS_BIT;
dependencies[1].dstStageMask = VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT;
dependencies[1].srcAccessMask = VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT | VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT;
dependencies[1].dstAccessMask = VK_ACCESS_INPUT_ATTACHMENT_READ_BIT;
dependencies[1].dependencyFlags = VK_DEPENDENCY_BY_REGION_BIT; // 极其关键，保证 TBDR 不将数据写回 VRAM

五、 工程落地与架构设计建议

在实际商业引擎研发中，建议采用自适应动态降级架构来彻底规避上述兼容性风险：

  1. 设备特征画像（Device Profiling）：
    在引擎初始化阶段，通过 vkGetPhysicalDeviceProperties 和 vkGetPhysicalDeviceFormatProperties 检测设备。针对 Adreno 6xx 以下、Mali-Gxx 以下的低端 GPU，直接关闭“Subpass + MSAA Deferred”管线。
  2. ** fallback 方案设计**：
    • 高端设备：启用 Subpass MSAA + Lazily Allocated Transient G-Buffer (片上延迟渲染)。
    • 中端设备：退化为 Standard Deferred + Post-Processing FXAA/SMAA（放弃 MSAA，改用空间抗锯齿，保留 Subpass 带来的带宽红利）。
    • 兼容性要求极高/低端设备：退化为传统 Forward Rendering + MSAA 4x（前向管线天然对 MSAA 友好，不会产生 Tile 溢出问题）。
  3. 活用 Vulkan 1.2+ 的 VK_KHR_create_renderpass2：
    在新版 API 中，显式使用 VkAttachmentDescription2 配合 VkAttachmentReference2，这能为驱动提供更明确的内存布局过渡意图，减少因驱动推导布局失败导致的底层回退。

通过上述多维度的优化与规避方案，我们可以在榨干移动端 TBDR 架构红利的同时，确保图形管线在成百上千款 Android/PC 硬件设备上稳定、高效地运行。

纳秒渲染 VulkanMSAA图形渲染

评论点评