4. 系统架构设计：CPU/GPU/FPGA方案对比、流水线设计、内存管理策略

好，咱们进入第四章。这一章我打算聊聊系统架构层面的选择。说白了，就是决定用哪块“料”来干活——CPU、GPU还是FPGA？以及怎么把这些计算单元组织起来，让它们高效运转。

我在做第一个畸变校正项目时，天真地以为算法写好了就万事大吉。结果一上1080p@60fps的实时流，CPU直接飙到100%，画面还卡成PPT。嗯，从那以后我才真正开始琢磨架构这件事。

4.1 计算方案选型：CPU vs GPU vs FPGA

先看一张对比表，帮你快速建立直觉：

我个人习惯这样选型：

• CPU方案：适合分辨率不高（如VGA）、帧率要求低（<30fps）的原型验证。我早期用OpenCV的remap函数跑640×480，勉强能到25fps。但一旦上到1080p，CPU就扛不住了。
• GPU方案：适合高分辨率、高吞吐的场景。比如4K@60fps的校正，用CUDA实现双线性插值，配合共享内存优化，延迟能控制在10ms以内。但要注意，GPU的PCIe传输是瓶颈。
• FPGA方案：适合对延迟和功耗有严格要求的嵌入式场景。比如无人机上的实时校正，FPGA能做到微秒级延迟，功耗不到10W。但开发周期长，调试起来也头疼。

4.2 流水线设计：让数据流起来

选好了计算单元，下一步就是设计流水线。畸变校正的典型流水线分为四个阶段：

1. 图像采集：从相机传感器读取原始帧（RAW或YUV）。
2. 预处理：去噪、白平衡、色彩空间转换。
3. 畸变校正：核心阶段，包括坐标映射和插值。
4. 后处理：裁剪、缩放、编码输出。

为什么需要流水线？因为每个阶段的处理时间不同。如果串行执行，总延迟就是各阶段之和。而流水线可以让四个阶段并行工作——采集第N+3帧时，校正第N+2帧，预处理第N+1帧，后处理第N帧。

我曾经在一个项目中，把流水线从4级拆成8级，延迟反而增加了。为什么？因为级数太多，每级的寄存器开销和同步开销超过了并行带来的收益。所以，流水线深度不是越深越好。

下面这张图展示了典型的4级流水线结构：

4.3 内存管理策略：别让数据搬运工拖后腿

流水线设计好了，但数据怎么在各级之间传递？这就涉及到内存管理。我见过太多项目，算法效率很高，但内存拷贝占了总时间的一半以上。

核心策略有三条：

• 零拷贝（Zero-Copy）：尽量让计算单元直接访问原始数据，避免不必要的内存拷贝。比如在GPU上，用cudaHostRegister锁定主机内存，让GPU直接通过PCIe访问。
• 双缓冲（Double Buffering）：用两个缓冲区交替读写。一个缓冲区被计算单元读取时，另一个缓冲区可以被采集单元写入。这样读写不冲突，流水线不会停顿。
• 内存池（Memory Pool）：预分配一大块连续内存，按需分配和回收，避免频繁的malloc/free。这在实时系统中尤其重要——动态分配可能导致不可预测的延迟。

下面是一个简单的双缓冲伪代码示例：

// 双缓冲乒乓操作
uint8_t* buffer[2] = { malloc(FRAME_SIZE), malloc(FRAME_SIZE) };
int write_idx = 0;  // 当前写入的缓冲区索引

while (running) {
    // 采集线程：写入 write_idx 缓冲区
    sensor_read(buffer[write_idx]);
    
    // 计算线程：读取 1-write_idx 缓冲区
    int read_idx = 1 - write_idx;
    process_frame(buffer[read_idx]);
    
    // 交换索引
    write_idx = 1 - write_idx;
}

在GPU上，内存管理还要考虑显存和主机内存的传输。我建议用异步传输：把数据从主机拷贝到设备的同时，让GPU执行上一个帧的kernel。CUDA的流（Stream）就是干这个的。