Render Hell —— 史上最通俗易懂的GPU入门教程(一)

声明:文本非原创,只是翻译,原文链接如下:
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 (流水线/管线)

就像我文章开头说的,美术师的作品不过是一堆顶点和纹理数据的集合而已。要想把它们转换为令人惊艳的图像,显卡必须借助顶点来创建三角形,计算它们的光照,给它们涂上纹理像素等等,这些操作被称为 statePipeline 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 详解,或返回目录索引

发布了69 篇原创文章 · 获赞 150 · 访问量 14万+
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 编程工作室 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览