Direct3D与OpenGL:对抗的历史

迄今为止,Internet上一直在争论哪种图形API更好:Direct3D或OpenGL?尽管具有宗教性质,但这种口头战以对硬件加速图形的发展的良好历史回顾的形式带来了有益的结果。

图片

这篇文章的目的是将这些旅行之一翻译成历史。由Jason L. McKesson撰写,以回答“为什么游戏开发人员更喜欢Windows”这一问题。本文不太可能回答所提出的问题,但是他以非常丰富多彩且相当详细的方式描述了发展史以及两种最受欢迎​​的图形API的对立关系,因此我在翻译中保留了作者的标记。文本编写于2011年中,涵盖了一段时间,从Direct3D出现之前开始直到撰写本文为止。原文的作者是经验丰富的游戏开发人员,也是StackOverflow 的积极参与者,并且是有关现代3D图形编程的广泛教科书的作者因此,让我们请杰森发言。

前言


在开始之前,我想说的是,我对OpenGL的了解比对Direct3D的了解还要多。我一生中没有用D3D编写任何代码,但是编写了OpenGL手册。但是,我想谈的不是偏见,而是历史。

冲突的诞生


一次,在90年代初左右,微软四处张望。他们发现SNESSega Genesis非常酷,您可以玩很多动作游戏等等。他们看到了要做的事。开发人员编写了dosovskie游戏作为游戏机:接近铁杆。但是,与控制台不同,在控制台中,开发人员知道用户将拥有哪种硬件,而dos开发人员则被迫在许多配置下进行编写。这比看起来要复杂得多。

但是微软有一个更大的问题:Windows。您会看到,Windows希望完全拥有硬件,这与DOS不同,DOS允许开发人员执行任何操作。拥有铁对于应用程序之间的交互是必要的。但是这种互动正是他们讨厌的。游戏开发人员,因为它消耗了宝贵的资源,可用于各种有趣的事物。

为了促进Windows上的游戏开发,Microsoft需要一个统一的API,该API是低级的,可以在Windows上运行而不会降低性能,并且要与各种硬件兼容。用于图形,声音和输入设备的单个API。

于是DirectX诞生了。

几个月后出现了3D加速器。微软陷入了麻烦。事实是DirectDraw是DirectX的图形组件,仅可用于2D图形:它分配了图形内存,并在内存的不同扇区之间进行了快速位操作。

因此,Microsoft购买了一些第三方软件,并将其转换为Direct3D版本3。绝对的一切。这是有原因的:在D3D v3上阅读代码看起来像是对已灭绝的古代文明的书面语言的解码。

Id Software的老人John Carmack看着这个耻辱,说“是的……”,并决定使用另一个API OpenGL进行编写。

但是,这个令人困惑的故事的另一面是,Microsoft与SGI合作为Windows实现了OpenGL。这个想法是为了吸引用于工作站的典型GL应用程序的开发人员:CAD,建模系统等。游戏是他们认为的最后一件事。这主要涉及Windows NT,但是Microsoft决定也将OpenGL添加到Windows 95中。

为了吸引Windows工作站软件开发人员,Microsoft决定贿赂他们以使用新型3D加速器。他们实现了用于已安装的客户端驱动程序的协议:图形卡可以用其硬件实现代替Microsoft的OpenGL软件。该代码自动使用硬件OpenGL(如果有)。

但是,在那时,消费类图形卡不支持OpenGL。这并没有阻止Carmack将Quake移植到SGI工作站上的OpenGL。您可以在GLQuake的自述文件中阅读以下内容:
, glquake OpenGL, texture objects. , , , . - , .

( 1997), opengl , glquake , intergraph realizm. 3dlabs , . 3dlabs glint permedia NT , glquake 3dlabs.

3dfx opengl32.dll, glquake, opengl. opengl- , « glquake».

这就是miniGL驱动程序的诞生。一旦硬件功能强大到足以在硬件中支持此功能,它们便最终演变为成熟的OpenGL实现。nVidia是第一个提供完整OpenGL实现的公司。其他供应商仍然很慢,这是在设备种类繁多的支持下过渡到Direct3D的原因之一。最后,仅剩下nVidia和ATI(现在为AMD),并且都具有良好的OpenGL实现。

OpenGL的曙光


因此,定义了参与者:针对OpenGL的Direct3D。考虑到D3D v3的糟糕程度,这真是一个了不起的故事。

