假设你刚接手一座千万人口的“数字城市”，每天都有海量的邮件（像素）要投递到屏幕的每个角落。上一任局长用的是“直送模式”：来一封信就派一名快递员从中央仓库（显存）单独跑一趟，送完再回来送下一封。结果城市没多大，马路却天天瘫痪——货车空驶、油费（带宽）烧得飞快。后来你推行“分块模式”：先把城市切成一块块街区（Tile），邮件按街区集中分拣、凑满一卡车再出发，一趟车覆盖一个街区，往返次数骤降。最近你又加了一道新岗位：装车前的“地址预检员”，凡是注定被高楼遮挡、永远送不到收件人手里的邮件，直接划掉不许上车。这一套“分块 + 延迟写回 + 预检剔除”的体系，就是移动端 GPU 的 TBDR（Tile-Based Deferred Rendering）架构。它让你的手机能在不烫手、不掉电的前提下，流畅跑起高画质游戏——我们今天就走进这座“邮政局”，把它从头到尾看明白。

岗位关联

对 AI 从业者而言，理解 TBDR 等于拿到了移动端渲染的性能钥匙：无论做游戏、AR/VR 还是端侧 AIGC 可视化，你都能精准定位带宽瓶颈，把每一毫瓦功耗花在刀刃上。

目录
  1. 可视化演示
  2. 架构演进：三代邮局的接力
  3. 分块渲染原理：把城市切成街区
  4. 片上内存机制：近手储物柜
  5. 隐藏面剔除：预检员与无效邮件
  6. 优化实战策略：让每辆车满载
  7. 性能功耗调优：算清每一趟账
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示系统处理流水线、实时性能指标曲线及多方案对比分析，包含数据流转、吞吐延迟监控与方案评估。

本节配有交互动效（进入视口后自动加载，约 3KB）。

系统可视化 处理流程：输入→处理→模型→输出 性能监控：实时指标 P=L×T

架构演进：三代邮局的接力

想象你刚接手这座城市邮政局时，仓库门口堵成一团。老员工们坚持“来一单送一单”：每封信到达，快递员立刻从中央仓库取值，直奔目标地址，送完再回来取下一封。这种桌面 GPU 的 IMR（Immediate Mode Rendering，立即模式渲染）在 PC 时代够用，因为桌面机有大功率电源和独立显存带宽，能源随便烧。

但手机不行。移动端设计师换了个思路：为什么不让近在手边的计算单元先把活儿攒起来？于是诞生了 TBR（Tile-Based Rendering，分块渲染）：把屏幕划分成一块块小街区，几何阶段完成的三角形先按“街区号”分拣，装满一个街区再统一交给片元阶段。更进一步，TBDR 在 TBR 的基础上增加了一个硬件级的“地址预检员”——隐藏面剔除单元（HSR），在片元写回颜色缓冲之前先比较深度，把注定被遮挡的片元直接丢弃。这“延迟写回 + 提前剔除”的理念，就是 TBDR 名字里 Deferred 的含义。

三代架构演进，本质是把总耗时从“逐封直送”压到“按街区打包再预检”：能不上车的邮件绝不上车，能少跑一趟的绝不多跑。理解这四段账本结构，后面所有优化都围绕“砍掉哪一段”展开。

Tframe=Tgeometry+Traster+Tfragment+Tbandwidth\displaystyle T_{frame} = T_{geometry} + T_{raster} + T_{fragment} + T_{bandwidth}
一帧的渲染时间就像邮局一天的运营时长：几何分拣、街区派送、逐户投递、仓库往返，四段账都要计入总时长。
  1. $T_{geometry}$（几何处理阶段）顶点着色和分拣耗时，相当于邮局把邮件按街区打码分类的环节，决定三角形归属哪些 tile。
    TgeometryT_{geometry}
  2. $T_{raster}$（光栅化阶段）把三角形离散成像素片元，相当于把一封邮件拆成若干可投递的“单元”。
    TrasterT_{raster}
  3. $T_{fragment}$（片元处理阶段）逐像素执行着色器、深度测试与混合，是快递员敲开收件人家门的过程。
    TfragmentT_{fragment}
  4. $T_{bandwidth}$（带宽开销）数据在 DRAM 与片上存储之间往返的时间，是邮车在仓库与街区之间行驶的油耗与耗时。
    TbandwidthT_{bandwidth}

