声明：文本非原创，只是翻译，原文链接如下：
https://simonschreibt.de/gat/renderhell-book1/

Render Hell – Book I

本文是 “Render Hell” 系列文章的第一篇。

如今对美术师的要求越来越高，因为在计算机眼里，他们提供的资源（asset）不过是一堆 顶点 和 纹理 数据的集合而已。而将这些数据转换为最终的图像，则主要是通过计算机中的 CPU 和 GPU 来完成的。

1. 拷贝数据到系统内存

最初，为了实现快速访问，所有的绘图数据都需要从硬盘（HDD）加载到系统内存（RAM）。而如今，那些顶点和纹理数据则会被加载到显存（VRAM）上，因为显卡访问 VRAM 的速度更快！

当 VRAM 中的纹理不再被需要时，就可以在 RAM 中将其删除（前提是你确定不再需要它们了，因为重新从硬盘上加载这些资源将会非常耗时）。而顶点数据则仍然需要保留在 RAM 中，因为大多数情况下 CPU 仍需要访问这些数据（比如碰撞检测（Collision Detection））。

好了，这下我们想要的数据都已经在显卡（VRAM）上了。但是数据从 VRAM 传输到 GPU 的速度还是太慢了！因为 GPU 工作的速度要比数据传输的速度快很多很多！

因此，硬件工程师将一小片内存直接塞进了处理器芯片里，这一小片内存通常被称为 片上缓存（on-chip Cache）。因为它的价格极其昂贵，所以在芯片设计时它的容量并不大，因此 GPU 只会拷贝当前所需的那一小部分数据到缓存上，而非全部数据。

现在，那一小部分数据被拷贝到了一个叫做 二级缓存（L2 Cache）的地方，它是一块很小的内存（在 NVIDIA GM204 上只有 2MB 大小），被放置在 GPU 内部，且访问速度要比 VRAM 快很多。

但即使是这样，二级缓存的访问速度还是不够快，导致 GPU 无法充分发挥它的性能！因此才有了 一级缓存（L1 Cache）（在 NVIDIA GM204 上只有 384KB 大小，4x4x24KB），它不仅被放置在 GPU 内部，还十分靠近 GPU 的 Core!
如果你想了解更多数字，可以 点此链接 查看。

另外，还有一块专用于 GPU Core 数据输入与输出的预留内存：寄存器 或 寄存器堆（register file）。GPU Core 从这里读取2个值，然后进行计算，并将计算的结果存放到某个寄存器中（通常该寄存器由寄存器堆中的内存地址来表示）。

接着将寄存器中的结果回写到 L1/L2/VRAM 中，用于腾出空间给寄存器堆存放新的数据。作为一名程序猿，通常是不需要关心这些细节的。

为什么会这么麻烦？就像前面提到的：这都是为了减少访问时间！如果你对比一下硬盘和一级缓存的访问时间，你会发现它们之间有着天壤之别！点此链接 查看更加精确的延迟数据。

在 GPU 开始执行渲染之前，CPU 会设置一些全局的参数，这些参数是用来描述那些网格该被如何渲染的，这些参数的集合就被称为 Render State（渲染状态） 。

2. 设置 Render State

Render State 是网格渲染方式的一种全局定义，它包含如下信息：
“顶点、像素着色器、纹理、材质、光照、透明度 等 …” [b01 第711页]

重点： CPU 命令 GPU 绘制的每个网格都将在这些条件下进行渲染！你可以渲染石头、椅子或宝剑 —— 如果在渲染下一个网格之前不更改 Render State，它们都将使用相同的渲染参数（例如材质）。

准备工作完成后，CPU 总算可以发送命令给 GPU 并告诉它需要画什么了，而这个命令就叫做：Draw Call。

3. Draw Call（绘图调用）

所谓 Draw Call 就是一条用来渲染网格的命令，它由 CPU 发出，并被 GPU 接收。该命令仅指向一个需要被渲染的网格，它不包含任何材质信息，因为这些信息早已在 Render State 中被设置。此时的网格正位于你的显卡中（VRAM）呢！

命令发出后，GPU 使用 Render State（材质、纹理、着色器）和所有顶点数据，通过代码魔法将这些信息转换为屏幕上的彩色像素，这个转换过程也被称为 Pipeline 。

4. Pipeline （流水线/管线）

就像我文章开头说的，美术师的作品不过是一堆顶点和纹理数据的集合而已。要想把它们转换为令人惊艳的图像，显卡必须借助顶点来创建三角形，计算它们的光照，给它们涂上纹理像素等等，这些操作被称为 state，Pipeline states。
根据你读过的文章，你会发现大部分事情都是由 GPU 来完成的。但有时他们会说，例如下图中的 Create Triangle 和 Create Fragment 步骤，则是由显卡的其他模块来完成的。

下面这个 Pipeline 示例非常简单，仅仅只是一个粗略的介绍，你也可以把它当作一个逻辑 Pipeline：每个三角形或像素都经过逻辑步骤，但实际发生的情况略有不同。所以，请不要太认真了，你也可以查阅我在文章底部留下的其他链接，或者通过邮件、推特、 facebook 给我留言，这样我就可以改进动画演示了。

如下为 GPU 渲染一个三角形的典型步骤：

渲染 说白了就是做大量的简单小任务，比如：计算上千个顶点，或者在屏幕上绘制数百万个像素点，这些任务至少要满足 30fps 的要求。

上面这些东西需要在同一时刻被计算出来，而不是一个接一个地计算每个顶点或像素。在早些年，CPU 只有一个 Core，也没有图形加速器，因此同一时刻只能处理一个任务，游戏看上去就很 。。。Low！如今的 CPU 已经有6-8个 Core 了，而 GPU 却有上千个 Core（它们不像 CPU Core 那么复杂，但非常适合处理大量的顶点和像素数据）。
更精确的 GPU Core 数字可以在 [a38], [a39], [a40], [a41], [a42] 或 Yeah 先生的留言中查看。

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。

5. Command Buffer（命令缓冲区）

Command Buffer 使得 CPU 与 GPU 之间的独立工作成为可能。当 CPU 想要绘制一些东西时，它可以将该指令塞到队列里。当 GPU 有可用硬件资源时，则会从该队列中取出指令并执行。该列表其实是一个 FIFO，因此 GPU 只能取出列表中最先放进去的指令执行。

顺便说一下，Command Buffer 中可能会存在不同的命令，一个例子是 Draw Call，另一个例子则是修改 Render State。

这就是第一篇，现在你应该对于渲染期间的资源数据、Draw Call、Render State 以及 CPU 与 GPU 之间的通信机制有所了解了。
继续阅读下一篇：Pipeline 详解，或返回目录索引。