开场
想象一下这样的场景：你接手了一个开放世界项目，美术同学在主城广场上摆了 200 盏动态光源（灯笼、火把、招牌），外加一堆粒子特效。
前向渲染（Forward Rendering）跑起来帧率直接腰斩：每个物体在每个光源下都要重算一遍着色，复杂度是O(物体数 × 光源数)——灯每多一盏，全场景所有物体的着色成本都跟着涨。灯多到一定量级，这就是灾难。
延迟渲染（Deferred Rendering）就是解决这个问题的利器：先把所有几何信息"记账"到几张贴图里，再统一"打光"。这套路就像餐厅的点餐系统——厨师不会每来一个客人就立刻炒菜，而是把所有订单汇总后批量处理。本文从"为什么这样做"出发，把延迟渲染的原理、实现和代价讲明白。
一、核心思想：把"几何"和"光照"解耦
1.1 前向渲染为什么扛不住多光源
先看清楚问题本质。前向渲染的每个片元着色器里，光照循环是内嵌的：画一个像素，就要遍历所有影响它的光源算一遍 BRDF。光源数翻倍，着色成本就翻倍——光照成本和场景几何规模死死绑在一起。更糟的是，大量被遮挡的像素（overdraw）也做了完整光照计算，纯属白算。
延迟渲染的破局点就是把这两件事拆开：
- Geometry Pass：只把材质和几何信息写进几张屏幕大小的贴图，完全不算光照；
- Lighting Pass：对屏幕上每个最终可见的像素，读回这些信息，统一算光照。
这样光照成
