GPU DirectX VS OpenGL 支持答案

【问题标题】：GPU DirectX VS OpenGL supportGPU DirectX VS OpenGL 支持
【发布时间】：2013-11-06 13:02:07
【问题描述】：

据我了解，GPU 供应商定义了供操作系统开发人员与特定驱动程序通信的标准接口。所以 DirectX 和 OpenGL 只是该接口的包装器。当操作系统开发人员决定创建新版本的图形 API 时，GPU 供应商会扩展他们的接口（新例程更快，而旧例程则因兼容性问题而留下），操作系统开发人员使用接口的这一新部分。
那么，当说 GPU 厂商对 DirectX 的支持优于对 OpenGL 的支持时，是否仅仅意味着 GPU 厂商主要考虑了微软未来开发 DirectX API 结构的计划，并根据自己的需要调整该接口的未来开发？还是在此之前有一些技术原因？

【问题讨论】：

标签： opengl directx gpu

【解决方案1】：

图形硬件抽象与 OpenGL 和 Direct3D 等图形 API 之间没有 1:1 的对应关系。 WDDM 是 Windows Vista 的驱动程序模型，它定义了常见的调度、内存管理等内容，以便 DirectX 和 OpenGL 应用程序可以互操作地工作，但一般来说，DirectX、OpenGL 或 GPU 的设计很少与此有关。把它想象成内核，没有人专门创建一个 CPU 来运行它，而且你不必每次出现一个新的处理器架构迭代，添加一个新的指令子集时重新编译内核。

应用程序开发人员和 IHV（您称其为 GPU 供应商）主要负责处理 GPU 架构的更改。看起来操作系统与方程式的关系比实际更多，因为微软（更多）和苹果——他们都拥有自己的专有操作系统——在 DirectX 和 OpenGL 的设计中具有影响力。如今，OpenGL 紧跟商用桌面 GPU 硬件的发展，但情况并非总是如此——它包含定制 SGI 工作站时代的包袱，并且兼容性配置文件中的许多内容在几十年来并非桌面 GPU 上的硬件原生。另一方面，DirectX一直追随桌面硬件。过去，如果您想了解桌面 GPU 的发展方向，D3D 是一个很好的标记。

OpenGL 可以说比 DirectX 更复杂，因为直到最近它从未放弃任何东西，而 DirectX 从根本上重新定义了 API 并在每次迭代中剥离了遗留支持。近年来，这两种 API 都已稳定下来，但 D3D 仍然保持着一定的优势，因为它只需要在单个平台上实现，而且微软编写了唯一的着色器编译器。如果有的话，D3D 中的着色器编译器和最小功能集（没有遗留包袱）可能就是为什么您会觉得供应商更好地支持它的原因。

随着 AMD Mantle 的出现，桌面画面可能会再次发生变化（回想一下 3Dfx 和 Glide 的时代）......这无疑表明操作系统开发人员与图形 API 设计几乎没有任何关系。 NV 和 AMD 在 PS3、GameCube/Wii/WiiU 和 PS4 上都有专有的 API，除了桌面上的 D3D 和 OpenGL 之外，它们还必须实现这些 API，因此总体情况比您想象的要广泛得多。

【讨论】：

【解决方案2】：

据我了解，GPU 供应商定义了供操作系统开发人员使用的标准接口，以与他们的特定驱动程序进行通信。所以 DirectX 和 OpenGL 只是该接口的包装器。

不，不是真的。 DirectX 和 OpenGL 只是定义 API 的规范。但是规范只不过是一个文档，而不是软件。 OpenGL API 规范由Khronos 控制，DirectX API 规范由微软控制。然后每个操作系统定义一个所谓的 ABI（应用程序二进制接口），它指定操作系统支持哪些系统级 API（OpenGL 和 DirectX 是系统级 API）以及实际实现在操作系统上运行时必须遵守的规则问题。

实际的 OpenGL 或 Direct3D 实现发生在硬件的驱动程序中（实际上硬件本身也是实现的一部分）。

当操作系统开发人员决定创建新版本的图形 API 时，GPU 供应商会扩展他们的接口

事实上恰恰相反：大多数图形 API 规范都是由图形硬件供应商制定的。毕竟他们离橡胶撞路的地方很近。对于 Khronos，GPU 制造商是 Khronos 控制组的一部分。在 DirectX 的情况下，硬件制造商向 Microsoft 提交草稿并审查 Microsoft 所做的更改和建议。但最终，每个新的 API 版本都反映了正在开发的下一代硬件功能的共同点。

那么，当说 GPU 厂商对 DirectX 的支持优于对 OpenGL 的支持时，是否仅仅意味着 GPU 厂商主要考虑了微软未来开发 DirectX API 结构的计划，并根据自己的需要吗？

不，这意味着每个 GPU 供应商都实现了自己的 OpenGL 版本和 Direct3D 后端，这就是所有神奇之处。然而，OpenGL 非常强调向后兼容性和易于过渡到新功能。 Direct3D 开发 OTOH 可以快速切断与早期版本的联系。这也意味着完整的兼容性配置文件 OpenGL 实现是相当复杂的野兽。这也是为什么最近版本的 OpenGL 核心配置文件确实（过期）减少了对遗留功能的支持的原因；这种 API 复杂性的降低对于开发人员来说也是一件相当解放的事情。如果您纯粹为核心配置文件进行开发，它会简化很多事情；例如，您在编写插件时不再需要担心过多的内部状态。

另一个因素是，对于 Direct3D，只有一个着色器编译器，它不是驱动程序基础结构/实现本身的一部分，而是在程序构建时运行。然而，OpenGL 实现必须实现自己的 GLSL 着色器编译器，这使事情变得复杂。恕我直言，缺乏统一的 AST 或直接着色器代码是 OpenGL 的主要缺点之一。

【讨论】：

@tamato：特别注意。这是一个抽象概念，某种标准化的即时代码，即带注释的语法树（AST）。例如，LLVM 编译器基础结构首先编译为 LLVM 立即代码，然后再转换为机器代码。事实上，用于 Radeon GPU 的 Mesa GLSL 编译器使用 LLVM，带有 Radeon LLVM 机器代码生成器后端。
@datenwolf 一般说得好，但我不同意你的最后一点。我不认为这是市场本身的兼容性倾向。 OpenGL 性能在今天不会移动桌面上的单位。在进行 OEM 交易时，他们将关注战地和 COD 的性能数据，而不是 Minecraft。从而激励优化 Direct3D。
@MooseBoys：有趣的是，你应该调出《战地》（无论如何都是 4），因为它使用 AMD Mantle。如果有的话，你会看到 AMD 将大部分精力放在优化 Mantle 版本的游戏上，它基本上是他们目前新 API 的典型代表。这证明了 datenwolf 的观点，然而，Mantle 目前是一个单一的实现系统——没有确保软件在多个实现中可移植地运行的负担，有很大的优化空间和不太严格的测试要求。
@datenwolf 那么是不是 Windows 的封闭源应用程序二进制接口阻止了某人在 Linux 上实现 DirectX？事实上，如果 DirectX 只是一个规范 - 是什么阻止了人们实施它们？
@iamcreasy：不，这不是问题。毕竟 DirectX 的 ABI 是众所周知的。不，问题是，到目前为止，除了 Wine 项目之外，没有人真正关心获得 DirectX。毕竟 DirectX 很大程度上基于 COM，而 COM 又依赖于 DLL 如何在 Windows 上工作以及 C++ 编译器如何实现纯抽象类的 vtable 的特定细节。实际上，Mesa 正在开发一个 DirectX 状态跟踪器。