分块渲染原理：把城市切成街区

邮局改革第一步，是给城市画一张街区地图。你不再按邮件到达顺序投递，而是拿出网格纸，把整座城市切成 16×16 像素的小方块，每块就是一个“投递作业区”。图形学里，这张网格就叫 Tile，是移动 GPU 渲染的最小调度单位。渲染目标（render target，即帧缓冲）不像桌面 GPU 那样在显存里开一大块，而是按 tile 逐个处理。

一个 tile 的完整流程是：几何阶段先做分拣（binning），把每个三角形“广播”给所有与它相交的 tile；随后 GPU 按 tile 顺序，逐个加载该 tile 的几何数据，完成光栅化和着色；结果先写进该 tile 私有的片上缓冲区，最后才统一冲刷（flush）到外部显存。无论画面里三角形如何排列，每一帧要处理的 tile 数只由屏幕分辨率决定，这保证了调度节奏永远稳定。

快递员每天只认街区号，邮件再多，出车顺序永远稳定。同样，GPU 每帧按 tile 顺序稳定推进，这为硬件预检和片上缓存创造了条件——下一节那座“近手储物柜”就要登场了。

Ntiles=⌈WTw⌉×⌈HTh⌉\displaystyle N_{tiles} = \left\lceil \frac{W}{T_w} \right\rceil \times \left\lceil \frac{H}{T_h} \right\rceil
只要知道屏幕宽高和 tile 尺寸，就能算出整帧的街区数。1080p 屏幕配 16×16 tile，恰好是 68×120 = 8160 个街区。
  1. $\lceil \cdot \rceil$（向上取整）窗口边缘多出的几行像素也得凑成一个完整 tile，不能漏投，就像街角零散住户也要归入某个街区。
    ⌈WTw⌉\left\lceil \frac{W}{T_w} \right\rceil
  2. $W \div T_w$（横向 tile 数）屏幕宽度除以每个 tile 的宽，得到水平方向需要多少个作业区。
    WTw\frac{W}{T_w}
  3. $H \div T_h$（纵向 tile 数）屏幕高度同理，注意同样要向上取整。
    HTh\frac{H}{T_h}
  4. $N_{tiles}$（总街区数）两者相乘得到整帧 tile 总数，它决定分拣与逐块执行的调度粒度，是 TBDR 一切优化的地基。
    NtilesN_{tiles}

片上内存机制：近手储物柜

为什么分块能省带宽？秘密在于每个作业区里摆着一个“近手储物柜”。分拣员不必为每一封信跑中央仓库，而是把整个街区的邮件先倒进手边的柜子，就地分拣、就地装车。这个柜子就是 Tile Memory（片上内存），通常只有几十 KB，但速度比外部 DRAM 快一个数量级。在 TBDR 中，颜色缓冲和深度缓冲尽量保留在这块片上空间里，街区内的片元全部完成深度测试、着色后，结果才一次性写回外部显存。

这一设计直接打中移动 GPU 的命门——带宽。手机芯片的功耗大头不是计算单元，而是与 DRAM 之间的来回搬运。对 IMR 而言，每画一个被遮挡的片元都要读深度、写颜色，数据在片上片外反复横跳；对 TBDR 而言，一帧中每个像素的读写尽量在 tile 内闭环。但请注意：如果你写了一个 render target 之后又读回来，它就需要一次 load + store 的完整往返，成本等同于把储物柜推回仓库再推回来——这是移动端最隐蔽的带宽黑洞。

近手储物柜让“每封信都跑仓库”变成了“一个街区只跑一次仓库”。读懂这条带宽公式，你就明白移动端一切优化，最终都在与“每秒多少 GB 的搬运量”搏斗。

