[OpenGL] OpenGL简介

一、摘要

本文简要介绍了OpenGL的发展历史，本文翻译自Preface: What is OpenGL?-OpenGLBook.com关于OpenGL的部分。

二、Opengl历史

0.什么是OpenGL

简单来讲，OpenGL 是一个软件接口，允许程序员与图形硬件进行通信。当然，它的内容远不止这些，本文接下来会解释 OpenGL 的更多细节。但在开始使用OpenGL进行编程之前，您可能需要了解一些计算机图形学和 OpenGL 的历史。

1.OpenGL的第一个十年

Silicon Graphics（通常称为SGI）是一家成立于1981年的公司，专门从事3D计算机图形学并专门为此目的开发软件和硬件。 SGI 开发的软件库之一是 IRIS GL（Integrated Raster Imaging System Graphical Library），用于在 SGI 的高性能工作站上生成 2D 和 3D 图形。该库曾经差一点发展成为 20 世纪 90 年代以来最重要的计算机图形开发之一。

在 20 世纪 90 年代初期，SGI 因其高性能硬件和易于使用的软件而成为 3D 图形工作站的市场领导者。 IRIS GL 是事实上的行业标准 3D 图形库，使所有其他开发和标准化 3D 图形接口的尝试黯然失色。尽管 IRIS GL 很受欢迎，但它仍然存在一个主要问题：它是一个与 SGI 自己的平台融合的专有系统，而竞争对手正在利用自己的 API（应用程序编程接口）来逼近 SGI 的优势。

之后SGI 采取了大胆的举措，清理了 IRIS GL，删除了所有与计算机图形无关的功能，并于 1992 年将其作为 OpenGL（Open Graphics Library）向公众发布，这是一种用于实时计算机图形的跨平台标准化 API。

软件供应商必须在其平台上提供自己的 OpenGL 标准实现，而硬件供应商则必须提供允许 OpenGL 与称为“设备驱动程序”的底层图形硬件对话的程序。 SGI 将其与一些高级 API 一起提供给他们的用户，而其他供应商也在追赶这个新的且易于使用的 API。

a.OpenGL的灵活性

由于 SGI 没有提供任何实际的源代码，只是提供了 API规范。这种抽象接口的出现让硬件和软件供应商可以自由地选择如何实现 OpenGL；这种抽象层次至今仍然存在。正因为如此，OpenGL 得到了许多平台和设备的支持；事实上，您将很难找到一个完全不支持 OpenGL 的现代平台。

但是，OpenGL 为实现者提供的最大优势可能是它对扩展的支持。如果 OpenGL 规范没有提供对特定功能的支持，硬件或软件供应商可以决定通过使用扩展功能自行添加该功能。许多厂商都选择这样做，它们的扩展可以通过前缀来区分，例如英伟达的NV_、苹果的AGL_，等等。扩展可以提供强大的功能，但通常只针对厂商自己实现的 OpenGL 支持。

然后，通过扩展加载机制在程序中加载这些扩展，并检索函数指针，就可以调用这些扩展提供的功能。然而，这种加载机制并没有标准化，因此每个平台都有自己特定的扩展加载函数。这种限制在 Microsoft Windows 平台上最为明显，因为 OpenGL 头文件自 OpenGL 1.1 版以来就没有更新过，即使在最新的 Windows 开发工具包中也是如此。本章稍后将详细介绍这种情况的原因。

b.一种开放的标准

之所以选择OpenGL这个名字，不仅仅是因为它听起来像个好听的术语，它还包含了一些实际的含义。由于 OpenGL 是一个不断发展的规范，因此必须有人来决定其中的内容。因此，1992 年成立了 ARB（OpenGL Architecture Review Board，OpenGL 架构审查委员会），该委员会由多家知名软件和硬件供应商组成，他们通过投票系统共同决定 OpenGL 标准的未来。除了决定将哪些新功能纳入 OpenGL 规范外，它还决定将哪些扩展功能提升为下一个 OpenGL 版本的核心功能。

