如今对美术师的要求越来越高，因为在计算机眼里，他们提供的资源（asset）不过是一堆 顶点 和 纹理 数据的集合而已。而将这些数据转换为最终的图像，则主要是通过计算机中的 CPU 和 GPU 来完成的。
最初，为了实现快速访问，所有的绘图数据都需要从硬盘（HDD）加载到系统内存（RAM）。而如今，那些顶点和纹理数据则会被加载到显存（VRAM）上，因为显卡访问 VRAM 的速度更快！
因此，硬件工程师将一小片内存直接塞进了处理器芯片里，这一小片内存通常被称为 片上缓存（on-chip Cache）。因为它的价格极其昂贵，所以在芯片设计时它的容量并不大，因此 GPU 只会拷贝当前所需的那一小部分数据到缓存上，而非全部数据。
但即使是这样，二级缓存的访问速度还是不够快，导致 GPU 无法充分发挥它的性能！因此才有了 一级缓存（L1 Cache）（在 NVIDIA GM204 上只有 384KB 大小，4x4x24KB），它不仅被放置在 GPU 内部，还十分靠近 GPU 的 Core!
接着将寄存器中的结果回写到 L1/L2/VRAM 中，用于腾出空间给寄存器堆存放新的数据。作为一名程序猿，通常是不需要关心这些细节的。
在 GPU 开始执行渲染之前，CPU 会设置一些全局的参数，这些参数是用来描述那些网格该被如何渲染的，这些参数的集合就被称为 Render State（渲染状态） 。
Render State 是网格渲染方式的一种全局定义，它包含如下信息：
“顶点、像素着色器、纹理、材质、光照、透明度 等 …” [b01 第711页]
重点： CPU 命令 GPU 绘制的每个网格都将在这些条件下进行渲染！你可以渲染石头、椅子或宝剑 —— 如果在渲染下一个网格之前不更改 Render State，它们都将使用相同的渲染参数（例如材质）。
准备工作完成后，CPU 总算可以发送命令给 GPU 并告诉它需要画什么了，而这个命令就叫做：Draw Call。
所谓 Draw Call 就是一条用来渲染网格的命令，它由 CPU 发出，并被 GPU 接收。该命令仅指向一个需要被渲染的网格，它不包含任何材质信息，因为这些信息早已在 Render State 中被设置。此时的网格正位于你的显卡中（VRAM）呢！
命令发出后，GPU 使用 Render State（材质、纹理、着色器）和所有顶点数据，通过代码魔法将这些信息转换为屏幕上的彩色像素，这个转换过程也被称为 Pipeline 。
就像我文章开头说的，美术师的作品不过是一堆顶点和纹理数据的集合而已。要想把它们转换为令人惊艳的图像，显卡必须借助顶点来创建三角形，计算它们的光照，给它们涂上纹理像素等等，这些操作被称为 state，Pipeline states。
根据你读过的文章，你会发现大部分事情都是由 GPU 来完成的。但有时他们会说，例如下图中的 Create Triangle 和 Create Fragment 步骤，则是由显卡的其他模块来完成的。
下面这个 Pipeline 示例非常简单，仅仅只是一个粗略的介绍，你也可以把它当作一个逻辑 Pipeline：每个三角形或像素都经过逻辑步骤，但实际发生的情况略有不同。所以，请不要太认真了，你也可以查阅我在文章底部留下的其他链接，或者通过、、 给我留言，这样我就可以改进动画演示了。?
如下为 GPU 渲染一个三角形的典型步骤：
渲染 说白了就是做大量的简单小任务，比如：计算上千个顶点，或者在屏幕上绘制数百万个像素点，这些任务至少要满足 30fps 的要求。
上面这些东西需要在同一时刻被计算出来，而不是一个接一个地计算每个顶点或像素。在早些年，CPU 只有一个 Core，也没有图形加速器，因此同一时刻只能处理一个任务，游戏看上去就很 。。。Low！如今的 CPU 已经有6-8个 Core 了，而 GPU 却有上千个 Core（它们不像 CPU Core 那么复杂，但非常适合处理大量的顶点和像素数据）。
更精确的 GPU Core 数字可以在 或 中查看。
Gustav 和 Christoph 对 Core 的那段描述做了一些补充，以解释为何 CPU 与 GPU 的 Core 数量存在如此差异：
现代的 CPU 有4-8个 Core，每个 Core 可以同时执行4-8个浮点操作，因此我们假设 CPU 有64个浮点执行单元，然而 GPU 却可以有上千个这样的执行单元。仅仅只是比较 GPU 和 CPU 的 Core 数量是不公平的，因为它们的职能不同，组织形式也不同。GPU 厂商倾向于使用 Core 作为最小的执行单元，而 CPU 厂商则倾向于使用更高级的单元。在 Book II 中将会阐述 GPU 内部由高到低执行单元组织形式的更多细节。
当数据（例如一堆顶点）进入到 Pipeline 阶段时，转换顶点或像素的工作就被分配到多个 Core 上去完成，这样才能将大量微小元素经过并行处理后生成一张大图片：
现在我们知道了，GPU 是可以并行的工作的。但是 CPU 与 GPU 之间的通信又是怎样的呢？CPU 是否需要一直等到 GPU 任务完成后才开始发送下一条指令呢？
NO！
谢天谢地还好不是！因为这样的通信方式会造成性能瓶颈（比如，CPU 无法足够快的下发命令），同时无法实现 CPU 与 GPU 的并行工作。解决方法就是创建一个列表，该列表可供 CPU 添加指令，由 GPU 读取指令，相互独立，互不干扰！这个列表即为：Command Buffer。
Command Buffer 使得 CPU 与 GPU 之间的独立工作成为可能。当 CPU 想要绘制一些东西时，它可以将该指令塞到队列里。当 GPU 有可用硬件资源时，则会从该队列中取出指令并执行。该列表其实是一个 ，因此 GPU 只能取出列表中最先放进去的指令执行。
顺便说一下，Command Buffer 中可能会存在不同的命令，一个例子是 Draw Call，另一个例子则是修改 Render State。
这就是第一篇，现在你应该对于渲染期间的资源数据、Draw Call、Render State 以及 CPU 与 GPU 之间的通信机制有所了解了。
继续阅读下一篇：，或返回。