Forward 与 Deferred

先把题目说成人话

一个移动战斗场景只有少量主灯，却满屏都是烟、粒子和透明技能；另一个夜景房间大多是不透明墙面，却挤着许多小灯。两边都要算灯光，但重复工作的来源完全不同。现实要解决的是决定：物体经过时当场把相关灯算完，还是先把当前看得见的表面记到账本，再让各盏灯统一查账。

物体绘制时直接完成材质与灯光计算叫前向渲染（Forward Rendering），先保存表面属性再统一算灯叫延迟渲染（Deferred Rendering），保存基础颜色、法线和粗糙度等属性的多张缓冲叫几何缓冲（G-buffer）。先按屏幕区域整理灯单、再做前向着色叫分区前向渲染（Forward Plus），边缘用多个样本抗锯齿叫多重采样抗锯齿（MSAA）。

这是虚构教学故事，不是个人项目经历。

场景：先让问题变得看得见

团队面对两个场景。第一个是移动端角色战斗：少量主灯，大量粒子与透明技能，要求 MSAA。第二个是室内夜景：屏幕里有许多小范围动态灯，大部分表面不透明。

两种场景像两种结账方式。少量灯时，物体经过收银台直接结账很自然；灯很多时，先把表面信息写到账本，再让每盏灯查账可能更省重复工作。

（右脑）画面：把渲染方式想成三种收银通道。第一条让每件物体到柜台时直接结清照到它的灯，透明技能也能排在这里；第二条先把不透明表面的基本信息写进公共账本，再让许多灯统一来查账，透明物仍需另走前一条通道；第三条先按屏幕区域整理每处可能相关的灯单，再让物体只结算自己的短名单。移动战斗场可能灯少却有大片透明粒子，室内夜景可能灯多但墙面多为不透明，两边排队形状完全不同。选择前必须同时看灯数、透明覆盖、抗锯齿、材质能力和内存带宽，不能背一个永远最快的答案。

（左脑）对表：核验对象包括可见不透明/透明像素、每对象或每 tile 灯数、G-buffer 数量与格式、分辨率、MSAA 样本、材质模型、显存/带宽和 GPU 阶段时间。多灯或大面积透明是观察事实，“因此某路径必然更快”只是待测假设；平台名称与公司归属也不是路径胜负证据，结论需来自同内容、同画质、同设备捕获。像素、灯数、字节/帧与毫秒要分别记录，透明通常回到 Forward 也应计入总账。收银台类比解释数据流，类比不等于某腾讯项目的实现事实。

小明：先形成一个完整猜测

小明认为移动端一律 Forward、PC 一律 Deferred。这个模型抓住了移动带宽与桌面算力差异，却忽略了现代移动 Tile GPU、Forward+、URP Deferred，以及具体内容的透明比例和灯光数量。

同一平台换一个场景，最合适的路径就可能改变。平台标签不是选择结论，只是约束之一。

小红：把猜测放回现实检查

小红先比较第一个场景。Forward 能自然处理透明和 MSAA，少量主灯不会让同一物体重复付出太多光照成本；Deferred 即使处理了不透明部分，透明技能通常仍要回到 Forward，并额外承担 G-buffer 的读写和 MSAA 复杂度。

她再看第二个场景。传统 Forward 中，每个对象或像素面对许多灯，Pass 或循环成本迅速增加；Deferred 让几何材质先写一次 G-buffer，再按灯体积计算，灯数多时更有优势。Forward+ 则先把灯分配到屏幕 tile/cluster，再让 Forward Shader 只遍历相关灯，位于两者之间。

我：用检查结果修正模型

我先为这两个虚构场景作出可被捕获推翻的候选决策，而不是停在“都可以”：

• 移动战斗场景：先选 Forward+。它保留透明与 MSAA 路径，又避免传统 Forward 遍历过多无关灯；若灯始终极少，普通 Forward 仍是更简单的对照组。
• 多动态灯的不透明场景：先把 Deferred 作为候选，让不透明材质主要先写 G-buffer，再按灯体积计算；实际管线仍可能有深度预通过、额外材质 Pass 或过绘，不能把“先写表面”简化成全场严格只写一次。同时把 G-buffer 带宽和显存列为否决条件。
• 混合内容：不透明走 Deferred、透明走 Forward 很常见；不能假设选了 Deferred 就消灭所有 Forward。

这只是按已知内容作出的实现起点，不是没有数据的性能胜负。两个场景都要在同一镜头下比较 GPU 阶段、带宽/显存、透明回退、MSAA 与灯数扩展性；捕获若推翻假设，就更换路径。TA 工作流也随之变化：Forward 要控制每对象灯数、变体、透明 overdraw 和多 Pass；Deferred 要管理 G-buffer 通道、材质模型兼容、带宽、灯体积与透明回退；Forward+ 还要检查灯列表构建和单 tile 灯数上限。

对“腾讯为何多采用前向”的边界结论是：没有具体项目统计或公开管线资料，不能证明“多采用”。若某腾讯移动项目选择 Forward，合理原因可能是透明内容、MSAA、少灯、内存带宽、兼容性和自定义材质需求，但必须以该项目资料为准。

（右脑）画面修正：小明给“移动端”贴上 Forward、给“PC”贴上 Deferred；小红不再按平台标签下结论，而是先核对移动战斗的少灯、透明和 MSAA，再核对夜景的多小灯与不透明占比。前者让 Forward 系路径更适合作为候选，后者才可能让 G-buffer 账本回本。于是选择改按内容流量而非平台标签：保留 Forward+ 的灯单方案，也允许“不透明 Deferred、透明 Forward”的混合路径；至于腾讯具体项目为何选某条通道，必须另有项目资料与目标设备捕获，不能拿这幅收银图证明公司级偏好。

（左脑）严格对表：选择流程为：先列目标设备和管线支持；统计代表镜头的灯数分布、透明覆盖、MSAA、材质模型与分辨率；实现画质等价的 Forward/Forward+ /Deferred 候选；分别记录几何、灯光、透明、G-buffer 读写、显存和总 GPU 时间；再检查变体、材质兼容和最坏 tile 灯数。只有候选在目标帧预算、内存预算和画质条件下通过才采用；若回答某公司为何选择，还必须引用具体项目资料，通用约束只能形成假设。

老师解惑

• Forward：着色对象时直接计算灯光；透明和自定义材质灵活，灯多时成本可能随对象/像素所受灯数增长。
• Deferred：先写 Base Color、Normal、Roughness 等 G-buffer，再计算灯光；多灯不透明场景有利，但增加 render target 带宽和内存。
• Forward+ / Clustered Forward：先按 tile/cluster 建灯列表，再做 Forward 着色，减少每像素遍历的无关灯。
• 透明边界：常规 G-buffer 难以保存多层透明表面，因此透明通常另走 Forward。
• MSAA 边界：Forward 与 MSAA 结合直接；Deferred 的多样本 G-buffer、逐样本着色和解析会更复杂，但不是绝对不能做。

工具分工

• Unity Render Pipeline Asset / Renderer：确认实际使用 Forward、Forward+ 还是 Deferred，以及平台支持。
• Frame Debugger：检查 G-buffer、灯光 Pass、透明回退和额外 Pass。
• Unity Profiler（GPU Usage）：比较目标构建中的几何、灯光、透明和带宽相关阶段。
• RenderDoc / 平台 GPU 工具：查看 render target、tile/cluster 灯列表与带宽证据。

记忆钩子

少灯、透明和 MSAA 把选择推向 Forward；多灯不透明把选择推向 Deferred；最终只认项目捕获，不认公司传说。