尽管任何人都可以根据OpenGL规范指导，自由地开发 OpenGL 的实现方案，但要使其被认定为真正的 OpenGL 实现方案，ARB 必须通过一致性测试予以批准。这些测试通过严格的测试程序来验证实现者声称的与特定 OpenGL 版本的兼容性。

OpenGL 很快成为业界领先的实时图形应用程序接口，因为它基本上是多个平台上唯一可用的应用程序接口。

c.在Windows平台上的OpenGL

1993 年，微软公司的工作站操作系统 Windows NT 进入市场时，基于 UNIX 的工作站已经开始使用 OpenGL。Windows NT 是作为 UNIX 的直接竞争对手发布的，它支持联网（NT 首字母缩写的意思是网Network Technology）和 32 位硬件。Windows NT 引入了一些至今仍在使用的功能，如用于创建 Windows 应用程序的 Win32 API。但由于系统中没有 3D 图形库，微软承诺在 Windows NT 中添加对 OpenGL 的支持。

微软公司终于在 1994 年发布的 Windows NT 3.5 中实现了 OpenGL，但实现的 OpenGL 程度仅限于通过实现 SGI 公司当时提供的示例来实现兼容性。该示例实现的目的仅仅是演示如何实现 OpenGL，并为供应商提供指导。不用说，这种实现方式的速度慢得可怕，因为它没有经过优化，而当时 PC 上几乎不存在图形加速器。事实上，这个性能问题非常明显，以至于微软知识库中有一篇文章（KB121282）警告说，使用 NT 3.5 的 OpenGL 屏幕保护程序可能会降低机器的运行速度，因为它会占用计算机 CPU 的大量时间。

d.DirectX

微软之后看到了游戏市场的商机，于是为 Windows 开始寻找自己的 3D 图形 API，以吸引游戏开发人员抛开 DOS（微软的第一个操作系统），纯粹为 Windows 开发游戏。他们的首次尝试是 WinG，它只是将命令传递到底层的 GDI（Graphics Device Interface，图形设备接口）接口，不提供 3D 功能。为此，微软不得不在 1995 年收购了一家名为 RenderMorphics 的公司，该公司生产了一种名为 Reality Lab 的 3D 图形 API。该 API 更名为 Direct3D，并在名为 DirectX 的 SDK（Software Development Kit，软件开发工具包）中发布，其中还捆绑了其他一些游戏开发专用的 API：

• DirectDraw 可快速绘制 2D 图形
• DirectInput 用于捕捉操纵杆输入
• DirectPlay 用于联网和通信
• DirectSound 用于声音回放

Direct3D 的最初版本使用起来很不方便，开发人员采用该 API 的速度也很慢。这使得微软在继续支持 OpenGL 的同时，也在努力使 Direct3D 成为具有竞争力的 API。OpenGL 1.1 规范已在 Windows 95 和 Windows NT 4.0 中实现，它带来了急需的性能提升，但这也是微软最后一次更新 OpenGL的实现 ，转而采用自己的 API。

e."API"战争的开端

虽然微软一直坚持认为 OpenGL 最适合用于 “专业图形”，即工作站上的 CAD（Computer Aided Design，计算机辅助设计），但它已开始在视频游戏中得到应用，而微软正试图通过 DirectX 在 Windows 平台上主导视频游戏这一行业。OpenGL 最大的突破来自于 id Software 公司颇具影响力的开发人员约翰-卡马克（John Carmack）将其著名的视频游戏《Quake》移植到 Windows 平台上时使用 OpenGL API，并向开发人员展示了使用 OpenGL API 的便捷性。

1996 年 12 月，卡马克发布了一份文件，概述了他对 Direct3D API 的不满。他通过比较两种应用程序接口在屏幕上绘制三角形所需的代码，概述了这两种应用程序接口之间的差异；在他的示例中，OpenGL 只需要四行代码，而 Direct3D 则需要大量的命令和赋值。

