在上一篇《DRM驱动程序开发（VKMS）》文章里，我们学习了如何编写一个最简单的 KMS 驱动。而本篇，我将以叙述的形式为大家讲解 DRM GEM 的相关概念，代码留到下一篇进行讲解。
我知道，大多数的 DRM 初学人员，在刚接触到 GEM 相关概念时，首先困惑的不是 GEM 架构有多难，而是 GEM 里面的那些专业术语到底是怎么来的？为什么要这样命名？比如本篇要讲的“DUMB”和“PRIME”，当你得知它们的作用时，你甚至会有些愤慨：它们的名字和它们的功能简直毫无逻辑关系！是 DRM 社区的大佬们都喜欢故弄玄虚？还是我们的百度翻译不够准确？带着这样的疑问，我查阅了 DRM 相关的历史资料，深挖这些术语的历史来源，最终形成此文。希望通过我的讲解，能为各位扫去心中的疑惑。
如果我们去百度翻译上查询“dumb”一词的含义，得到的解释有2种：
- “哑的” 2. “傻的”
哑的 buffer ？什么鬼！而如果我们在 Ubuntu 下运行 man drm-memory 命令，则会得到如下关于 Dumb-Buffer 的解释：
These buffers can be memory mapped via mmap(2) so you can render into them on the CPU. However, GPU access to these buffers is often not possible.
大意就是该 buffer 通常不能用于 GPU 硬件加速，只能给 CPU 使用。但是不能用于硬件加速的 buffer 为什么要叫 dumb buffer 呢？为何不直接叫 simple buffer 呢？“dumb”一词在这里到底是什么含义呢？其实这还得从上世纪80年代的VGA显卡说起。
那时的显卡由一块很小的显存（通常为640x480）加一块数模转换电路（DAC）组成，说白了就是一块 Framebuffer + Display Controller。显卡的功能极其简单，只负责将显存中的图像数据转换成RGB信号发送出去即可，而所有的绘图操作则都交给 CPU 来完成。行业里将这种显卡称为 VGA Card，它的显存则被称为“Dumb Frame Buffer”。而到了后期，随着显卡技术的不断发展，许多原来由 CPU 干的活，渐渐的都被显卡取代了。从最初支持某些特定绘图指令（如画点、画线）的显卡，到后来支持视频解码的 Video Card，再到现代支持复杂3D渲染指令（如OpenGL）的 GPU 显卡，CPU 绘图的繁重任务彻底得到了解放。与 VGA Card 相比较，行业里将后来显卡的显存称为“Smart Frame Buffer”。首先从这两种称谓上我们就可以看出，dumb 是 smart 的反义词，因此 dumb 在这里的解释应该是“傻的”或“傻瓜式的”，而不是“哑的”。
(图片来自1992年的计算机杂志)
那为什么说用 CPU 画的 framebuffer 就很傻，而 GPU 画的 framebuffer 就很 smart呢？是歧视 CPU 吗？不了解 GPU 的小伙伴可能不知道，当我们要让 GPU 硬件渲染一副图像的时候，并不是简单的传给 GPU 一块 buffer 然后告诉他“你画吧！”就完事了，而是要将好几种不同类型的 buffer 都传给它，这些 buffer 包括 Command Buffer (绘图指令)、Vertex Buffer（顶点数据）、Texture Buffer（纹理数据，即图片）、Framebuffer（GPU最终输出的结果）等等，这样 GPU 才知道自己应该如何去绘制一幅图像（详见本人翻译的“Render Hell”文章）。而如果我们将这些 buffer 发送给一块早期的 VGA 显卡，那可就傻眼了！因为它根本不会去解析 framebuffer 里的数据，只会将它们一股脑的都发送出去，最终的结果可想而知。所以 dumb buffer 和 smart buffer 的区别就在于，你写到显存里的数据，是可以直接上屏显示的图像内容，还是一堆需要 GPU 来解析的命令和资源数据。 如果是前者，那我们就称之为“傻瓜式的” framebuffer，即 dumb buffer。因为它的“大脑”在 CPU 那，它的“智商”不足以解析 framebuffer 中的内容，所以它很“傻”。
当然，如果从另一个角度去理解，smart buffer 中的绘图命令和资源数据可以看作是 CPU 和 GPU 交流的媒介，它使得 smart buffer 对 GPU 而言具有了“交流”的能力，那么 dumb buffer 因为没有这种交流能力而被当成是个“哑巴”，似乎也说的过去。。。
总之，不管是“哑巴”还是“傻瓜”，dumb buffer 就代表了所有的绘图操作都由 CPU 来完成的 framebuffer。它只是一种软件功能上的定义，与你系统上是否带 GPU 硬件无关。即使你的硬件支持 GPU 加速，也不妨碍你使用 dumb buffer 来做 CPU 纯软绘的工作。正因为 dumb buffer 的这一功能特性，使得它普遍应用于简单 UI 场景，如 Android 的 Recovery 模式。
与 dumb buffer 命名类似的还有：
- dumb-terminal：不支持特殊字符的终端，如“清屏”、“粗体”、“彩色字符”等等
- dumb-panel：不带 GRAM 的 panel
- dumb-TV：与 Smart-TV 相反，指以前老式的黑白电视
如今的 IT 领域，dumb 一词更多的代表 “功能简单的”、“老式的”、“传统的” 含义。
“prime”一词在百度翻译中被解释为“主要的”、“典型的”，如果只是想表达“主要的”一词，为什么不用“primary”？而用过 drm-prime 的小伙伴都知道，PRIME 在 DRM 驱动中其实是一种 buffer 共享机制，它是基于 dma-buf 来实现的。既然如此，那为什么不直接叫 drm-dmabuf 呢？光从字面上看， PRIME 和 DMA-BUF 没有半点关系，这让初学者在刚接触 drm-prime 的时候感到十分困惑。其实 PRIME 这个名字的由来是有背景故事的，故事还得从 NVIDIA 说起。
2010年2月9日，NVIDIA 官方发布了一项新的双显卡技术 —— Optimus Technology。该技术主要运用于带双显卡的笔记本（集成显卡+独立显卡），可以根据当前集成显卡的工作负载，自动的将一部分图形任务交给独立显卡去处理，以此来达到功耗和性能的最佳平衡。举例来说，一个带 Intel 集成显卡和 NVIDIA 独立显卡的笔记本，通常将集成显卡做为默认显卡，且充当了 Display Controller 的角色。当用户使用办公软件时，由于需要渲染的任务量不多，此时直接由 Intel 集成显卡来完成。而当用户玩3D游戏时，由于图形渲染的负载较重，此时系统会将部分或全部的任务交给 NVIDIA 独立显卡去处理，等处理完后再将结果送回给集成显卡做最后的合成显示。而这整个过程都是由软硬件自动完成的，中间无需人为干预，用户体验十分流畅。只可惜，该技术只能用在 Windows 系统上，Linux 系统不支持。
再看当时的 Linux 开源社区，Dave Airlie （RedHat Graphics 工程师，DRM 社区 maintainer）正如火如荼地向社区提交着他的 vga_switcheroo patch —— 一种用于 Linux 下双显卡切换的技术，但同一时刻只能有1个GPU处于工作状态（请注意和 Optimus 技术区分开来，Optimus 允许同一时刻有2个 GPU 同时处于工作状态）。当 Dave 完成了他的 vga_switcheroo 提交后，他开始在业余时间里研究起 Optimus 技术，并琢磨着怎样在 Linux 平台上实现类似的功能。结果不到2周时间，他就做出了该方案的原型设计，并在自己的笔记本上（Intel集成显卡+ATI独立显卡）实现了该功能的验证。
就像他在自己博客中所描述的，他将这项技术命名为“PRIME”：
So NVIDIA unveiled their optimus GPU selection solution for Windows 7, so I decided to see what it would take to implement something similar under DRI. I’ve named it PRIME for obvious reasons.
关键是这句 “I’ve named it PRIME for obvious reasons.” 许多国人看不明白，怎么就 obvious 了？博客里也没给出进一步的解释。其实如果把 Optimus 和 Prime 组合在一起，它是一个人的名字，谁的名字？
没错！Optimus Prime 就是变形金刚 擎天柱 的名字！《变形金刚》系列动画最早从1984年就开始在美国盛行，后来在2007年的时候又开始推出一系列3D真人版大电影，因此对于当时国外的年轻人来说，Optimus Prime 这个名字是再熟悉不过的了。这里也不得不夸赞一下 NVIDIA 当初给他们 Optimus 技术命名的精妙之处：擎天柱本身所具有的变形能力，形象的表达了 Optimus 这项技术可以在功耗和性能之间来回自由变换；而擎天柱作为汽车人的统领，象征着 NVIDIA 是行业里双显卡技术的领军人物！回过头来再说 Dave 将他这项 Linux 下的技术命名为 “PRIME”，其实是很巧妙的玩了一把文字游戏，同时也隐晦的告诉大家：DRM Prime 技术就是用来对标 NVIDIA Optimus 技术的！
不过需要注意的是，当时的 PRIME 并不是基于 dma-buf 的，而是基于 shm （共享内存）的。但只可惜，Dave 提出了他的 PRIME 原型设计后，就没有再进一步跟进下去，理由是该项工作除了需要修改 DRM 公共代码，还涉及到底层 GPU 硬件驱动的修改，以及上层 X Server 整个架构的改动，工作量实在太大了。而此后他一直致力于 Multi-GPU 的上层修改中，直到2年后 dma-buf 被合入到 linux-3.3 后，他才又回到 PRIME 的开发中来，并于2012年3月最终合入到 linux-3.4 主线版本中，也就是我们今天看到的基于 dma-buf 架构的 PRIME 版本。
这里顺便提一下，在 PRIME 概念提出之后，另有一群开源爱好者为了让 NVIDIA Optimus 硬件也能在 Linux 下正常使用 ，他们发起了一个新的项目，名字叫“Bumblebee”！
没错，Bumblebee 就是变形金刚里奶狗奶狗的大黄蜂！如果说 PRIME 是 Linux 下 Multi-GPU Rendering （或者叫 GPU Offloading）的通用技术方案，那么 Bumblebee 则是为 NVIDIA 硬件专门定制的 Linux 下 Optimus 全套技术解决方案。该项目也是几经波折，中间还出现了不少闹剧，甚至人们一度怀疑该项目已经死了，但它其实到现在都还在维护中，感兴趣的同学可以直接点此链接访问它们的官网，这里就不赘述了。
总之，DRM 有太多的历史讲不完，但至少通过本文，你应该已经了解了为什么 DRM 中会有 DUMB 和 PRIME 这两个莫名其妙的词语了。下一节，我们将开始真正动手写一个最简单的 GEM 驱动程序，敬请期待！
