OpenGL:What'；反对是怎么回事？

OpenGL 3.0和3.1已经弃用了很多我认为必不可少的功能。特别是在着色器中使用固定函数

谁能解释一下这到底是怎么回事

---

为什么他们觉得有必要不推荐如此有用的功能，这显然是每个人都在使用的，而且没有一家健全的硬件公司会取消对它的支持？

正如你所说，没有一家硬件公司会取消对固定函数着色器的支持，因为有这么多现有的应用程序在使用它们。但是，他们不想做的是找出如何指定FF着色器和它们添加的每个未来扩展之间的交互。这些交互非常复杂（部分原因是FF着色器非常复杂），这会导致供应商之间的错误和不一致的实现——这对开发人员和最终用户都是不利的

---

所以他们在画一条线：如果你想使用FF着色器，你就得不到任何新功能。如果需要新功能，则不能使用FF着色器。这与微软在D3D10中所做的非常相似：它添加了大量新功能，但同时完全删除了固定的函数着色器。我们相信，需要新的非着色器功能但不需要可编程着色器的开发人员数量非常少。

固定函数着色器很容易被标准GLSL着色器取代，因此很难理解为什么逻辑上不应该弃用它们

我比你更不确定的是，在可预见的未来，它们不会从很多硬件中消失，因为OpenGL ES 2.0不支持FF管道（因此与OpenGL ES 1.x不向后兼容）。在我看来，OpenGL最近的发展势头很大程度上来自于OpenGL ES在移动平台上的广泛应用，随着FF功能的消失，将有相当大的压力迫使人们不再使用它

---

事实上，我预计更精简的OpenGL ES实现将在未来几年内相当广泛地取代标准OpenGL，FF功能可能会消失得更多，因为大多数硬件将实现OpenGL ES，而不是因为它从实现完整OpenGL的硬件中移除。应该澄清的是“不赞成“实际上并没有被删除。例如，OpenGL 3.0上下文具有所有功能—没有任何功能消失。此外，一些供应商将提供可以使用兼容配置文件创建3.1和3.2上下文的驱动程序，该配置文件还将启用不推荐的功能。因此，请仔细查看您将支持的供应商硬件，并询问旧功能的ARB兼容模式。（从3.2开始，还有“核心”配置文件，允许供应商创建一个更精简、更吝啬的驱动程序，如果他们希望这样做的话）

---

请注意，任何当前卡实际上都不再具有FF硬件部分-它们只运行着色器。当您请求FF行为时，GL运行时将代表您编写着色器

为什么他们认为有必要贬低如此有用的特性，因为它显然是每个人都在使用的，而且没有一家理智的硬件公司会取消对它的支持

我想苹果一定是疯了，因为MacOSX 10.7只支持3.2内核。没有兼容性规范支持，没有ARB_兼容性扩展，什么都没有。您可以创建2.1上下文或3.2核心上下文

但是，如果您想了解原因：

为了完整起见：杰西·霍尔说了些什么。ARB不再需要考虑固定函数和新特征之间的相互作用。整数数学、数组纹理和各种其他功能被定义为不可用于固定函数管道。自从GL3.0问世以来，OpenGL在过去三年中取得了长足的进步；ARB的变化速度相当快。如果他们必须找到一种方法，使所有这些功能与固定功能交互，这可能吗？如果它们没有固定的函数交互，您会不会抱怨无法从旧代码访问新功能？这很好地引出：

它有力地表明了应该使用什么。即使兼容性上下文始终可用，您也可以查看核心OpenGL以了解如何解决问题

这使得最终的桌面GL和GL ES的统一更加合理。ES 2.0抛弃了所有旧东西，只是采用了您可能认为是核心GL 2.1的东西。最终目标将是只有一个OpenGL。要做到这一点，你必须能够摆脱桌面GL的所有积垢

---

OpenGL支持“核心”配置文件和“兼容”配置文件。因此，对于大多数系统，您不会失去对不推荐或删除的函数的任何访问权限

但如果你想确保兼容，最好还是坚持核心内容。您不能保证有一个兼容性配置文件（即使大多数硬件都有一个，并且在当前状态下，您很可能会遇到一个过时的OpenGL，而不是一个只有核心的配置文件）。此外，OpenGL ES现在是OpenGL的一个子集，可以编写OpenGL ES 2.x/3.x程序，并在OpenGL 4.3中运行，几乎没有任何更改

像PlayStations和Nintendo这样的游戏机自带了自己的图形库，而不是使用OpenGL

它们是基于OpenGL的，但在这里被简化为类似于ES（我不认为当时ES 2.0已经过时）。这些系统需要编写自己的图形驱动程序和库，要求硬件供应商编写基本上是一整套遗留包装库有点过分（所有固定函数的东西最终都会在某个阶段在着色器中实现，而且glBegin/glEnd很可能会自动变成VBO）

我认为，确保开发人员能够独立工作也很重要