卡马克直言不讳地描述方式严重损害了 Direct3D 的声誉，以至于 Direct3D 开发人员亚历克斯-圣-约翰（Alex St.约翰（Alex St. John）在 1997 年 2 月发表了一篇后续文章，为他的 API 辩护，而奇怪的是，微软也承认了它的缺陷。他解释说，Direct3D 在设计时考虑的是直接访问硬件而不是软件，由此产生的界面可能并不美观，但它依旧可以完成目标工作。微软再次强调，OpenGL 是一个 CAD 库，不会很快在消费类硬件上得到支持。

微软公司的这一回应激怒了 SGI ，1997 年 6 月，SGI对圣约翰的批评做出了自己的回应。这份冗长的文件概述了 “Direct3D 设计和当前实施中一些最显著的缺陷”。它从技术角度而非市场角度指出了两个 API 之间的差异，并通过更多的代码示例详细阐述了卡马克提到的易用性问题。

Direct3D 在 5.0 版本中变得更加实用，该版本删除了 API 中一些令人不舒服的功能。在这一点上，这两个应用程序接口都相当友好，功能集也很相似，但这种现状即将改变。

f.驱动灾难

由于 OpenGL 和 Direct3D 在 Windows NT 上处于胶着状态，微软亟需一个优势令Direct3D打败OpenGL。在 Windows NT 中，OpenGL 驱动程序是通过使用迷你客户端驱动程序（Mini-Client Driver，MCD）实现的，它是硬件和软件之间性能较低的折衷方案，但却是创建驱动程序最简单的解决方案。MCD 允许供应商挑选他们希望在硬件上加速的部分，而其余部分则在提供的软件实现上运行（反之亦然）。微软不允许在 Windows 95 上授权使用 MCD 来获得他们所需的竞争优势，从而有效地将 OpenGL 限制在微软提供的软件实现上。

这一决定对正试图进入消费市场的 OpenGL 来说是一个巨大的打击，更不用说那些几个月来一直在实现这些驱动程序的硬件供应商了。值得庆幸的是，SGI 提供了一种将硬件驱动程序引入 Windows 95 的解决方案，称为可安装客户端驱动程序 (Installable Client Driver，ICD)。事实上，这种实现方式比 MCD 驱动程序模式要快上好几倍，因此它被证明是一种不幸中的万幸。硬件供应商抓住这一机遇，迅速开始提供驱动程序。不久之后，游戏开发商开始在他们的游戏中使用 OpenGL，再次证明它是 Direct3D 的可行替代品。

g.硬件升级

20 世纪 90 年代末，OpenGL 成为三维计算机图形的行业标准，而不仅仅是 CAD 程序的标准，尽管它是该市场的唯一竞争者。诸如《Quake 2》、《虚幻》和《半条命》等 PC 视频游戏充分利用了 OpenGL 的优势，充分展示了自己的潜力，广受欢迎。大约在这个时候，第一款消费级专用 3D 图形硬件开始出现，从此改变了视频游戏行业。

最早的 3D 加速器之一是 3Dfx Interactive 的 Voodoo Graphics，这是一款高性能附加卡，一上市就树立了标准。虽然还有其他附加卡，如 ATI 3D Rage 和 S3 ViRGE，但 3Dfx 显卡在性能和功能上都远远超过了它们。除此之外，3Dfx 还提供了自己的 3D 图形 API，名为 Glide，可以直接访问底层图形硬件。在当时，Glide 是最快的 API，但由于它是针对特定供应商的，几年后就被竞争对手的 API 所淘汰。尽管如此，Glide 还是对整个行业产生了影响，导致其他应用程序接口在相当长的一段时间内处于追赶状态。

英伟达™（NVIDIA®）公司很快就在 1999 年推出了 GeForce 256 显卡，并称之为 GPU（图形处理器），它支持一种名为 “Transform & Lighting”（通常称为 T&L）的全新技术。T&L 将顶点变换计算和光照计算从计算机的 CPU 转移到了 GPU 上。GPU 的主要优势在于它能快速完成浮点运算，因为硬件专门用于这项任务，而 CPU 则专门用于整数和更通用的运算。3Dfx 从来没有实施过 T&L，这最终导致了他们的消亡，因为更多的在CPU上的运算都被转移到了 GPU 上。

