这里的许多答案都非常非常好。但是，应该解决OpenGL和Direct3D（D3D）问题。这需要...历史课程。
在开始之前，我对OpenGL的了解比对Direct3D的了解还要多。我一生中从未写过任何D3D代码，而且我已经在OpenGL上编写了教程。因此，我要说的不是偏见问题。这完全是历史问题。
冲突的诞生
有一天，在90年代初的某个时候，微软向四周张望。他们看到SNES和Sega Genesis很棒，可以运行很多动作类游戏。他们看到了DOS。开发人员编写了诸如主机游戏之类的DOS游戏的代码：直接开发。但是与控制台不同，在控制台上，开发SNES游戏的开发人员知道用户将拥有什么硬件，而DOS开发人员则必须编写多种可能的配置。这比听起来要难得多。
微软有一个更大的问题：Windows。与DOS不同，Windows希望拥有硬件，而DOS却可以让开发人员做任何事情。为了拥有应用程序之间的协作，必须拥有硬件。合作正是游戏开发人员所讨厌的，因为合作会占用宝贵的硬件资源，而他们可能会使用这些资源来提高性能。
为了促进Windows上的游戏开发，Microsoft需要一个统一的API，该API是低级的，并且可以在Windows上运行且不受其影响，并且大多数都是跨硬件的。适用于所有图形，声音和输入硬件的单个API。
因此，DirectX诞生了。
3D加速器在几个月后诞生。微软遇到了麻烦。参见DirectX的图形组件DirectDraw，它仅处理2D图形：分配图形内存并在内存的不同分配部分之间进行位清除。
因此，微软收购了一下中间件，它塑造成Direct3D的版本3.据普遍唾骂。并且有充分的理由；查看D3D v3代码就像凝视《约柜》一样。
Id Software的老约翰·卡马克（John John Carmack）看着那个垃圾，说道：“拧紧！” 并决定编写另一个API：OpenGL。
瞧瞧，这头猛兽中的另一部分是Microsoft一直在忙于在Windows的OpenGL实现中使用SGI。这里的想法是向典型的GL应用程序的开发人员求助：工作站应用程序。CAD工具，建模之类的东西。游戏是他们心目中最遥远的事情。这主要是Windows NT，但Microsoft决定也将其添加到Win95。
为了吸引工作站开发人员使用Windows，Microsoft决定尝试贿赂他们以使用这些新型3D图形卡。微软实现了Installable Client Driver协议：图形卡制造商可以使用基于硬件的协议来替代微软的软件OpenGL实现。如果可用，代码可以自动仅使用硬件OpenGL实现。
早期，消费者级别的视频卡虽然不支持OpenGL。这并没有阻止Carmack仅仅将Quake移植到他的SGI工作站上的OpenGL（GLQuake）。正如我们从GLQuake自述文件中看到的：
从理论上讲，glquake将在支持纹理对象扩展的任何兼容OpenGL上运行，但是除非它是非常强大的硬件来加速所需的一切，否则游戏将无法接受。如果必须通过任何软件仿真路径，则性能可能会大大低于每秒一帧。
目前（97年3月），唯一可以合理地发挥作用的标准opengl硬件是鹰图实现，这是一张非常昂贵的卡。3dlabs一直在显着提高其性能，但是使用可用的驱动程序仍然不够好玩。从全屏运行退出时，当前用于glint和permedia板的某些3dlabs驱动程序也会在NT崩溃，因此，我不建议在3dlabs硬件上运行glquake。
3dfx提供了一个opengl32.dll，它可以实现glquake所需的一切，但它不是完整的opengl实现。其他opengl应用程序不太可能与它一起使用，因此基本上将其视为“ glquake驱动程序”。
这就是miniGL驱动程序的诞生。随着硬件功能强大到足以在硬件中实现大多数OpenGL功能，这些技术最终演变为完整的OpenGL实现。nVidia是第一个提供完整OpenGL实现的公司。许多其他供应商都在苦苦挣扎，这就是开发人员偏爱Direct3D的原因之一：它们与更广泛的硬件兼容。最终仅剩下nVidia和ATI（现在为AMD），并且都具有良好的OpenGL实现。
OpenGL崛起
这样就设置了阶段：Direct3D与OpenGL。考虑到D3D v3的糟糕程度，这真是一个了不起的故事。
OpenGL体系结构评审委员会（ARB）是负责维护OpenGL的组织。他们发布许多扩展，维护扩展存储库，并创建API的新版本。ARB是由许多图形行业参与者以及某些OS制造商组成的委员会。苹果和微软在不同时间都是ARB的成员。
3Dfx随Voodoo2一起推出。这是第一个可以进行多重纹理处理的硬件，这是OpenGL以前无法做到的。虽然3Dfx强烈反对OpenGL，但下一代多纹理图形芯片（TNT1）的制造商NVIDIA很喜欢它。因此，ARB发布了扩展名：GL_ARB_multitexture，它将允许访问多重纹理。
同时，Direct3D v5发布了。现在，D3D已成为实际的API，而不是猫可能会呕吐的东西。问题？没有多重纹理。
哎呀。
现在，由于人们没有过多地使用多重纹理，因此该伤害几乎不会达到应有的程度。不直接。多重纹理会严重影响性能，在许多情况下，与多重传递相比，这是不值得的。当然，游戏开发人员喜欢确保自己的游戏可以在较旧的硬件上运行，而这些硬件没有多重纹理，因此很多游戏都没有它。
因此，D3D被判缓刑。
随着时间的流逝，NVIDIA部署了GeForce 256（不是GeForce GT-250；这是第一个GeForce），在接下来的两年中，显卡的竞争几乎结束了。主要卖点是能够在硬件中执行顶点变换和照明（T＆L）。不仅如此，NVIDIA非常热爱OpenGL，因此他们的T＆L引擎实际上就是 OpenGL。几乎从字面上看；据我了解，它们的某些寄存器实际上直接将OpenGL枚举数作为值。
Direct3D v6发布。最后是多纹理，但是没有硬件T＆L。OpenGL 一直有一条T＆L管道，即使在256条之前是通过软件实现的。因此，对于NVIDIA而言，将其软件实现转换为硬件解决方案非常容易。直到D3D v7才最终获得硬件T＆L支持。
着色器的曙光，OpenGL的黄昏
然后，GeForce 3出现了。同时发生了很多事情。
微软已经决定他们不会再迟到了。因此，他们没有看NVIDIA在做什么，而是在事后照搬了它，而是采取了惊人的立场去与他们交谈。然后他们相爱了，在一起有了一个小小的控制台。
随后发生了混乱的离婚。但这是另外一次。
这对PC而言意味着GeForce 3与D3D v8同时发布。不难看出GeForce 3如何影响D3D 8的着色器。支持Shader Model 1.0的像素着色器是非常具体的，以NVIDIA的硬件。从未尝试过抽象NVIDIA的硬件。SM 1.0就是GeForce 3所做的。
当ATI开始使用Radeon 8500进入性能显卡竞赛时，出现了问题。8500的像素处理管线比NVIDIA的强大。因此，微软发布了Shader Model 1.1，基本上就是“ 8500所做的一切”。
这听起来像D3D的失败。但是失败和成功是度的问题。而史诗故障是发生在OpenGL的土地。
NVIDIA喜欢OpenGL，因此当GeForce 3推出时，他们发布了一系列OpenGL扩展。专有的 OpenGL扩展：仅NVIDIA。自然而然地，当8500出现时，它不能使用它们中的任何一个。
至少在D3D 8平台上，您可以在ATI硬件上运行SM 1.0着色器。当然，您必须编写新的着色器才能利用8500的凉爽度，但是至少您的代码有效。
为了在OpenGL的Radeon 8500上具有任何种类的着色器，ATI必须编写许多OpenGL扩展。专有的 OpenGL扩展：仅ATI。因此，您需要一个NVIDIA代码路径和一个ATI代码路径，才能完全使用着色器。
现在，您可能会问：“ OpenGL ARB在哪里，它是使OpenGL保持最新状态的工作？” 许多委员会经常结局的地方：不要傻了。
看到了，我在上面提到了ARB_multitexture，因为它是所有这些的深层因素。从局外人的角度来看，ARB似乎想完全避免着色器的想法。他们认为，如果将足够的可配置性应用于固定功能管道，则它们可以等同于着色器管道的功能。
因此，ARB在扩展后发布了扩展。其中每个带有“ texture_env”字样的扩展都是对这种老化设计进行修补的另一种尝试。检查注册表：在ARB和EXT扩展之间，进行了八个扩展。许多已升级为OpenGL核心版本。
微软此时是ARB的一部分。他们在D3D 9命中时就离开了。因此，他们完全有可能以某种方式破坏OpenGL。我个人对此理论有怀疑，有两个原因。第一，他们将不得不从其他ARB成员那里获得帮助，因为每个成员只有一票。最重要的两个是，ARB不需要Microsoft的帮助即可解决问题。我们将进一步证明这一点。
最终，ARB可能受到ATI和NVIDIA（均为活跃成员）的威胁，最终他们伸出了足够的头以提供实际的装配样式着色器。
想要什至是愚蠢的东西吗？
硬件T＆L。OpenGL 首先要具备的功能。好吧，这很有趣。为了从硬件T＆L中获得最大的性能，您需要将顶点数据存储在GPU上。毕竟，实际上是GPU要使用您的顶点数据。
在D3D v7中，Microsoft引入了顶点缓冲区的概念。这些是为分配顶点数据而分配的大量GPU内存。
是否想知道OpenGL何时获得了等效的支持？噢，NVIDIA是OpenGL的全部爱好者（只要它们是专有的NVIDIA扩展），就在GeForce 256首次发布时发布了顶点阵列范围扩展。但是ARB何时决定提供类似功能？
两年后。这是在他们批准了顶点和片段着色器（D3D语言中的像素）之后。这就是ARB开发跨平台解决方案以在GPU内存中存储顶点数据所花的时间。同样，硬件T＆L 需要达到最高性能的要求。
一种语言摧毁所有人
因此，OpenGL开发环境曾一度破裂。没有跨硬件着色器，也没有跨硬件GPU顶点存储，而D3D用户则同时享受了两者。会变得更糟吗？
你...你可以这么说。输入3D Labs。
您可能会问他们是谁？他们是一家已经停业的公司，我认为它们是OpenGL的真正杀手。当然，当ARB应该拥有D3D时，它的一般能力不足使OpenGL易受攻击。但是3D Labs也许是我想到OpenGL当前市场状况的唯一最大原因。他们可能为此做了什么？
他们设计了OpenGL阴影语言。
看得出来，3D Labs是一家垂死的公司。NVIDIA对工作站市场的压力越来越大，他们昂贵的GPU被边缘化了。与NVIDIA不同，3D Labs在主流市场上没有任何业务。如果NVIDIA赢了，他们就死了。
他们做了。
因此，为了在不希望其产品的世界中保持相关性，3D Labs参加了游戏开发者大会，为他们称为“ OpenGL 2.0”的内容进行演示。这将是对OpenGL API的完整，从零开始的重写。这是有道理的；当时OpenGL的API中存在很多问题（请注意：该问题仍然存在）。只看纹理加载和绑定是如何工作的；它是半鹿茸。
他们提议的一部分是阴影语言。自然。但是，与当前的跨平台ARB扩展不同，它们的着色语言是“高级”的（C是着色语言的高级。是的，确实如此）。
现在，Microsoft正在开发自己的高级着色语言。在Microsoft的全部集体想象中，他们将其称为...高级着色语言（HLSL）。但是它们是对语言的根本不同的方法。
3D Labs着色器语言的最大问题是它是内置的。HLSL是Microsoft定义的一种语言。他们为此发布了一个编译器，并生成了Shader Model 2.0（或更高版本的shader模型）汇编代码，您可以将其输入D3D。在D3D v9时代，HLSL从未直接被D3D所触及。这是一个很好的抽象，但它纯粹是可选的。开发人员总是有机会落后于编译器并调整输出以实现最佳性能。
3D Labs语言没有这些。您为驱动程序提供了类似C的语言，并生成了一个着色器。故事结局。不是程序集着色器，不是您要提供的其他东西。表示着色器的实际OpenGL对象。
这意味着OpenGL用户对各种各样的开发人员持开放态度，这些开发人员刚刚掌握了汇编类语言的编译方法。编译器错误在新命名的OpenGL阴影语言（GLSL）中盛行。更糟糕的是，如果您设法使着色器正确地在多个平台上编译（绝非易事），那么您仍然会受到当天的优化器的影响。并不是最理想的。
虽然这是GLSL中最大的缺陷，但不是唯一的缺陷。通过远。
在D3D和OpenGL中的旧汇编语言中，可以混合并匹配顶点和片段（像素）着色器。只要它们与同一接口通信，就可以将任何顶点着色器与任何兼容的片段着色器一起使用。他们甚至可以接受不兼容的程度。顶点着色器可以写入片段着色器未读取的输出。依此类推。
GLSL没有任何东西。顶点着色器和片段着色器融合在一起，成为3D Labs称为“程序对象”的对象。因此，如果要共享顶点和片段程序，则必须构建多个程序对象。这引起了第二大问题。
看，3D Labs认为他们很聪明。他们基于GLSL的编译模型基于C / C ++。您采用.c或.cpp并将其编译为目标文件。然后，您获取一个或多个目标文件并将它们链接到程序中。这就是GLSL的编译方式：将着色器（顶点或片段）编译为着色器对象。然后，将这些着色器对象放在程序对象中，并将它们链接在一起以形成您的实际程序。
虽然这确实允许潜在的好主意，例如使“库”着色器包含主着色器可以调用的额外代码，但实际上意味着着色器被编译了两次。一次在编译阶段，一次在链接阶段。尤其是NVIDIA的编译器，因为它基本上运行两次。它没有产生某种目标代码中介。它只是编译一次并扔掉答案，然后在链接时再次编译它。
因此，即使要将顶点着色器链接到两个不同的片段着色器，也必须比D3D进行更多的编译。特别是因为类似C的语言的编译都是脱机完成的，而不是在程序执行开始时进行的。
GLSL还有其他问题。归咎于3D Labs似乎是错误的，因为ARB最终批准并合并了该语言（但“ OpenGL 2.0”计划没有其他要求）。但这是他们的想法。
这是真正令人难过的部分：3D Labs是对的（大部分情况下）。GLSL不是HLSL当时的基于矢量的着色语言。这是因为3D Labs的硬件是标量硬件（类似于现代NVIDIA硬件），但是它们最终正确地朝着许多硬件制造商使用其硬件的方向发展。
他们选择“高级”语言的在线编译模型是正确的。D3D甚至最终切换到了那个版本。
问题在于3D Labs在错误的时间正确。为了尽早召唤未来，为了适应未来，他们放弃了现在。这听起来与OpenGL始终具有T＆L功能的可能性类似。除了在硬件T＆L之前OpenGL的T＆L管道仍然有用，而GLSL在世界赶上它之前是一个责任。
GLSL 现在是一门好语言。但是时间呢？那太差了。OpenGL为此蒙受了痛苦。
走向神化
虽然我坚称3D实验室受到了致命的打击，但ARB本身却是棺材上的最后一颗钉子。
这是您可能听说过的故事。到OpenGL 2.1时，OpenGL遇到了问题。它有很多遗留问题。该API不再易于使用。有5种做事方式，但不知道哪一种是最快的。您可以通过简单的教程“学习” OpenGL，但实际上并没有真正学习能够提供真正性能和图形功能的OpenGL API。
因此，ARB决定尝试重新发明OpenGL。这类似于3D Labs的“ OpenGL 2.0”，但更好，因为ARB在它后面。他们称其为“龙峰”。
花一些时间改进API有什么不好？这很糟糕，因为微软让自己容易受到攻击。瞧，这是在Vista切换时。
借助Vista，Microsoft决定在显示驱动程序中进行一些急需的更改。他们迫使驱动程序向操作系统提交图形内存虚拟化和其他各种东西。
尽管人们可以争论这一点的优缺点或是否确实可行，但事实仍然如此：Microsoft认为D3D 10仅适用于Vista（及更高版本）。即使你有，这是硬件能够 D3D 10的，你不能没有也运行Vista上运行的D3D 10级的应用程序。
您可能还记得Vista ...嗯，让我们说它运行不佳。因此，您有一个性能不佳的OS，仅在该OS上运行的新API，以及需要该API和OS执行比上一代产品更快的速度的新一代硬件。
但是，开发人员可以通过OpenGL访问D3D 10级功能。好吧，如果ARB不在朗斯峰（Longs Peak）上忙，他们可以。
基本上，ARB花了一年半到两年的时间来改善API。到OpenGL 3.0真正问世时，Vista的采用率开始上升，Win7即将把Vista抛在后面，大多数游戏开发人员无论如何都不在乎D3D-10类功能。毕竟，D3D 10硬件可以很好地运行D3D 9应用程序。随着PC到控制台端口的增加（或PC开发人员跳入控制台开发。随您选择），开发人员不再需要D3D 10类功能。
现在，如果开发人员可以在WinXP机器上通过OpenGL早期访问这些功能，那么OpenGL开发可能已经需要了很多帮助。但是ARB错过了他们的机会。而且您想知道最糟糕的部分吗？
尽管花了两年宝贵的时间尝试从头开始重建API ...但是它们仍然失败，只是恢复到了现状（除弃用机制外）。
因此，ARB不仅错过了至关重要的机会之窗，甚至没有完成使他们错过机会的任务。几乎所有的史诗失败。
这就是OpenGL与Direct3D的故事。错失良机，愚蠢，任性盲目和愚蠢的故事。