OpenGL体系结构评审委员会(ARB)是负责维护和开发OpenGL的组织。他们发布了许多扩展,包含具有扩展的存储库,并创建了API的新版本。 ARB是一个由计算机图形行业的众多参与者和某些OS制造商组成的委员会。苹果和微软在不同时期也是ARB的成员。

3Dfx以其Voodoo2进入场景。这是第一张允许您进行多重纹理处理的视频卡,而以前的OpenGL中没有提供。虽然3Dfx强烈反对OpenGL,但下一代多纹理芯片(TNT1)的制造商nVidia却为OpenGL疯狂。然后,ARB发布了GL_ARB_multitexture扩展,该扩展提供了对多个纹理的访问。

同时,出现Direct3D v5。现在,D3D实际上已经成为一种API,而不是某种废话。怎么了在没有多重纹理的情况下。

哎呀

但这并没有带来它带来的不便,因为几乎没有人使用多重纹理。多重纹理化几乎不会损害性能,并且在许多情况下,在多重通过的背景下,这种差异是看不见的。当然,游戏开发人员非常喜欢他们的游戏在旧硬件上自信地工作,因为旧硬件不支持多种纹理,因此发布了很多没有它的游戏。

D3D松了一口气。

时间流逝,nVidia推出了GeForce 256(不要与首款GeForce GT-250混淆),从而在接下来的两年中停止了显卡市场的争夺。该评估板的主要竞争优势是能够在硬件中进行顶点和照明的转换(转换和照明,T&L)。但是,这还不是全部:nVidia的OpenGL的喜爱,以至于他们的T&L引擎实际上 OpenGL的。几乎从字面上看!据我了解,它们的某些寄存器直接接收了GLenum类型变量的数值。

Direct3D v6发布。最终,多种纹理及时出现了……但是没有硬件T&L。总是 OpenGL尽管在GeForce 256之前它是通过软件实现的,但这里有一条T&L管道。因此,对于nVidia来说,将软件实现重新构建为硬件解决方案非常简单。在D3D中,硬件T&L仅出现在第七版中。

着色器时代的黎明,黑暗中的OpenGL


然后是GeForce3。与此同时,发生了许多有趣的事情。

微软决定他们不再迟到了。因此,微软没有看nVidia会做什么,而是在事后复制他们的开发成果,而是做出了一个了不起的决定:闲聊。他们坠入爱河,他们得到了一个联合的小控制台。

吵闹的离婚后来发生,但这是一个完全不同的故事。

对于PC市场,这意味着GeForce 3与D3D v8同时出现,并且很容易看出GeForce 3如何影响D3D v8着色器。 Shader Model 1.0的像素着色器非常对于nVidia设备大大提高了。没有做出任何尝试从铁中提取nVidia的尝试。 Shader Model 1.0是GeForce 3的设计目标,

当ATI凭借Radeon 8500进入图形性能竞赛时,出现了一个问题。事实证明,Radeon 8500像素管线比nVidia更强大。因此,微软发布了Shader Model 1.1,基本上就是8500

的用途,听起来像D3D失败,但是成功和失败是相对的。实际上,史诗般的失败正在等待OpenGL。

NVidia非常喜欢OpenGL,因此在GeForce 3发布之后,他们发布了一大堆OpenGL扩展。专有的仅适用于nVidia的扩展。自然,当8500板出现时,它不能使用任何一个。

因此,在D3D 8上,您至少可以运行SM 1.0着色器。当然,为了使用8500的所有功能,我不得不编写新的着色器,但是代码至少可以正常工作

为了在OpenGL的Radeon 8500上获得任何着色器,ATI必须为OpenGL开发一些扩展。仅在ATI上可用的专有扩展。结果,为了使开发人员可以声明他们将着色器固定在引擎上,他们必须为nVidia编写单独的代码,为ATI编写单独的代码。

您可能会问:“应该支持OpenGL的ARB委员会在哪里?”他们是许多委员会最终的所在地:他们坐着很愚蠢。

请注意,我在上面提到了ARB_multitexture,因为此扩展与整个情况密切相关。在外部观察者看来,ARB通常希望避免着色器的想法。他们决定,如果将足够的可配置性注入固定的管线中,那么它的功能将与可编程的着色器管线相同。

ARB一一发布了扩展程序。名称中每个带有“ texture_env”字样的扩展都是为了修补此老化设计。看一下扩展列表:已经发布了八个这样的扩展部件,其中许多部件已转换为OpenGL核心功能。