3Dfx 破产后，英伟达™（NVIDIA®）公司收购了其大部分知识产权（包括著名的 SLI 技术），但没有继续 Voodoo 产品线，也没有支持 3Dfx 的任何旧产品。到 2000 年，GPU 市场上的竞争对手只剩下英伟达公司的 GeForce 2 和 ATI 公司的 Radeon 7000 系列 GPU。这两家厂商只支持 OpenGL 和 Direct3D，为这些应用程序接口的正面交锋扫清了障碍。

2.范式的转变

本世纪初，随着越来越多的软件功能被转移到 GPU 上，GPU 的性能呈指数级增长。由于 CPU 无法跟上 GPU 的发展，CPU 在渲染实时 3D 图形方面已经过时。事实上，当前的 3D 图形渲染方法将 CPU 视为主要瓶颈，因此必须发明新的方法来规避 CPU 的使用。

a.Buffers 缓冲

在此之前，为了在屏幕上进行渲染，程序员会从程序中发出一系列命令，由 GPU 进行解释，这就是所谓的即时模式(immediate mode)。这种方法在处理较小的数据集时表现良好，但在处理较大的数据集时，由于所有函数调用都来自程序本身，因此性能会受到 CPU 性能的影响。

新方法以**缓冲对象(buffer object)**的形式出现。缓冲对象以display lists 和 vertex arrays的形式出现已有一段时间，但它们各有缺点。display lists仍然使用即时模式，而vertex arrays则存储在系统内存中，因此每次调用都必须将它们传输到 GPU。

取而代之的是，新的缓冲对象将在初始化后存储在 GPU 的内存中，直到不再需要为止。在 OpenGL 中，这些对象被称为顶点缓冲对象（Vertex Buffer Objects，VBO），而在 Direct3D 中，它们被称为顶点缓冲区（Vertex Buffers）。

b.Shader 着色器

2000 年，微软发布了 Direct3D 8.0，它支持一种名为着色器(shader)的新功能。着色器基本上就是直接在 GPU 上运行的小程序，因此可以充分利用 GPU 的更多能力，并将更多的功能从 CPU 上移除。Direct3D 8.0 发布时，公布了两种类型的着色器，即顶点着色器(vertex shader)和像素着色器(pixel shader)。

顶点着色器是一种 GPU 程序，每个顶点执行一次。像素着色器也是一种 GPU 程序，每个像素执行一次。着色器在许多任务中无需使用 CPU，从而提高了可编程性和性能，但由于其语法类似于 CPU 的汇编语言，因此很难编程。

2003 年，随着 Direct3D 9.0 的发布，高级着色器语言（High-Level Shader Language，HLSL）在着色器方面取得了重大突破。这种新语言允许使用基于 C 语言语法的高级语言来操作着色器。此时，着色器的使用变得更加方便，并得到了广泛采用。

c.OpenGL的停滞

上段没有提到 OpenGL 是有原因的，那就是 OpenGL 当时不支持任何着色器。OpenGL 直到 2004 年才正式支持着色器，当时发布了 OpenGL 2.0 并同时发布了 OpenGL 着色语言 (OpenGL Shading Language，GLSL)。尽管使用着色器的扩展功能在 2004 年之前就已广泛存在，但它们并不是官方规范的一部分，需要数年时间才能顺利地实现。

在核心功能方面，OpenGL 已大大落后于 Direct3D。就像 Direct3D 在 90 年代末一直在追赶一样，OpenGL 现在也必须追赶 Direct3D，但这并没有实现。从 2004 年到 2006 年，Direct3D 9.0 在市场上占据主导地位，只有少数游戏支持 OpenGL。2005 年，支持 Direct3D 9.0 的 Xbox 360 发布后，对 Direct3D 的支持更上一层楼。在此期间，ARB 没有任何消息，OpenGL 似乎真的死了一段时间。

