📚 课程目录第4章帧缓冲（Framebuffer）机制

4、帧缓冲（Framebuffer）机制：Framebuffer原理与数据结构、多缓冲技术（双缓冲/三缓冲）、DMA-BUF与ION内存管理

帧缓冲，说白了就是一块内存区域。GPU 往里面画图，显示控制器从里面读数据，然后刷到屏幕上。这个机制在车载系统里特别重要——你想想看，仪表盘、中控屏、HUD，哪个不需要它？

我刚开始做车载显示时，总觉得帧缓冲就是个简单的显存。后来踩了不少坑才明白，它的数据结构、同步机制、内存管理，每一个环节都可能成为性能瓶颈。

4.1 Framebuffer 原理与数据结构

帧缓冲的核心原理其实不复杂。应用程序通过系统调用把图像数据写入这块内存，显示控制器按固定的时序（比如 60Hz）从中读取像素，转换成显示信号。

在 Linux 内核里，帧缓冲设备通常对应 /dev/fb0。它的数据结构长这样：

struct fb_fix_screeninfo {
    char id[16];        // 标识符，比如 "DISP0"
    unsigned long smem_start;  // 物理地址
    __u32 smem_len;     // 长度
    __u32 type;         // 类型，比如 FB_TYPE_PACKED_PIXELS
    __u32 visual;       // 颜色模式，比如 FB_VISUAL_TRUECOLOR
    __u16 line_length;  // 一行字节数
};

struct fb_var_screeninfo {
    __u32 xres;         // 可见分辨率宽
    __u32 yres;         // 可见分辨率高
    __u32 xres_virtual; // 虚拟分辨率宽
    __u32 yres_virtual; // 虚拟分辨率高
    __u32 bits_per_pixel; // 每像素位数
    __u32 pixclock;     // 像素时钟
    __u32 left_margin;  // 行同步参数
    __u32 right_margin;
    __u32 upper_margin;
    __u32 lower_margin;
    __u32 hsync_len;
    __u32 vsync_len;
};

这里有个关键点：xres_virtual 和 yres_virtual 可以比实际分辨率大。为什么？因为多缓冲技术要用到它。

核心概念：帧缓冲的物理地址必须连续，且对齐到页边界。车载 SoC 的显示控制器通常要求 64 字节对齐，否则会出现显示错位。

4.2 多缓冲技术

单缓冲的问题很明显——你在画图的时候，显示控制器也在读同一块内存。画面就会出现撕裂（tearing）。

我遇到过最严重的一次，客户投诉仪表盘指针在快速转动时出现锯齿状断裂。查了半天，就是单缓冲导致的。

双缓冲

双缓冲的思路很简单：两个缓冲区，一个用于显示（front buffer），一个用于绘制（back buffer）。绘制完成后交换角色。

交换方式有两种：

页面翻转（Page Flip）：直接修改显示控制器的基地址寄存器，指向新的缓冲区。效率高，但需要硬件支持。
位块传输（BitBlt）：把绘制好的内容拷贝到显示缓冲区。简单，但浪费带宽。

车载系统里，我强烈建议用页面翻转。为什么？因为 BitBlt 在 1080p 分辨率下，每帧要拷贝约 8MB 数据，60fps 就是 480MB/s 的带宽消耗。这还没算上 GPU 的绘制带宽。

三缓冲

双缓冲有个隐藏问题：如果绘制速度跟不上显示刷新率，画面会卡在同一个缓冲区上。三缓冲就是解决这个的。

三个缓冲区轮流使用：一个显示，一个绘制完成等待，一个正在绘制。这样即使绘制偶尔超时，也不会阻塞显示。

特性	单缓冲	双缓冲	三缓冲
内存占用	1x	2x	3x
撕裂风险	高	低	极低
绘制延迟	低	中	高
帧率稳定性	差	中	好
适用场景	静态画面	一般动画	高帧率交互