Bframe=W×H×Cbytes×Ffps×Ooverdraw\displaystyle B_{frame} = W \times H \times C_{bytes} \times F_{fps} \times O_{overdraw}
帧缓冲带宽 = 像素总量 × 每像素字节数 × 帧率 × 过绘制倍数。1080p、32 位色、60 帧、2 倍 overdraw 时，仅颜色缓冲每秒就要搬运约 1 GB 数据。
  1. $W \times H$（像素总量）屏幕的物理像素数，相当于全城住户总数，分辨率越高搬运量线性上涨。
    W×HW \times H
  2. $C_{bytes}$（每像素字节数）颜色与深度格式占用的字节数，如同每户要投递的信件重量。
    CbytesC_{bytes}
  3. $F_{fps}$（每秒帧数）目标帧率，帧率翻倍意味着每秒完整搬运的次数翻倍。
    FfpsF_{fps}
  4. $O_{overdraw}$（过绘制倍数）平均每个像素被写入的次数，是带宽的放大器，也是 TBDR 重点压制的对象。
    OoverdrawO_{overdraw}

隐藏面剔除：预检员与无效邮件

街区作业区再快，也架不住无效邮件堆积。想象一栋高楼背后躺着上千封信：它们全被装车、全被送到楼下，却根本没人能签收——因为被楼挡住了。TBDR 的聪明之处，就是在装车前安排了一名“预检员”：凡是注定被遮挡的片元，直接盖一个“查无此人”的章，原地丢弃。

这名预检员在硬件里叫 HSR（Hidden Surface Removal，隐藏面消除）。由于 tile 内所有片元都先堆在片上，GPU 有能力在写入颜色缓冲前做一次“谁在最前面”的全局比较：对不透明物体，只有最靠近相机的片元通过，其余全部剔除。它比传统 Early-Z（仅按提交顺序做的局部深度比较）更彻底——Early-Z 只能处理按顺序提前提交的物体，HSR 则无视提交顺序，只看最终谁遮挡谁。

HSR 的存在把 overdraw 的伤害降到了极低。overdraw 指某个像素被重复绘制多次。对桌面 IMR，overdraw=3 意味着帧缓冲写入量乘以 3；对 TBDR，不透明物体的 overdraw 基本被 HSR 归零。但半透明物体必须与背景逐层混合，无法预判深度，预检员只能下班——所以在移动端，“层层叠半透明特效”是唯一能气走预检员的写法。

预检员是 TBDR 的灵魂人物，他保证每一趟车装的都是最终会被看见的信。作为渲染工程师，你的职责就是别用半透明层把预检员支开。

Ooverdraw=NfragmentNvisible\displaystyle O_{overdraw} = \frac{N_{fragment}}{N_{visible}}
过绘制倍数 = 进入片元阶段的片元总数 ÷ 最终可见像素数。TBDR 的不透明场景里，这个比值可以无限逼近 1。
  1. $N_{fragment}$（片元总数）所有被光栅化并进入着色阶段的片元数，即预检员上岗前收到的全部“候选邮件”。
    NfragmentN_{fragment}
  2. $N_{visible}$（可见像素数）最终真正写进屏幕的像素数，只有最前面那封“被签收的信”。
    NvisibleN_{visible}
  3. $O_{overdraw}$（过绘制倍数）比值越接近 1，预检效率越高；比值越大，说明无效投递越多。
    OoverdrawO_{overdraw}

优化实战策略：让每辆车满载

邮局硬件再好，也怕调度混乱。既然摸清了 TBDR 的脾气，装车策略就要彻底换血，别再用桌面时代的“一封信一专车”思维。第一招，深度缓冲复用：深度图被存到新的 render target、之后又被读回，相当于储物柜反复推回仓库；正确做法是在同一 render target 同一帧内完成所有写入。第二招，Draw Call 合并：移动 GPU 的顶点能力远强于 CPU 的命令提交能力，成千上万个 draw call 会让 CPU 先趴窝；用静态合批、GPU Instancing 把同材质小物体打包成一辆车。第三招，纹理压缩：ASTC、ETC2 等格式能把显存数据量压到原来的四分之一，如同把大件行李抽成真空包装。第四招，避免全屏特效：全屏后处理意味着每个 tile 要把整块颜色缓冲额外读一遍，带宽成本直接翻倍。