2006 年，OpenGL 2.1 作为原始 2.0 规范的一个小增量发布，只带来了少量新功能。雪上加霜的是，微软在发布新的 Windows Vista 操作系统的同时还发布了 Direct3D 10.0，其中包括对 API 的重大修改和许多新功能。硬件开始向新的方向发展，从即时模式、固定功能方法转向更可编程模式，而这正是 OpenGL 所缺乏的。
与此同时，OpenGL 开发者社区开始躁动不安，要求 ARB 或 SGI 给出答复，但得到的却是完全不同的结果。

3. 新一代OpenGL

在 2006 年的 SIGGRAPH 大会上，SGI 宣布 OpenGL 今后将由 Khronos 管理，SGI 仍拥有 OpenGL 和所有相关版权，但将不再对其进行管理。Khronos 是一个由硬件和软件厂商组成的联盟，与 OpenGL 有着千丝万缕的联系，主要致力于创建和维护开放标准的应用程序接口，在收购 OpenGL 之前最著名的是用于 3D 内容的 COLLADA 文件格式。最后，OpenGL 方面传来了一些消息，两年来首次传出 OpenGL API 的全新版本将带来一些重大变化。

a.代号Longs Peak 和 Mt. Evans

2007年OpenGL两个新版本发布了，临时代号为“Longs Peak”和“Mt. Evans”，以科罗拉多州的山脉命名。Longs Peak将是2007年夏天发布的第一个规范，而Mt. Evans将在几个月后的同年10月发布。

这些修订承诺提供全新的API，能够与Direct3D 10 API竞争，就像Direct3D 10所做的那样，Mt. Evans将取消即时模式渲染，只依赖缓冲区和着色器。这个API重写是一个伟大的事业，需要多个技术小组（Technical Sub-Groups，TSG）合作完成，他们专注于自己的OpenGL规范的专业领域。

其中之一是对象模型技术小组（Object Model TSG），它涉及如何在新的应用程序接口中表示缓冲区和其他类型的对象。提议的 "对象模型 "提出了一种只需调用几个函数即可创建对象的全新方法。最重要的是，通过使用模板，所有类型的对象所使用的方法都将保持一致。这意味着供应商之间将不再存在差异，供应商依旧可以使用不同方式提供对象创建功能。

Longs Peak将是一个与当时硬件兼容的API，并保留与旧版本OpenGL的向后兼容性，而Mt. Evans版本将取消向后兼容性，采取面向未来的立场。这与对象模型一起成为拟议 API 的主要内容，引起了 OpenGL 社区的广泛期待。

但 2007 年夏天过去了，Khronos 没有任何消息，到了 10 月 30 日，又传出新规范被推迟的消息。社区对此有些不满，但总体上认为新规范值得等待，于是又过了一年。

b.OpenGL 3.0

距离OpenGL 2.1 小版本发布已有两年之后，OpenGL 3.0 于 2008 年 7 月发布。在阅读规范后，我们很快就发现这不是 Longs Peak。事实上，它看起来并没有什么变化：即时模式依然存在，提议的对象模型不见了，也没有计划将其纳入 OpenGL 今后的任何版本中。在引入一些新功能的同时，还引入了一种叫做 **“弃用模式（deprecation model）”**的东西。

弃用模式将所有即时模式功能标记为弃用，转而使用更现代的方法。不过，OpenGL 3.0 并没有计划删除任何已废弃的功能，而是将其作为一个完全向后兼容的应用程序接口，并保留了过去的所有限制性功能。

这引起了社区的强烈不满，并在 OpenGL 社区留言板和其他网络媒体上提出了强烈抗议。有人揣测说，OpenGL 仍然向后兼容，是因为 Khronos 不想失去那些仍在使用即时模式并拒绝升级的 CAD 客户。许多 Windows 开发人员开始放弃 OpenGL，转而使用 Direct3D，其中包括一些被指责的 CAD 软件开发人员。如果说之前 OpenGL 的前景黯淡无光，那么这次的发布无疑让人看到了 OpenGL 在 API 大战中的彻底失败。

