榨干移动端GPU性能：深入理解Vulkan Subpass与TBDR架构的带宽优化实践

2026/7/19 18:17:13 32 0 0 0

在移动端游戏开发和图形渲染中，**带宽（Bandwidth）是决定帧率稳定性和设备发热量的第一杀手。移动端GPU（如ARM Mali、Qualcomm Adreno、Apple GPU）普遍采用TBR（Tile-Based Rendering）或TBDR（Tile-Based Deferred Rendering）架构。这类架构的核心思想是“空间换带宽”——将屏幕划分为多个微小的Tile（如16x16像素），并在极高带宽、极低延迟的片上瓦片内存（On-Chip Tile Memory / SRAM）**中完成光栅化和混合，最后一次性写回系统内存（DRAM）。

Vulkan引入的Subpass（子通道）机制，正是为了完美契合TBDR架构的这一硬件特性。如果设计得当，Subpass能让多阶段渲染（如延迟渲染中的G-Buffer写入与光照计算）完全在片上Tile Memory中完成，实现零DRAM带宽消耗。本文将从硬件原理出发，详细解析如何设计高效的Vulkan Subpass。

一、为什么传统渲染管线在移动端是“带宽灾难”？

在传统的立即渲染模式（IMR，常见于桌面端GPU）下，延迟渲染（Deferred Shading）的流程通常如下：

Pass 1 (G-Buffer Base Pass)：渲染场景，将Albedo、Normal、Depth、Material等数据写入多个纹理附件（Attachments）。这些数据必须写入显存（DRAM）。
Pass 2 (Lighting Pass)：读取这些G-Buffer纹理，进行光照计算，输出最终颜色。

在移动端，这意味着巨大的带宽开销：

$$\text{总带宽} = \text{写入G-Buffer到DRAM} + \text{从DRAM读取G-Buffer} + \text{写入最终颜色到DRAM}$$

对于一个1080P、60帧的游戏，仅G-Buffer的读写就会轻松吃掉数GB/s的带宽，直接导致手机烫手、降频、掉帧。

二、 TBDR与Subpass的完美契合

TBDR架构引入了片上SRAM。在Vulkan中，一个VkRenderPass代表了一次完整的、需要与DRAM进行可能交互的渲染流程；而VkSubpass则代表了这个RenderPass内部的各个子阶段。

当我们在一个RenderPass中定义了多个Subpass，并且子路之间存在数据依赖（例如Subpass 1需要读取Subpass 0输出的G-Buffer）时，驱动程序会利用TBDR的特性：

Subpass 0 输出的G-Buffer并不写入DRAM，而是直接保留在片上的 Tile Memory 中。
Subpass 1 直接从 Tile Memory 中读取这些数据（通过subpassInput）。
最终只有光照计算后的Color Buffer才会被写回DRAM。

通过这种方式，G-Buffer的读写完全在片上完成，物理带宽开销降为0。

三、高效Subpass的设计要点与配置实践

要让Vulkan驱动完美实现上述的“片上保留”，必须正确配置一系列复杂的Vulkan结构体。任何一个参数配置错误，都会导致驱动放弃片上优化，退化为昂贵的DRAM读写。

1. 正确设置 Attachment 的 Load/Store Ops

这是告诉GPU哪些数据需要保留、哪些可以丢弃的关键。

对于中间产物（如G-Buffer中的Albedo、Normal、Depth）：

loadOp：设置为 VK_ATTACHMENT_LOAD_OP_CLEAR 或 VK_ATTACHMENT_LOAD_OP_DONT_CARE。避免使用 LOAD，因为我们不需要从DRAM加载旧数据。
storeOp：必须设置为 VK_ATTACHMENT_STORE_OP_DONT_CARE。这是最核心的步骤，告诉GPU：“这个附件在RenderPass结束后我不再需要了，不用写回DRAM。”

对于最终输出（如Present Color Buffer）：

storeOp：设置为 VK_ATTACHMENT_STORE_OP_STORE，将其安全写回系统内存。