实际做预算时，牢记一个关键事实：CPU 提交、几何处理、像素填色、带宽搬运，谁慢谁就是卡脖子的那根绳子。TBDR 下常见的 fill-bound（填色瓶颈）大多来自半透明层叠加；bandwidth-bound（带宽瓶颈）则来自未压缩纹理、频繁切换 render target 或过高倍数的 MSAA。先用 Profile 工具定位是哪一段慢，再决定用什么招，切忌闭眼乱调。

满载的车队、不搬的储物柜、真空包装的货物、干脆取消的全屏活动——每一招都瞄准 TBDR 的财富密码：让每一趟车只跑必要的公里数。

Tframe=TCPU+max⁡(Tgeometry,Tfill,Tbandwidth)\displaystyle T_{frame} = T_{CPU} + \max\left(T_{geometry}, T_{fill}, T_{bandwidth}\right)
一帧总时长 = CPU 提交时间 + GPU 各阶段中最长的那一段。优化永远先砍最长的木板，而不是均匀用力。
  1. $T_{CPU}$（提交时间）CPU 把渲染命令装车打包的时间；draw call 越多，这个值越大。
    TCPUT_{CPU}
  2. $\max(\cdot)$（取最大值）GPU 内几何、填色、带宽三段是并行的，总时间由最慢者决定，这就是“瓶颈”的数学含义。
    max⁡(Tgeometry,Tfill,Tbandwidth)\max\left(T_{geometry}, T_{fill}, T_{bandwidth}\right)
  3. $T_{geometry}$（几何阶段）顶点处理与分拣耗时，常见瓶颈是网格过密或顶点着色过重。
    TgeometryT_{geometry}
  4. $T_{fill}$（填色阶段）片元着色与混合耗时，半透明层层叠加时此值暴涨。
    TfillT_{fill}

性能功耗调优：算清每一趟账

再好的车队，也得有个会计。邮局每天用固定预算运营：一帧只有 16.6ms（对应 60fps），就像一天只有 24 小时。调优的本质，是把这 16.6ms 的账本摊开，找出哪一项超支离谱。先立预算：60fps 目标下，CPU 侧留约 4ms，GPU 侧留约 8ms，剩下预留给同步信号与系统调度。然后对账：Mali 平台的 Performance Analyzer、高通的 Snapdragon Profiler、Unity/Unreal 的 Frame Debugger，都能把几何、填色、带宽三段分开列出。

典型的“抓贼”场景有三种：填色时间爆表——查半透明叠层数量；带宽计数器爆表——查纹理格式和 render target 切换频次；CPU 时间爆表——查 draw call 与脚本开销。功耗的账也逃不掉：移动 GPU 的功耗与电压平方成正比，频率提 10%，功耗可能涨 20% 以上。TBDR 把带宽功耗压到极低，才让手机靠一块小电池也能跑大作。一个经典“真香”案例：某 MMO 手游把全屏泛光改成分辨率减半的降采样再合成，overdraw 从 3.5 降到 1.2，帧率从 45 拉回 60，机身温度降了 4℃，这就是砍掉“全城无效活动”后的收益。

账算得清，车队才跑得远。从分块、预检到打包优化，TBDR 的全部意义可以浓缩成一句话：让 GPU 用最少的搬运、最低的频率，把每一帧该送到的邮件准时送到。