c.失望之后

但在最初的失望过后，新的规范被证明具有一些 Direct3D 所不具备的特性。例如，OpenGL 3.0 包含 Direct3D 10 的许多功能，但可以在 Windows XP 上使用，而 Direct3D 10 由于采用了新的驱动程序模式，需要 Windows Vista 才能运行。

大约一年后的 2009 年 3 月，OpenGL 3.1 发布，它终于删除了 OpenGL 规范中所有被 3.0 标注为废弃的即时模式功能，从而使其向 Longs Peak 和 Mt.Evans承诺的API更进了一步。随着这一快速版本的发布，OpenGL 终于回到了正确的道路上，仅仅几个月后，OpenGL 3.2 发布，通过加入几何着色器（Gemometry Shader），使 API 达到了 Direct3D 10 的水平。

d.弃用模式、核心模式和兼容性

OpenGL 弃用模式可能有点令人困惑，因此在本节中，我将尝试一次性解释相关术语。OpenGL 3.0 引入了一项名为 “弃用”（deprecation）的功能，用于 "标记 "旧的、不需要的 OpenGL 功能，并警告这些功能可能会在未来的规范中被移除；基本上，在程序中使用被弃用的功能不是一个好主意。

当开发人员希望在程序中使用 OpenGL 时，他们需要创建一个所谓的上下文，它基本上只是一个允许开发人员向 OpenGL 设备传递命令的对象。过去，无论实现的 OpenGL 版本如何，这些上下文都是以相同的方式创建的。
这意味着，当你创建一个使用 OpenGL 1.5 功能的设备时，如果驱动程序返回的是一个 OpenGL 2.0 设备，这并不会造成危害，因为所有上下文都是完全向后兼容的。OpenGL 3.0 引入了一种创建上下文的新方法，要求在创建上下文时使用以下参数：

• A major version number 主要版本号
• A minior version number 次版本号
• Optional attributes 可选属性

如果是 OpenGL 3.0 上下文，相应的值将是 3、0 和其他的一些属性组合。这一新功能可确保返回的设备是所请求的 OpenGL 设备，否则就意味着该版本不支持。可传递的属性使选择更加详细，包括以下属性之一：

• A Core Profile context flag 核心配置上下文标志
• A Compatibility Profile context flag 兼容性配置上下文标志
• A Forward Compatible flag 向前兼容标志
• A Debug flag 调试标志

前两个配置文件之间的区别在于，核心配置上下文标志不包含以前版本中删除的任何功能，而兼容性配置上下文标志包含这些功能。OpenGL 实现总是保证包含规范的核心配置上下文标志，但不一定包含兼容性配置上下文标志。采用核心配置上下文标志是最合乎逻辑的做法，也是创建此类上下文的初衷。
如果设置了向前兼容标志，返回的上下文将不包含您请求的版本中已废弃的任何功能，从而使其与可能已删除这些功能的未来版本兼容。
如果设置了调试标记，将返回一个调试上下文，其中包括额外的检查、验证和其他功能，在开发周期中非常有用。
上述标志都可以组合在一起，但核心配置上下文标志和兼容性配置上下文标志除外，因为只能返回其中一个。组合标志可使用位运算符 OR 或 C 语言中的 | 符号完成。

如果这些术语对你来说还有点模糊，别担心，我们会在附录中再次讲解，我们将在特定平台上从头开始设置 OpenGL 上下文。现在，请记住有两种 OpenGL 配置文件：Core（核心）和 Compatibility（兼容性），前者是更现代的配置文件，后者是兼容旧版 OpenGL 功能的配置文件。

e.OpenGL 4.0