// G-Buffer Normal Attachment 示例
VkAttachmentDescription normalAttachment{};
normalAttachment.format = VK_FORMAT_R16G16B16A16_SFLOAT;
normalAttachment.samples = VK_SAMPLE_COUNT_1_BIT;
normalAttachment.loadOp = VK_ATTACHMENT_LOAD_OP_CLEAR;
normalAttachment.storeOp = VK_ATTACHMENT_STORE_OP_DONT_CARE; // 关键：不写回DRAM
normalAttachment.stencilLoadOp = VK_ATTACHMENT_LOAD_OP_DONT_CARE;
normalAttachment.stencilStoreOp = VK_ATTACHMENT_STORE_OP_DONT_CARE;
normalAttachment.initialLayout = VK_IMAGE_LAYOUT_UNDEFINED;
normalAttachment.finalLayout = VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL;

2. 声明延迟分配内存（Lazily Allocated Memory）

既然G-Buffer不需要写回DRAM，那我们是否连物理显存都不用给它分配？答案是肯定的。

在创建G-Buffer的 VkImage 和分配 VkDeviceMemory 时：

VkImage 的 usage 必须包含 VK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BIT（暂存附件）。
分配内存时，寻找支持 VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT 的内存类型。

// 1. 创建 Image
VkImageCreateInfo imageInfo{};
imageInfo.sType = VK_STRUCTURE_TYPE_IMAGE_CREATE_INFO;
imageInfo.usage = VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT | VK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BIT; // 声明为暂存
// ...

// 2. 分配内存时筛选 Lazily Property
VkMemoryRequirements memRequirements;
vkGetImageMemoryRequirements(device, gBufferImage, &memRequirements);

VkMemoryAllocateInfo allocInfo{};
allocInfo.allocationSize = memRequirements.size;
allocInfo.memoryTypeIndex = FindMemoryType(
    memRequirements.memoryTypeBits, 
    VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT // 优先寻找延迟分配内存
);

在现代移动端GPU上，支持 LAZILY_ALLOCATED 的内存其实只是一段虚拟地址空间。GPU甚至不会为其分配实际的物理DRAM页面，从而实现了真正的零内存占用。

3. 配置 By-Region 的 Subpass Dependency

Subpass之间的数据流转需要通过同步屏障（Dependency）来协调。为了让GPU知道像素之间的对应关系，必须使用 VK_DEPENDENCY_BY_REGION_BIT。

这个标志告诉硬件：Subpass 1中像素 $(x, y)$ 的计算，仅依赖于Subpass 0中同一位置 $(x, y)$ 像素的输出。

这使得GPU可以安全地对单个Tile进行流水线处理，而不需要等待整个屏幕的Subpass 0渲染完毕。

VkSubpassDependency dependency{};
dependency.srcSubpass = 0; // G-Buffer Pass
dependency.dstSubpass = 1; // Lighting Pass
dependency.srcStageMask = VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT;
dependency.dstStageMask = VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT;
dependency.srcAccessMask = VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT;
dependency.dstAccessMask = VK_ACCESS_INPUT_ATTACHMENT_READ_BIT; // 关键：作为输入附件读取
dependency.dependencyFlags = VK_DEPENDENCY_BY_REGION_BIT;       // 核心：按区域同步

4. 在 Shader 中高效读取 `subpassInput`

在光照阶段（Subpass 1）的Fragment Shader中，不能使用常规的 sampler2D，而必须使用 subpassInput。

在GLSL中：

#version 450

// 绑定输入附件，对应 Subpass Description 中的 inputAttachments
layout(input_attachment_index = 0, set = 0, binding = 0) uniform subpassInput inAlbedo;
layout(input_attachment_index = 1, set = 0, binding = 1) uniform subpassInput inNormal;

layout(location = 0) out vec4 outColor;

void main() {
    // 使用 subpassLoad 获取当前像素位置的数据，无需传入 UV 坐标
    vec3 albedo = subpassLoad(inAlbedo).rgb;
    vec3 normal = subpassLoad(inNormal).xyz;

    // 光照计算...
    outColor = vec4(albedo * max(dot(normal, vec3(0.0, 1.0, 0.0)), 0.0), 1.0);
}

