OpenGL 3.0和3.1已弃用了我认为必不可少的一些功能。特别是在着色器中使用固定功能。
任何人都可以解释一下这是什么意思吗？
为什么他们发现需要弃用这种显而易见的每个人都使用的有用功能，并且没有理智的硬件公司会删除支持？
答案 0 :(得分：6)
正如您所说，没有硬件公司会删除对固定功能着色器的支持，因为现有的应用程序有很多使用它们。但是，他们不想做的是弄清楚如何指定FF着色器与它们添加的每个未来扩展之间的交互。这些交互非常复杂（部分原因是因为FF着色器非常复杂），这导致了供应商之间的错误和不一致的实现 - 这两者对开发人员和最终用户都是不利的。
所以他们画了一条线：如果你想使用FF着色器，你就不会获得任何新功能。如果需要新功能，则无法使用FF着色器。这与微软在D3D10中的表现非常相似：它增加了一大堆新功能，但同时完全删除了固定功能着色器。我们相信，那些需要新的非着色器功能但不需要可编程着色器的开发人员非常小。
答案 1 :(得分：2)
应该澄清的是，实际上并未删除标记为“已弃用”的功能。例如，OpenGL 3.0上下文具有所有功能 - 没有任何消失。此外，一些供应商将发布可以使用兼容性配置文件创建3.1和3.2上下文的驱动程序，这也将启用已弃用的功能。因此，请仔细查看您要支持的供应商硬件，并询问有关旧功能的ARB兼容模式。 （从3.2开始，还有“核心”配置文件，如果他们希望制作这样的东西，它可以让供应商创建一个更精益和更卑鄙的驱动程序）
请注意，任何当前的卡都不再具有FF硬件部分 - 它们只运行着色器。当您要求FF行为时，GL运行时代表您创作着色器..
答案 2 :(得分：2)
为什么他们发现需要弃用这种显而易见的每个人都使用的有用功能，并且没有理智的硬件公司会删除支持？
我认为Apple必须疯狂，因为MacOSX 10.7仅支持3.2 核心。没有兼容性规范支持，没有ARB_compatibility扩展，什么都没有。您可以创建2.1上下文或3.2核心上下文。
但是，如果你想要理由：
为了完整起见：Jesse Hall所说的话。 ARB不再需要考虑固定功能和新功能之间的相互作用。整数数学，数组纹理和各种其他功能被定义为不能与固定功能管道一起使用。自GL 3.0问世以来，OpenGL在过去3年里得到了很大改善。 ARB的变化步伐相当可观。如果他们必须找到一种方法使所有这些功能与固定功能交互，那么这是否可能？如果他们没有固定的功能交互，那么您是否会抱怨如何从旧代码中访问新功能？这很好地导致了：
它充分表明应该使用什么。即使兼容性上下文始终可用，您也可以查看核心OpenGL以了解应该如何解决问题。
它使最终的桌面GL和GL ES统一更加合理。 ES 2.0抛弃了所有旧的东西，并采用了你可能认为的核心GL 2.1。最终目标是只拥有一个OpenGL。要做到这一点，你必须能够摆脱桌面GL的所有困境。
答案 3 :(得分：1)
固定功能着色器很容易被标准GLSL着色器取代，因此很难理解为什么逻辑上不应该弃用它们。
我不太确定在可预见的将来他们不会从多硬件中丢弃，因为OpenGL ES 2.0不支持FF管道（因此不能向后兼容OpenGL ES 1.x） 。在我看来，目前OpenGL的大部分动力来自于OpenGL ES在移动平台上的广泛采用，并且FF功能从那里消失，将会有一些相当大的压力要求摆脱它的使用。
事实上，我希望更精简的OpenGL ES实现在未来几年内相当广泛地取代标准OpenGL，并且FF功能可能会消失得更多，因为大多数硬件将实现OpenGL ES而不是因为它从实现完整OpenGL的硬件中删除< / p>
答案 4 :(得分：0)
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。）
我认为确保开发人员了解他们应该编程的当前方式也很重要。几十年来，人们已经被教导了默认的“错误”做事方式，顶点缓冲对象已经被教导为额外的。