P=α×C×V2×f\displaystyle P = \alpha \times C \times V^{2} \times f
动态功耗与负载系数、等效电容、电压平方、时钟频率成正比。省带宽 = 省计算 = 可降频 = 省电，TBDR 的价值正在于让高频变得不必要。
  1. $C$（等效电容）芯片内部状态切换时充放电的“惯性”，由工艺制程和晶体管规模决定。
    CC
  2. $V^{2}$（电压平方）电压的微小变化会平方级影响功耗，所以降频降压是最狠的省电手段。
    V2V^{2}
  3. $f$（时钟频率）GPU 每秒运行的周期数，频率越高，单位时间耗电越多。
    ff
  4. $\alpha$（负载系数）实际活跃电路的比例。TBDR 提前剔除片元，活跃负载下降，功耗随之下滑。
    α\alpha

AI 应用场景

场景一：手游画质与发热调优

阶段：渲染性能优化（工程交付阶段）

解决的问题：美术在 PC 编辑器里满帧运行，一上手机就发热卡顿。传统思路是暴力降分辨率、砍特效，结果画面糊成一片。结合 TBDR 知识后，能精准定位真凶——往往是全屏半透明粒子的层层叠加，导致带宽爆炸，而不是几何太复杂。

具体案例：某国风 MMO 手游的雨夜场景，全屏雨丝粒子加多层半透纱帘，用 Frame Debugger 测得 overdraw 高达 4.2，Mali 带宽计数器打满。按 TBDR 原理把半透明层合并到一张混合贴图、粒子降采样渲染，GPU 帧时从 24ms 降到 12ms，机身温度下降 5℃，画质肉眼无损。

场景二：AR 眼镜的端侧低功耗渲染

阶段：端侧实时渲染链路设计

解决的问题：AR 眼镜对功耗极其敏感，整机渲染功耗预算常常只有几百毫瓦，任何一次多余的显存搬运都不可接受。桌面 GPU 的“随便读写纹理”思路在这里直接出局。

具体案例：某 AR 眼镜的实时深度合成管线，利用移动 GPU 的 Framebuffer Fetch / Subpass 特性，在分块内一次完成“深度 + 彩色”融合，避免两个 render target 之间反复 load/store。改造后同等画质下整机渲染功耗降低约 35%，连续使用时间从 2 小时延长到 3.5 小时。

Python 演示