当时,微软是ARB的一部分,并且仅将其保留给D3D 9发行,因此也许微软以某种方式破坏了OpenGL。我个人对此理论表示怀疑,有两个原因。首先,他们将必须获得委员会其他成员的支持,因为每个成员只有一票。其次,也是更重要的是,委员会不需要微软的帮助来搞砸一切,我们将在以后提供证据。

结果,ARB极有可能在ATI和nVidia(都是积极参与者)的压力下最终醒悟,并将汇编着色器引入了标准。

想要一个更古怪的故事吗?

硬件T&L。这就是OpenGL 最初的功能。。为了获得最高的硬件T&L性能,您需要在GPU上存储顶点数据。尽管如此,GPU仍是顶点数据的主要使用者。

在D3D v7中,Microsoft引入了顶点缓冲区的概念,它可以在GPU中分配内存块并将顶点数据放置在其中。

想知道等效功能何时在OpenGL中出现?是的,作为最大的OpenGL风扇,nVidia在GeForce 256发行时就发布了将顶点阵列存储在GPU上的扩展。但是ARB何时引入了这种功能?

两年后。那是它如何批准顶点和片段(以D3D表示的像素)着色器。ARB花了很多时间来开发用于在GPU内存中存储顶点数据的跨平台解决方案。这就是硬件T&L达到最高性能所需要的

一种语言可以杀死所有人


因此,OpenGL已经被破坏了一段时间。 GPU中没有跨平台的着色器和与硬件无关的顶点存储,而D3D用户则喜欢两者。会变得更糟吗?

您可以说可以。见面:3D Labs

您问:他们是谁?他们是一家死掉的公司,我认为它是OpenGL的真正杀手。当然,委员会的普遍失败使OpenGL易受攻击,而应该将D3D撕成碎片。但是我认为3D Labs也许是OpenGL当前市场地位的唯一原因。他们为此做了什么?

他们为OpenGL开发了着色器语言。

3D Labs是一家垂死的公司。由于nVidia的压力越来越大,他们昂贵的GPU已被挤出工作站市场。与nVidia不同,3D实验室并未引入消费市场。 nVidia的胜利将意味着3D Labs的死亡。

最终发生了什么。

为了在不需要产品的世界中生存,3D Labs在游戏开发者大会上展示了他们所谓的“ OpenGL 2.0”。这是一个从头开始重写的OpenGL API。这是有道理的,因为在那些日子里OpenGL API充满了垃圾(但是直到今天仍然存在)。至少看一看在美学上如何完成纹理的加载和绑定。

他们提议的一部分是着色器语言。是的,他是。但是,与现有的跨平台扩展不同,它们的着色器语言是“高级”的(C是着色器语言的高级)。

同时,Microsoft正在开发自己的着色器语言。他们,包括他们所有的集体想象力,被称为……高级着色器语言(HLSL)。但是他们对语言的态度根本不同。

3D Labs的最大问题是它是可嵌入的。 Microsoft完全确定了自己的语言。他们发布了一个编译器,该编译器为SM 2.0着色器(或更高版本)生成了汇编代码,然后可以将其馈送到D3D。在D3D v9时代,HLSL从未直接接触过D3D。他是一个很好的但可选的抽象。开发人员总是有机会让编译器精疲力尽并对其进行调整,以实现最佳性能。

3D Labs 没有这些。给驱动程序提供一种类似于C的语言,它会创建一个着色器。仅此而已。没有汇编着色器,没有任何东西可以提供给其他东西。仅表示着色器的OpenGL对象。

对于OpenGL用户,这意味着他们容易受到刚刚学会如何编译类似汇编语言的OpenGL开发人员的异想天开。 OpenGL着色器语言编译器(GLSL)一直对bug充满愤怒。更糟糕的是,如果您能够使着色器在不同的平台上正确编译(这本身就是一个很大的成就),那么它仍然受到那些当时未达到最佳状态的优化器的约束

这是GLSL的一大缺点,但并非唯一。远非唯一。

在D3D中,就像在旧的OpenGL汇编语言中一样,您可以以各种可能的方式混合和匹配顶点和片段着色器。如果顶点着色器通过同一接口进行交互,则可以将其与任何兼容的片段着色器一起使用。此外,甚至允许某些不兼容的情况:例如,顶点着色器可能会输出片段着色器未使用的值。

GLSL中没有类似的东西。顶点着色器和片段着色器融合在一起,形成称为3D Labs的“软件对象”。因此,为了以多种组合方式联合使用多个顶点着色器和片段着色器,有必要创建多个程序对象。这引起了第二大问题。