我的经验：车载仪表盘建议用双缓冲就够了。中控导航因为涉及地图滚动、应用切换，三缓冲更稳妥。HUD 因为对延迟敏感，我一般用双缓冲加垂直同步。

4.3 DMA-BUF 与 ION 内存管理

帧缓冲的内存不是随便分配的。车载系统里，GPU、显示控制器、视频解码器、相机 ISP 都要访问同一块内存。这就需要统一的内存管理机制。

DMA-BUF 是 Linux 内核的框架，用于在不同设备间共享 DMA 缓冲区。ION 则是 Android 引入的内存分配器，基于 DMA-BUF 做了上层封装。

DMA-BUF 核心概念

DMA-BUF 本质上是一个文件描述符。你可以把它传给不同的设备驱动，每个驱动通过 dma_buf_attach() 获取访问权限。

// 分配 DMA-BUF
struct dma_buf *dmabuf = dma_buf_export(exp_info, &exp_ops);

// 设备 A 附加
struct dma_buf_attachment *attach_a = dma_buf_attach(dmabuf, dev_a);
struct sg_table *sgt_a = dma_buf_map_attachment(attach_a, DMA_BIDIRECTIONAL);

// 设备 B 附加
struct dma_buf_attachment *attach_b = dma_buf_attach(dmabuf, dev_b);
struct sg_table *sgt_b = dma_buf_map_attachment(attach_b, DMA_BIDIRECTIONAL);

这里有个坑：不同设备的 IOMMU 映射可能不同。同一个物理地址，在 GPU 和显示控制器眼里可能是不同的虚拟地址。DMA-BUF 帮你处理了这些映射关系。

ION 内存管理器

ION 把内存分成不同的堆（heap），每种堆适合不同的场景：

ION_HEAP_TYPE_SYSTEM：普通系统内存，通过页分配器获取。
ION_HEAP_TYPE_SYSTEM_CONTIG：连续物理内存，适合显示控制器。
ION_HEAP_TYPE_CARVEOUT：预留内存区域，适合 GPU 和显示控制器共享。
ION_HEAP_TYPE_DMA：通过 DMA API 分配，适合外设。

我做过一个项目，客户要求仪表盘和中控共享同一块帧缓冲。当时用的就是 ION 的 carveout heap，在系统启动时预留一块连续物理内存，然后通过 DMA-BUF 共享给两个显示控制器。

注意：ION 在较新内核中已被逐步弃用，改用 dma-heap 框架。但很多车载平台还在用 Android 10/11，ION 仍然是主流。迁移时要注意兼容性。

实际工作流程

一个典型的帧缓冲分配流程：

应用程序通过 ION 分配一块内存，指定 heap 类型和大小。
ION 返回一个 DMA-BUF 文件描述符。
应用程序把这个 fd 传给 GPU 驱动，GPU 映射后开始绘制。
绘制完成后，应用程序把 fd 传给显示控制器驱动。
显示控制器映射后，设置基地址寄存器，开始扫描输出。

整个过程不需要数据拷贝。这就是零拷贝（zero-copy）的核心。

4.4 避坑指南

做了这么多年车载显示，我总结几个常见问题：

缓存一致性：GPU 写完后，CPU 可能还在 cache 里存着旧数据。记得调用 dma_buf_begin_cpu_access() 和 dma_buf_end_cpu_access()。
内存碎片：连续物理内存分配容易失败。我建议在系统启动时预分配，或者用 carveout heap。
同步问题：多缓冲切换时，要等垂直消隐期（VBlank）。否则画面撕裂。用 FBIOPUT_VSCREENINFO 或 DRM 的 page_flip 可以解决。

小技巧：调试帧缓冲问题时，可以先用 cat /dev/urandom > /dev/fb0 看看屏幕有没有雪花点。有，说明硬件通路正常。没有，查驱动或硬件连接。

嗯，帧缓冲这块内容就这些。记住一个原则：能零拷贝就零拷贝，能硬件翻转就别软件拷贝。车载系统对实时性和稳定性要求高，每一微秒的延迟都可能影响用户体验。