OpenGL 3.2 发布一年后，OpenGL 4.0 作为最新一代 GPU 的应用程序接口发布，与 Direct3D 11 类似。与此同时，OpenGL 3.3 也发布了，它在兼容上一代硬件的同时，尽可能多地实现了 OpenGL 4.0 的功能。
OpenGL 4.0 中的一项重要新功能称为 “细分”（Tessellation），它允许对场景中的表面和自动细节级别进行精细控制。我们将在以后的章节中探讨什么是 "细分曲面 "以及如何使用它。

如果您已经了解一些即时模式 OpenGL，请注意我们不会介绍这种类型的 OpenGL。在OpenGLBook这本书中，你将找不到glBegin 、 glEnd 、 glVertex3f和glColor3f等命令（除了这些参考资料），因为 OpenGL 4.0 Core Profile 中没有这些命令。忘掉到目前为止所学到的关于即时模式 OpenGL 的所有知识，也忘掉即时模式 API 曾经存在过，因为它再也不会出现了。
现在是开始学习 OpenGL 的大好时机，因为视频游戏正被大量移植到 Microsoft Windows 以外的平台上，而在 Windows 以外的平台上获得实时计算机图形的唯一途径就是 OpenGL。例如，《半条命》的开发商 Valve 就使用 OpenGL 作为图形库，将他们的许多热门游戏移植到了苹果 Macintosh 上。

此外，现代智能手机（如 iPhone 和基于 Android 的手机）都使用 OpenGL ES 来制作交互式 3D 图形，这是一种基于嵌入式系统的 API，与 OpenGL 非常相似。这就意味着，您的代码可以移植到 PC、Mac、游戏机以及各种移动设备上运行。

OpenGL ES 本身催生了另一个名为 WebGL 的应用程序接口，这是一个跨浏览器、跨平台兼容的 3D 图形应用程序接口，适用于网络浏览器。这个库有可能将网络和多用户应用程序提升到一个全新的水平。
总之，OpenGL 远未消亡，它作为功能齐全的现代 3D 图形应用程序接口正在蓬勃发展。

4.软件流水线

在渲染实时计算机图形时，软件流水线的存在是为了描述我们希望在屏幕上看到什么。例如，如果我们想在屏幕上显示一个绿色的正方形，计算机软件就会描述该正方形的尺寸、颜色以及在屏幕的哪个位置绘制。
软件流水线还提供将几何图形绘制到屏幕上的功能。值得注意的是，软件流水线实际上并不进行任何绘制或变换，因为在现代系统中，这些功能完全由硬件实现。

软件流水线由几个不同的层组成，每个层都有自己非常特殊的用途。每一层都可能包含无数的功能，但为了简洁明了，我们只讨论每一层的高级功能。

第一层是应用层，也就是你的程序，调用绘图命令的程序。应用程序是整个进程的控制器，负责监督所有用户级操作，如创建窗口、线程、内存分配、复杂的用户数据类型，以及通过各自的接口调用 OpenGL 或 Direct3D 等外部库。

下一层是抽象层，其中包含 OpenGL 或 Direct3D API 实现。重要的是要区分应用层中的 API 和抽象层中的 OpenGL 和 Direct3D 实现。用 C 语言来说：您可以将应用层视为只包含定义的头文件，而抽象层则是包含实际功能的源文件。通过以可用的标准化格式实现硬件级功能，抽象层成为下一层的调度层。
抽象层将命令传递给设备驱动程序，这是一个与硬件连接的软件通信层。开发人员完全看不到这一层，因为无法通过程序与之交互。就像许多看不见的东西一样（还记得细菌吗），设备驱动程序是软件管道中最重要的部分之一，因为它将所有单独的部分连接在一起。由于设备驱动程序包含大量专业功能，其文件大小可能相当庞大。
设备驱动程序解释抽象层传递给它的命令，并以硬件可以理解和轻松处理的格式将这些命令转发给底层设备。

5.总结

现在，我们已经了解了计算机图形学和 OpenGL 的大部分背景知识，并知道了继续学习的要求，我们可以动手在下一章中设置 OpenGL 渲染上下文了。

三、参考引用

Preface: What is OpenGL?