3D Labs认为他们是最聪明的。他们将C / C ++作为GLSL编译模型的基础。这是当您获取一个c文件并将其编译为一个目标文件,然后获取多个目标文件并将其组成一个程序时。 GLSL的编译方式如下:首先将顶点或片段着色器编译为着色器对象,然后将这些对象放入程序对象中,然后将它们放在一起以最终形成程序。

从理论上讲,这允许显示“库”着色器之类的很酷的东西,其中包含主着色器调用的代码。实际上,这导致着色器被编译两次:在编译阶段一次,在编译阶段第二次。尤其是nVidia的编译器为此而闻名。它没有生成任何中间目标代码。他从一开始就进行编译,将结果扔掉,然后在编译阶段再次进行编译。

因此,为了将顶点着色器附加到两个不同的片段着色器,必须比在D3D中进行更多的编译。特别是考虑到整个编译是脱机完成的,而不是在直接执行程序之前完成的。

GLSL还有其他问题。将所有错误归咎于3D Labs也许是错误的,因为最终ARB批准并在OpenGL中包含了着色器的语言(但3DLabs建议中没有其他内容)。但是,最初的想法仍然是3D Labs。

现在最可悲的事情是:3D Labs是对的(大多数情况下)。 GLSL当时不像HLSL那样是矢量语言。发生这种情况是因为3D Labs的硬件是标量的(例如nVidia的现代硬件),并且他们完全正确地选择了许多设备制造商后来遵循的方向。

他们选择了“高级”语言的编译模型是正确的。甚至D3D终于来到了这一点。

问题在于3D Labs在错误的时间是正确的。为了过早地进入未来,为未来做好准备,他们放弃了现在。看起来一直是OpenGL中的T&L功能。除了OpenGL T&L管道有用在硬件T&L出现之前,GLSL在世界其他地区追赶他之前是一个负担。

GLSL 现在是一种好语言但是那个时候是什么?他太可怕了。OpenGL遭受了这一痛苦。

在通往神化的路上


我支持3D实验室对OpenGL造成致命打击的观点,但棺材中的最后一个钉子是ARB自己打的。

您可能已经听过这个故事。在OpenGL 2.1时代,OpenGL存在很多问题。他承担着巨大的兼容性。该API不再易于使用。可以用五种不同的方式来完成一件事,但不清楚哪一种更快。您可以通过简单的教程“学习” OpenGL,但您没有学习提供真正图形功能和性能的OpenGL。

ARB决定再次尝试发明OpenGL。就像3D Labs的“ OpenGL 2.0”一样,但效果更好,因为ARB支持此尝试。他们称其为“龙峰”。

花一点时间改善API有什么不好?坏消息是微软处于一个不稳定的位置。这是升级到Vista的时候。

在Vista中,Microsoft决定对图形驱动程序进行逾期未交的更改。他们迫使驱动程序转向操作系统以实现图形内存和其他许多虚拟化。

您可以争论这种方法的优点,甚至是否可行,但事实仍然存在:Microsoft仅针对Vista和更高版本制作了D3D 10。即使在兼容 D3D的硬件上,如果没有Vista也无法运行D3D应用程序。

您可能还记得Vista。。。说得不好。因此,我们拥有一个悠闲的OS,一个仅在该OS上运行的新API,以及新一代需要该API和OS做一些事情的硬件,而不仅仅是在性能上超越了上一代。

但是,开发人员可以通过OpenGL使用D3D 10级功能。也就是说,如果ARB不忙于在Long Peaks工作,他们可以。

ARB花了一年半到两年的时间来改进API。到OpenGL 3.0发行之时,向Vista的过渡已经结束,Windows 7即将到来,游戏开发人员不再关心D3D 10级别的功能,最终,D3D 10的设备可以与D3D 9上的应用程序完美地配合使用。控制台(或随着PC开发人员向控制台市场的过渡),开发人员对D3D 10功能的需求越来越少。

如果开发人员即使在Windows XP上也可以使用此功能,则OpenGL的开发可以赋予生命力。但是ARB错过了这个机会。您是否想知道最坏的情况?

ARB 失败尽管花了两年的宝贵时间才从头开始发明API。因此,他们返回了现状,仅添加了一种宣布功能已过时的机制。

结果,ARB不仅错过了关键的机会,而且也未能完成导致他们遗漏的工作。这是全方位的史诗性失败。

这是OpenGL与Direct3D之间对抗的故事。错过机会,最大的愚蠢,故意的鲁ck和平庸的荒诞故事。

Source: https://habr.com/ru/post/zh-CN397309/


All Articles