python58 行
"""模拟 IMR 与 TBDR 的片元写入带宽差异"""  class MailLayer:    """一个渲染层邮件: 矩形区域表示投递范围"""     def __init__(self, x, y, w, h):        self.x = x        self.y = y        self.w = w        self.h = h  def build_scene(width, height, layers, seed=42):    """随机生成多层覆盖的渲染场景"""    import random    random.seed(seed)    scene = []    for _ in range(layers):        w = random.randint(8, width // 2)        h = random.randint(8, height // 2)        x = random.randint(0, width - w)        y = random.randint(0, height - h)        scene.append(MailLayer(x, y, w, h))    return scene  def simulate_imr(scene):    """IMR: 每个片元都独立写一次帧缓冲, 不管是否被遮挡"""    total = 0    for layer in scene:        total += layer.w * layer.h    return total  def simulate_tbdr(scene, width, height):    """TBDR: HSR 之后每个像素只保留最顶层的可见片元"""    visible = set()    for layer in scene:        for py in range(layer.y, layer.y + layer.h):            for px in range(layer.x, layer.x + layer.w):                visible.add((px, py))    return len(visible)  def main():    width, height, layers = 64, 64, 12    scene = build_scene(width, height, layers)    imr = simulate_imr(scene)    tbdr = simulate_tbdr(scene, width, height)    print("IMR  模式写入片元:", imr)    print("TBDR 模式写入片元:", tbdr)    print("带宽节省: {:.1f}%".format(100 * (1 - tbdr / imr)))    print("IMR 等效过绘制倍数: {:.2f}".format(imr / tbdr))  if __name__ == "__main__":    main()
目的：在 64×64 的虚拟屏幕上随机撒 12 层矩形“邮件”，分别用 IMR 的逐个计数和 TBDR 的集合去重两种方式统计片元写入量，直观看出隐藏面剔除能省多少带宽。
  1. random.randint(8, width // 2)随机生成每层矩形的宽高，模拟游戏里大小不一的网格对象覆盖关系。
  2. total += layer.w * layer.hIMR 模式下每个被覆盖的像素都算一次真实写入，不管后面有没有被挡住。
  3. visible.add((px, py))用集合天然去重，模拟 HSR 预检后每个像素只保留最顶层可见片元这一行为。
  4. 100 * (1 - tbdr / imr)算出 TBDR 相对 IMR 的带宽节省百分比，通常跑完会发现省下 50% 以上。
  5. if __name__ == "__main__":保证脚本既可被导入复用，也能直接命令行运行看到对比结果。

常见误区

误区“我在 PC 上随便切 render target、随便叠后处理，手机应该也扛得住吧？”

正解桌面 IMR 的显存带宽充裕，切一次 render target 代价不大；移动端 TBDR 每次切换都意味着 tile 的 load/store 往返，等于把近手储物柜推回仓库再推回来。移动端应优先用 Subpass / Framebuffer Fetch 在分块内闭环数据流。

为何常见：主流开发流程都在 PC 编辑器里跑，PC 强大的带宽掩盖了移动端的真实代价，导致“编辑器不卡、真机卡爆”的经典翻车。

误区“TBDR 名字里带 Deferred，那不就是延迟渲染（Deferred Shading）吗？”

正解两者完全不是一回事。TBDR 的 Deferred 指“延迟写回”，是硬件层把片元在 tile 内攒齐再统一写回显存的调度策略；Deferred Shading 是软件层的多渲染目标（MRT）+ G-Buffer 着色技术。TBDR 不排斥前向渲染，HSR 依然有效。

为何常见：都叫"Deferred"，英文字面撞车，初学者极易望文生义。

误区“HSR 不是能自动剔除被遮挡的片元吗？那满屏粒子随便撒！”

正解HSR 只对不透明物体有效。半透明片元必须与背景逐层混合，无法用深度做“谁在前谁胜出”的预判，预检员直接下班。每一层半透明都会真实写回，overdraw 重新变成带宽杀手。

为何常见：只记住了 HSR 的结论，没记住 HSR 的前提条件——不透明。

误区“移动端优化三板斧：减面、减贴图、减 Draw Call，肯定没错。”

正解Draw Call 只影响 $T_{CPU}$。如果瓶颈在 fill（半透明叠层）或 bandwidth（纹理/RT 切换），砍 Draw Call 根本没用。正确顺序永远是先 Profile 定位瓶颈，再针对最短的那块木板动手。

为何常见：桌面时代的“性能口诀”深入人心，却忽略了瓶颈树模型里“谁慢听谁的”这一基本原则。

面试题

Q1. TBDR 架构名称中字母 "R" 的含义是？

单选题 · easy

  • A.光栅化 Rasterize
  • B.渲染 Rendering← 正确答案
  • C.递归 Recursion
  • D.反射 Reflection

答案：B。TBDR 全称 Tile-Based Deferred Rendering，R 指 Rendering（渲染），核心是“渲染目标延迟写回”的硬件理念。Rasterize、Recursion、Reflection 都与字母 R 不符，且不是 TBDR 的构成部分。

Q2. 移动端 GPU 普遍采用 TBDR 的首要原因是什么？

单选题 · easy

  • A.提升 CPU 单核频率
  • B.降低内存带宽功耗← 正确答案
  • C.增加屏幕分辨率上限
  • D.简化驱动程序开发

答案：B。手机芯片的功耗大头是显存带宽，TBDR 通过分块 + 片上缓存 + HSR 把片元读写尽量闭环在 tile 内，大幅减少 DRAM 搬运。提升 CPU 频率、增加分辨率、简化驱动都不是 TBDR 的设计初衷。

Q3. 在 TBDR 中，HSR（隐藏面剔除）发生在哪个时机？

单选题 · mid

  • A.顶点着色阶段开始之前
  • B.片元写回帧缓冲之前← 正确答案
  • C.完成全部帧输出屏幕后
  • D.材质纹理采样发起时

答案：B。HSR 是硬件级预检员，工作在光栅化之后、片元真正写入 tile 颜色缓冲之前：先做深度比较，被遮挡者直接丢弃。它发生在顶点着色之后、纹理采样之前，因此 A、C、D 均不正确。

Q4. 屏幕分辨率 1280×720，Tile 尺寸 16×16，整帧共有多少个 Tile？

单选题 · mid

  • A.3200 个
  • B.3600 个← 正确答案
  • C.8000 个
  • D.14400 个

答案：B。1280÷16=80，720÷16=45，80×45=3600 个 Tile。把屏幕切成街区后，GPU 按街区逐个处理，这个数量决定了分拣与逐块执行的调度粒度。

Q5. 以下哪些做法有利于发挥 TBDR 架构的优势？

多选题 · mid

  • A.复用深度缓冲降低切换开销← 正确答案
  • B.大量叠加全屏半透明特效
  • C.使用 ASTC 压缩纹理贴图← 正确答案
  • D.用 Subpass 在片上完成降采样← 正确答案

答案：ACD。复用深度缓冲避免 load/store 往返，ASTC 减少纹理带宽，Subpass 让数据留在片上——三者都贴合 TBDR 特性。B 会让 HSR 下班、overdraw 飙升，是典型的反面做法。

Q6. Tile Memory 与外部 DRAM 相比，最突出的特点是什么？

单选题 · mid

  • A.容量更大价格更便宜
  • B.位于 GPU 片上速度更快← 正确答案
  • C.可以持久保存渲染数据
  • D.不需要任何电源供电

答案：B。Tile Memory 是 GPU 片上的近手储物柜，容量只有几十 KB，但速度比 DRAM 快一个数量级。它每次渲染都会重新填充，不具备持久性；容量小、成本高，也不能脱离供电。

Q7. 关于 overdraw 与 HSR 的关系，下列说法正确的有？

多选题 · hard

  • A.不透明物体 overdraw 基本被 HSR 消除← 正确答案
  • B.半透明物体仍会产生真实 overdraw← 正确答案
  • C.HSR 会额外增加纹理采样带宽
  • D.overdraw 是带宽公式中的放大器← 正确答案

答案：ABD。HSR 在写回前比较深度，不透明物体被遮挡片元直接丢弃，overdraw 趋近 1；半透明无法预判深度，仍需逐层混合产生真实 overdraw；overdraw 是带宽公式里的乘法因子。HSR 本身不增加采样带宽，C 错误。

Q8. 在 Mali GPU 上使用 Framebuffer Fetch 的主要收益是什么？

单选题 · hard

  • A.避免 Tile 的加载与存储开销← 正确答案
  • B.自动降低光照计算精度等级
  • C.显著增加几何顶点缓存容量
  • D.有效提升纹理压缩率至两倍

答案：A。Framebuffer Fetch 让当前片元直接读取 tile 内存中正在渲染的内容，省去把前一 pass 结果 load 回来再 store 出去的往返，这正是 TBDR 最省带宽的用法。B、C、D 与它的作用无关。

Q9. 目标 60fps 时，一帧的渲染时间预算约为多少毫秒？

单选题 · easy

  • A.6.6 毫秒
  • B.16.6 毫秒← 正确答案
  • C.33.3 毫秒
  • D.66.6 毫秒

答案：B。1000÷60≈16.6ms。理解帧预算才能把 CPU 提交、GPU 几何/填色/带宽几个阶段切分清楚，也才能明白“先定位瓶颈再优化”的调优逻辑。

Q10. 移动端性能调优中，正确的瓶颈定位思路包括？

多选题 · hard

  • A.先测 GPU 几何/填色/带宽分段← 正确答案
  • B.每次只优化当前最慢的瓶颈← 正确答案
  • C.直接盲目降低全部画质参数
  • D.用 Profile 工具对比优化前后数据← 正确答案

答案：ABD。瓶颈树模型告诉我们“谁最长听谁的”，先分段测量、再针对最慢项优化、最后用数据验证，是标准流程。盲目整体降画质既无法定位根因，也往往牺牲了不该牺牲的视觉效果，因此 C 错误。