14、内存池在图形学中的应用：帧分配器、双缓冲、临时分配

图形学这块，说白了就是跟帧率赛跑。你想想看，一秒钟要渲染60帧，每帧只有16毫秒的时间。这期间要处理顶点、纹理、光照、阴影……哪有功夫去搞复杂的内存释放？

我早年做游戏引擎时，就吃过这个亏。那时候用标准malloc/free，结果每帧结束都要释放成百上千个小对象。帧率直接掉到30fps以下。后来我意识到——图形学里的内存管理，思路得反过来。

14.1 帧分配器：用完就扔，别回头

帧分配器（Frame Allocator）的思路特别简单：每帧分配，每帧清空。你不需要关心每个对象什么时候释放，只需要在帧结束时把整个内存区域重置就行。

它的核心结构就两个指针：

typedef struct {
    char* buffer;      // 内存块起始
    size_t size;       // 总大小
    size_t offset;     // 当前分配位置
} FrameAllocator;

void* frame_alloc(FrameAllocator* fa, size_t size) {
    // 对齐到8字节（图形学里常见要求）
    size_t aligned = (size + 7) & ~7;
    if (fa->offset + aligned > fa->size) {
        return NULL;  // 帧内存耗尽
    }
    void* ptr = fa->buffer + fa->offset;
    fa->offset += aligned;
    return ptr;
}

void frame_reset(FrameAllocator* fa) {
    fa->offset = 0;  // 简单粗暴，直接重置
}

你看，分配就是移动指针，释放就是归零偏移量。没有链表，没有空闲块合并，没有任何复杂逻辑。我曾在项目中用这个方案处理粒子系统——每帧生成上千个粒子，帧尾直接reset，性能提升了一个数量级。

关键点：帧分配器只适用于生命周期明确、且不超过一帧的数据。比如临时变换矩阵、每帧的顶点缓存、UI绘制命令等。

注意：千万别把跨帧引用的数据放在帧分配器里。我曾经有个同事把纹理句柄存在帧分配器里，下一帧访问时内存已经被覆盖了——嗯，画面直接花屏。

14.2 双缓冲：让GPU和CPU不打架

双缓冲（Double Buffering）是图形学里最经典的内存管理策略。为什么需要它？因为GPU和CPU是并行工作的。CPU在准备下一帧的数据，GPU在渲染当前帧。如果它们操作同一块内存，就会产生竞争。

解决方案很简单：准备两块缓冲区。CPU写一块，GPU读另一块。每帧结束后交换角色。

typedef struct {
    FrameAllocator buffers[2];
    int current_index;
} DoubleBufferAllocator;

void* db_alloc(DoubleBufferAllocator* db, size_t size) {
    // 只分配当前帧的缓冲区
    return frame_alloc(&db->buffers[db->current_index], size);
}

void db_swap(DoubleBufferAllocator* db) {
    // 重置下一帧的缓冲区，准备使用
    int next = 1 - db->current_index;
    frame_reset(&db->buffers[next]);
    db->current_index = next;
}

这个模式在图形API里随处可见。Vulkan的Command Buffer、DirectX的Ring Buffer，底层都是这个思路。我个人习惯把双缓冲和帧分配器结合使用——每帧分配的数据天然就在当前缓冲区里，swap之后自动变成旧数据，下一帧重置即可。

小技巧：如果数据量波动大，可以给每个缓冲区分配不同的初始大小。比如第一帧可能分配较多，第二帧较少。观察几帧后动态调整，避免浪费。

14.3 临时分配：别让中间数据占着茅坑

图形学里有很多临时数据：顶点变换后的坐标、裁剪后的三角形、光栅化前的片段……这些数据用完就扔，没必要长期保留。

临时分配（Scratch Allocation）就是为这类场景设计的。它通常是一个独立的、较小的内存池，专门用于存放中间计算结果。

typedef struct {
    char* scratch;
    size_t scratch_size;
    size_t mark;  // 保存检查点
} ScratchAllocator;

void scratch_mark(ScratchAllocator* sa) {
    sa->mark = sa->offset;  // 记录当前位置
}

void scratch_rewind(ScratchAllocator* sa) {
    sa->offset = sa->mark;  // 回退到检查点
}

这个模式特别适合嵌套的渲染管线。比如你先做阴影贴图，再做主渲染。阴影阶段分配了一堆临时数据，完成后回退到检查点，主渲染阶段就能复用同一块内存。

我曾经在移动端GPU上优化过一个后处理管线。原来每步都malloc/free，帧率只有20fps。换成临时分配器后，帧率直接翻倍到40fps。为什么？因为省掉了系统调用的开销，而且缓存命中率大幅提升。

核心原则：临时分配器的生命周期越短越好。最好在函数调用内部完成mark和rewind，不要跨函数传递临时指针——容易造成悬空引用。

14.4 三种分配器的对比与选择

特性 帧分配器 双缓冲 临时分配
生命周期 一帧 两帧交替 函数/阶段内
释放方式 整块重置 交换后重置 回退到检查点
适用场景 每帧生成的数据 CPU/GPU并行 中间计算结果
性能开销 极低 低 极低
内存浪费 可能有碎片 双倍内存 取决于检查点

实际项目中，我通常把这三种分配器组合使用。帧分配器负责每帧的常规数据，双缓冲负责GPU交互，临时分配器处理管线内部的中间步骤。各司其职，互不干扰。

14.5 核心逻辑图：图形学内存分配流程

图形学内存分配流程 CPU准备数据 帧分配器 每帧数据（粒子/UI） 双缓冲 GPU/CPU并行数据 临时分配 中间计算结果 GPU渲染 帧结束：重置/交换 下一帧复用

这张图展示了我常用的分配流程。CPU准备数据时，根据数据类型选择不同的分配器。帧分配器处理每帧的临时对象，双缓冲处理GPU交互数据，临时分配器处理管线内部的中间步骤。帧结束后，所有分配器统一重置或交换，为下一帧做准备。

经验之谈：如果你发现帧率不稳定，先检查是不是内存分配导致的。用性能分析工具看看malloc/free的调用次数。如果每帧超过1000次，就该考虑用帧分配器了。

图形学里的内存管理，说白了就是「快」字当头。别想着精细释放，别想着碎片整理。用完就扔，整块回收，这才是正道。我见过太多团队在图形项目里用通用内存池，结果性能还不如裸malloc——因为通用池的元数据开销和锁竞争，在每帧几千次分配的场景下会被放大到难以接受。

嗯，记住一句话：图形学分配器，越简单越好。帧分配器、双缓冲、临时分配，这三个工具足够覆盖90%的场景。剩下的10%，要么是设计有问题，要么是数据量太大需要流式处理——那是另一个话题了。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →