OpenGL 3.0 和 3.1 已经弃用了很多我认为必不可少的功能。特别是在着色器中使用固定函数。
谁能解释这到底是怎么回事?
为什么他们发现有必要弃用如此有用的功能,显然每个人都在使用它并且没有理智的硬件公司会取消对它的支持?
OpenGL 3.0 和 3.1 已经弃用了很多我认为必不可少的功能。特别是在着色器中使用固定函数。
谁能解释这到底是怎么回事?
为什么他们发现有必要弃用如此有用的功能,显然每个人都在使用它并且没有理智的硬件公司会取消对它的支持?
正如您所说,没有硬件公司会取消对固定功能着色器的支持,因为有很多现有的应用程序使用它们。然而,他们不想做的是弄清楚如何指定 FF 着色器与他们添加的每个未来扩展之间的交互。这些交互非常复杂(部分原因是 FF 着色器非常复杂),这会导致供应商之间的错误和不一致的实现——这对开发人员和最终用户都是不利的。
所以他们画了一条线:如果你想使用 FF 着色器,你不会得到任何新功能。如果您想要新功能,则不能使用 FF 着色器。这与微软在 D3D10 中所做的非常相似:它添加了一大堆新功能,但同时完全删除了固定功能着色器。人们认为,需要新的非着色器功能但又不需要可编程着色器的开发人员数量非常少。
应该澄清的是,标记为“已弃用”的功能实际上并未被删除。例如,OpenGL 3.0 上下文具有所有功能 - 什么都没有。此外,一些供应商将发布可以使用兼容性配置文件创建 3.1 和 3.2 上下文的驱动程序,该配置文件也将启用已弃用的功能。因此,请仔细查看您将支持哪些供应商硬件,并询问旧功能的 ARB 兼容模式。(还有 3.2 的“核心”配置文件,如果他们希望制造这样的东西,它允许供应商创建一个更精简和平均的驱动程序)
请注意,任何当前的卡实际上都不再有 FF 硬件部分——它们只运行着色器。当您要求 FF 行为时,GL 运行时会代表您创作着色器。
为什么他们发现有必要弃用如此有用的功能,显然每个人都在使用它并且没有理智的硬件公司会取消对它的支持?
我想那苹果一定是疯了,因为 MacOSX 10.7 只支持 3.2 core。没有兼容性规范支持,没有 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 的所有杂物。
固定函数着色器很容易被标准 GLSL 着色器替换,因此很难理解为什么不应该在逻辑上弃用它们。
由于 OpenGL ES 2.0 不支持 FF 管道(因此不向后兼容 OpenGL ES 1.x),我比您不确定它们在可预见的将来不会从很多硬件中删除。在我看来,如今 OpenGL 的大部分动力来自于 OpenGL ES 在移动平台上的广泛采用,并且随着 FF 功能的消失,放弃使用它将会有相当大的压力。
事实上,我希望更精简的 OpenGL ES 实现将在未来几年内广泛取代标准 OpenGL,而 FF 功能可能会更多地消失,因为大多数硬件将实现 OpenGL ES,而不是因为它已从实现完整 OpenGL 的硬件中删除
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)。
我认为确保开发人员了解他们当前的编程方式也很重要。几十年来,人们一直被教导默认做事的“错误”方式,而顶点缓冲区对象被当作额外的东西来教导。