第一章：显存泄漏的噩梦——一个真实案例引发的思考

各位做嵌入式GPU开发的朋友，咱们今天聊点扎心的事。

先讲个我亲身经历的故事。那是几年前，我参与一个智能座舱项目。说白了就是车载娱乐系统，带3D导航、倒车影像、还有一堆炫酷的UI特效。硬件用的是某款中高端SoC，集成了自研GPU。一切看起来都很美好——直到量产前两个月。

测试团队反馈：系统运行3小时后，导航画面开始卡顿。5小时后，倒车影像延迟超过1秒。8小时后，系统直接黑屏重启。

嗯，你猜对了——显存泄漏。

1.1 那个让我连续加班两周的Bug

当时我负责GPU驱动中的显存管理模块。说实话，一开始我根本没往泄漏上想。我以为是硬件问题，或者是某个DMA传输没对齐。结果呢？

用cat /sys/kernel/debug/dri/0/gem_objects一看，显存占用从初始的32MB，一路飙升到512MB——而我们的物理显存总共才256MB。

为什么会这样？

我花了整整两天，才定位到问题：某个纹理上传函数里，每次调用都会分配一块新的DMA缓冲区，但释放条件写错了。当纹理被销毁时，缓冲区没有被回收。说白了，就是只借不还。

你想想看，一个纹理上传操作，每帧执行几十次。每次泄漏4KB，一秒钟60帧，那就是240KB/s。一小时下来，接近900MB。显存不爆才怪。

1.2 泄漏带来的连锁反应

显存泄漏不只是「内存不够」那么简单。它会引起一系列连锁反应：

• 性能断崖式下跌：当显存剩余不足10%时，GPU开始频繁触发页面置换。每次置换都要走PCIe总线，延迟从几十纳秒飙升到几微秒。帧率直接从60fps掉到15fps。
• 系统无响应：更可怕的是，当显存完全耗尽，GPU驱动会进入「紧急回收」模式。这时候，所有提交的渲染命令都会被阻塞。用户看到的就是——画面卡死，点哪都没反应。
• 硬件损伤风险：我见过最极端的情况，某款GPU在显存耗尽后，电压调节器因为持续高负载而烧毁。虽然概率低，但一旦发生，就是硬件报废。

1.3 排查过程的痛苦回忆

说实话，那次排查让我对显存管理有了刻骨铭心的认识。

我试过的方法：

1. 手动打日志：在每个分配和释放点加printk。结果日志量太大，直接把内核日志缓冲区撑爆了。
2. 用ftrace跟踪：能抓到函数调用链，但面对几万条记录，根本看不出哪个是泄漏点。
3. 写脚本统计：我写了个Python脚本，定时抓取/proc/meminfo和DRM的debugfs信息。然后画成折线图。嗯，看到那条持续上升的曲线时，我确认了泄漏的存在——但依然不知道是谁在泄漏。

最后怎么找到的？

我写了一个简单的「引用计数检查器」。每次分配显存时，记录调用栈；每次释放时，检查是否匹配。如果某个地址的分配次数大于释放次数，就打印出那个调用栈。

代码其实很简单，核心逻辑就几十行：

// 伪代码，展示核心思路
struct mem_tracker {
    void *addr;
    size_t size;
    char stack[512];  // 保存调用栈
    int alloc_count;
};

void track_alloc(void *addr, size_t size) {
    struct mem_tracker *t = kmalloc(sizeof(*t), GFP_KERNEL);
    t->addr = addr;
    t->size = size;
    save_stack_trace(t->stack, 512);
    t->alloc_count = 1;
    // 插入到全局链表
}

void track_free(void *addr) {
    struct mem_tracker *t = find_tracker(addr);
    if (t) {
        t->alloc_count--;
        if (t->alloc_count == 0) {
            // 正常释放，移除记录
            remove_tracker(t);
            kfree(t);
        }
    } else {
        // 释放了未分配的内存，打印警告
        printk("WARNING: double free or invalid free\n");
    }
}

// 定期检查泄漏
void check_leak(void) {
    struct mem_tracker *t;
    list_for_each_entry(t, &tracker_list, list) {
        if (t->alloc_count > 0) {
            printk("LEAK: addr %p, size %zu, stack:\n%s\n",
                   t->addr, t->size, t->stack);
        }
    }
}

就是靠这个工具，我找到了那个「只借不还」的纹理缓冲区。修复后，显存占用稳定在32MB左右，再也没出过问题。

1.4 为什么你需要这门课？

那次经历让我意识到：显存泄漏检测，在嵌入式GPU开发中是个「隐形杀手」。

你可能觉得：

• 「我用的GPU有硬件MMU，不怕泄漏」——错。MMU只能做地址映射，不能解决泄漏问题。
• 「我用的RTOS，内存管理很简单」——更错。RTOS下显存管理往往更原始，泄漏更容易发生。
• 「我项目小，不会遇到这种问题」——我当年也是这么想的。

这门课，我会把我这些年踩过的坑、总结的方法、写过的工具，全部拿出来分享。从原理到实战，从检测到修复，一步步带你掌握显存泄漏的「终结技」。

说白了，我不想让你再经历我当年的痛苦。

下一章，咱们从显存管理的底层原理讲起。先搞清楚「显存是怎么分配的」，才能知道「泄漏是怎么发生的」。

准备好了吗？咱们开始。