subpassLoad 在硬件底层会被编译为直接读取片上Tile寄存器的指令，完全不经过纹理采样器（Sampler）和纹理缓存（Texture Cache），速度极快。

四、移动端 Subpass 的核心限制与避坑指南

虽然Subpass非常强大，但在实际开发中存在诸多硬件限制。一旦踩坑，Subpass将失去优化效果，退化为普通的RenderPass。

1. 警惕 Tile Memory 容量超限（Pixel Local Storage Limit）

片上Tile Memory的空间是极为有限的。

Mali GPU：通常每个像素（Pixel）在Tile Memory中分配的空间限制在 128-bit (16 bytes) 到 256-bit (32 bytes) 之间（取决于具体架构，如Valhall/Fifth Gen）。
Adreno GPU：也有类似的片上寄存器限制（GMEM）。

如果你的G-Buffer过于肥胖：

Albedo (RGBA8 = 32-bit)
Normal (RGBA16F = 64-bit)
Material (RGBA8 = 32-bit)
Depth (D24S8 = 32-bit)

总计已经达到160-bit。如果超过了当前GPU硬件的物理限制，驱动将不得不发生**“Tile Spilling”**——强制将部分数据写回DRAM，这会导致严重的性能回落。

优化方案：

压缩G-Buffer格式。例如，Normal使用 R10G10B10A2_UNORM 或八面体编码（Octahedral Encoding）压入2通道。
尽量保持在128-bit以内，以兼容中低端移动设备。

2. 严禁进行“跨像素”采样

Subpass的设计基石是 1:1的像素映射（Pixel-local）。这意味着在Subpass 1中，你只能通过 subpassLoad 读取当前正在处理的这个像素在Subpass 0中的输出，绝对不能读取邻域像素。

如果你需要实现以下算法：

SSAO（屏幕空间环境光遮蔽）：需要采样周围像素的深度。
Bloom / Blur：需要进行高斯模糊邻域采样。
FXAA / Post-Processing：需要边缘检测。

这些算法无法在同一个RenderPass的Subpass内部完成。你必须结束当前RenderPass（将数据Store到DRAM），然后再开一个新的RenderPass进行采样。

3. 多线程渲染（Secondary Command Buffers）与 Subpass

如果在多线程中录制渲染指令，每个线程（Secondary Command Buffer）只能跑在特定的Subpass内。在调用 vkCmdExecuteCommands 时，必须显式指定当前CommandBuffer属于哪一个Subpass。频繁地在多线程中切换Subpass可能会引入额外的调度开销，需要合理划分任务。

五、总结：移动端高效 Subpass 检查清单

在移动端部署Vulkan Subpass时，请对照以下清单进行自检：

检查项	正确配置	常见错误
中间附件 Store Op	`VK_ATTACHMENT_STORE_OP_DONT_CARE`	`STORE` (导致不必要的DRAM写入)
中间附件 Image Usage	包含 `VK_IMAGE_USAGE_TRANSIENT_ATTACHMENT_BIT`	仅使用 `COLOR_ATTACHMENT_BIT`
内存分配属性	`VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT`	`DEVICE_LOCAL_BIT` (浪费物理显存)
同步依赖标记	`VK_DEPENDENCY_BY_REGION_BIT`	`0` (导致全局同步，破坏Tile并行)
Shader 读取方式	`subpassInput` / `subpassLoad()`	`sampler2D` / `texture()`
G-Buffer 像素大小	控制在 128-bit 以内 (Mali 兼容性友好)	盲目使用 `RGBA32F` 等高精度格式

通过严格遵守TBDR的硬件约束，巧妙设计Vulkan Subpass，你可以将移动端渲染管线的带宽消耗降到最低，从而在保证设备不发热的前提下，释放出令人惊叹的画面表现力。

瓦片渲染大师 Vulkan 移动端优化 TBDR架构

榨干移动端GPU性能：深入理解Vulkan Subpass与TBDR架构的带宽优化实践

一、 为什么传统渲染管线在移动端是“带宽灾难”？