OpenGL：弃用是怎么回事？
OpenGL 3.0 和 3.1 已经弃用了相当多我认为必不可少的功能。 特别是着色器中固定函数的使用。
谁能解释一下这到底是怎么回事？
为什么他们发现有必要弃用如此有用的功能，显然每个人都在使用，而且没有理智的硬件公司会取消对它的支持？
OpenGL 3.0 and 3.1 have deprecated quite a few features I find essential. In particular, the use of fixed function in shaders.
Can anyone explain what's really the deal with that?
Why do they find the need to deprecate such useful feature that its obvious everybody uses and that no sane hardware company is going to remove support for?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
正如您所说，没有硬件公司会取消对固定功能着色器的支持，因为有很多现有的应用程序使用它们。 然而，他们不想做的是弄清楚如何指定 FF 着色器与他们添加的每个未来扩展之间的交互。 这些交互非常复杂（部分原因是 FF 着色器非常复杂），这会导致供应商之间出现错误和不一致的实现，这对开发人员和最终用户来说都是不利的。
所以他们划清了界限：如果您想使用 FF 着色器，您将无法获得任何新功能。 如果您想要新功能，则不能使用 FF 着色器。 这与微软在 D3D10 中所做的非常相似：它添加了一大堆新功能，但同时完全删除了固定功能着色器。 人们相信，需要新的非着色器功能但也不需要可编程着色器的开发人员非常少。
As you said, no hardware company will remove support for fixed-function shaders, because there are so many existing applications that use them. What they don't want to do, though, is figure out how to specify the interactions between FF shaders and every future extension they add. Those interactions are very complicated (partly because FF shaders are so complicated), which leads to bugs and inconsistent implementations between vendors -- both of which are bad for developers and end users.
So they're drawing a line: if you want to use FF shaders, you don't get any of the new functionality. If you want new functionality, you can't use FF shaders. This is very similar to what Microsoft did in D3D10: it added a whole bunch of new functionality, but at the same time completely removed fixed-function shaders. The belief is that the set of developers who need the new non-shader functionality but who don't also need programmable shaders is very small.
应该澄清的是，标记为“已弃用”的功能实际上并未被删除。 例如，OpenGL 3.0 上下文具有所有功能 - 没有任何功能消失。 此外，一些供应商将发布可以使用兼容性配置文件创建 3.1 和 3.2 上下文的驱动程序，这也将启用已弃用的功能。 因此，请仔细查看您将支持哪些供应商硬件，并询问旧功能的 ARB 兼容性模式。 （从 3.2 开始还有“核心”配置文件，如果供应商希望制作这样的东西，它允许供应商创建更精简和平均的驱动程序）
请注意，任何当前的卡实际上都不再具有 FF 硬件部分 -他们只运行着色器。 当您请求 FF 行为时，GL 运行时会代表您编写着色器。
It should be clarified that a feature that is marked "deprecated" is not actually removed. For example, an OpenGL 3.0 context has all of the features - nothing is gone. Further, some vendors will ship drivers that can create 3.1 and 3.2 contexts using a compatibility profile which will also enable the deprecated features. So, look closely at what vendor hardware you are going to support and ask about the ARB compatibility mode for old features. (There is also the "core" profile as of 3.2, which allows vendors to create a more lean and mean driver if they wish to make such a thing)
Note that any current card really doesn't have an FF hardware section any more - they only run shaders. When you ask for FF behavior, the GL runtime is authoring shaders on your behalf..
我想Apple一定是疯了，因为MacOSX 10.7只支持3.2个核心。 没有兼容性规范支持，没有 ARB_compatibility 扩展，什么都没有。 您可以创建 2.1 上下文或 3.2 核心上下文。
但是，如果您想要理由：
为了完整起见：杰西·霍尔所说的。 ARB不再需要考虑固定功能和新功能之间的交互。 整数数学、数组纹理和各种其他功能被定义为不能与固定函数管道一起使用。 自从 GL 3.0 发布以来，OpenGL 在过去 3 年里确实得到了很大的改进； ARB 的变革步伐相当大。 如果他们必须找到一种方法使所有这些功能与固定功能交互，这可能吗？ 如果它们没有固定的功能交互，您是否会抱怨如何无法从旧代码中访问新功能？ 这很好地引出了：
它强烈地表明了人们应该使用什么。 即使兼容性上下文始终可用，您也可以查看核心 OpenGL 来了解应该如何解决问题。
这使得最终的桌面 GL 和 GL ES 统一更加合理。 ES 2.0 抛弃了所有旧的东西，只是采用了您可能认为的核心 GL 2.1 的内容。 最终目标是只有一个 OpenGL。 为此，您必须能够消除桌面 GL 的所有缺陷。
I suppose then Apple must be insane, because MacOSX 10.7 supports only 3.2 core. No compatibility specification support, no ARB_compatibility extension, nothing. You can either create a 2.1 context or a 3.2 core context.
However, if you want reasons:
For the sake of completeness: what Jesse Hall said. The ARB no longer has to consider the interaction between fixed function and new features. Integer math, array textures, and various other features are defined to not be usable with the fixed function pipeline. OpenGL has really improved over the last 3 years since GL 3.0 came out; the pace of the ARB's changes is quite substantial. Would that have been possible if they had to find a way to make all of those features interact with fixed function? And if they didn't have fixed function interactions, would you not then be complaining how you can't access new features from your old code? Which leads nicely into:
It serves as a strong indication of what one ought to be using. Even if the compatibility context is always available, you can look at core OpenGL to see how one ought to be approaching problem solving.
It makes the eventual desktop GL and GL ES unification much more reasonable. ES 2.0 threw out all of the old stuff and just adopted what you might think of as core GL 2.1. The ultimate goal will be to only have one OpenGL. To do that, you have to be able to rid the desktop GL of all of the cruft.
固定功能着色器很容易被标准 GLSL 着色器替换，因此很难理解为什么从逻辑上讲它们不应该被弃用。
我比你更不确定它们在可预见的将来不会从很多硬件中删除，因为 OpenGL ES 2.0 不支持 FF 管道（因此不向后兼容 OpenGL ES 1.x）。 在我看来，如今 OpenGL 的大部分动力来自于 OpenGL ES 在移动平台上的广泛采用，随着 FF 功能的消失，人们将面临相当大的压力，放弃使用它。
事实上，我预计更精简的 OpenGL ES 实现将在未来几年内广泛取代标准 OpenGL，并且 FF 功能可能会消失更多，因为大多数硬件将实现 OpenGL ES，而不是因为它从实现完整 OpenGL 的硬件中删除
Fixed function shaders are quite easily replaced with standard GLSL shaders so it's difficult to see why logically they shouldn't be deprecated.
I'm less certain than you that they won't be dropped from much hardware in the foreseeable future as OpenGL ES 2.0 doesn't support the FF pipeline (and so isn't backward compatible with OpenGL ES 1.x). It seems to me that much of the momentum with OpenGL these days is coming from the widespread adoption of OpenGL ES on mobile platforms and with FF functionality gone from there there will be some considerable pressure to move away from it's use.
Indeed I'd expect the leaner OpenGL ES implementation to replace standard OpenGL quite widely over the next few years, and FF functionality may disappear more because most hardware will implement OpenGL ES rather than because it's removed from hardware implementing the full OpenGL
OpenGL 允许“核心”配置文件和“兼容”配置文件。 因此，对于大多数系统，您不会失去对已弃用或已删除功能的任何访问权限。
但如果你想确保兼容性，最好坚持核心内容。 无法保证您具有兼容性配置文件（即使大多数硬件都有一个兼容性配置文件，并且在当前状态下，您更有可能遇到过时的 OpenGL，而不是仅核心的配置文件）。 此外，OpenGL ES 现在是 OpenGL 的子集，可以编写 OpenGL ES 2.x/3.x 程序并使其在 OpenGL 4.3 中运行，几乎无需任何更改。
PlayStation 和 Nintendo 等游戏机附带了自己的图形库，而不是使用 OpenGL。
它们基于 OpenGL，但这里以类似于 ES 的方式进行了剥离（我认为当时 ES 2.0 还没有出来）。 这些系统需要编写自己的图形驱动程序和库，要求硬件供应商编写基本上是遗留包装库的全部负载有点多（所有固定功能的东西最终都会在某个阶段在着色器中实现，并且无论如何，glBegin/glEnd 很可能会自动变成 VBO）。
我认为确保开发人员了解他们当前的编程方式也很重要。 几十年来，人们一直被教导以“错误”的默认方式做事，而顶点缓冲对象则被作为额外的教导。
OpenGL allows for both a 'core' profile and a 'compatibly' profile. So for most systems you wont loose any kind of access to deprecated or removed functions.
But if you want to ensure compatibly it is best to stick to the core stuff. You won't be guaranteed a compatibility profile (even if most hardware has one and at the current state it's more likely you will encounter an out of date OpenGL rather than a core only one). Also OpenGL ES is now a subset of OpenGL, it is possible to write a OpenGL ES 2.x/3.x program and have it run in OpenGL 4.3 with almost no changes.
Game console like the PlayStations and the Nintendo ones shipped with their own graphics libraries rather than using OpenGL.
They were based on OpenGL but here stripped down in a similar was to ES (I don't think ES 2.0 was out then). Those systems need to write their own graphics drivers and libraries, asking a hardware vendor to write what is basically a whole load of legacy wrapping libraries is a bit much (all the fixed function stuff would just end up being implemented in shaders at some stage and it's likely that glBegin/glEnd would just be getting turned into a VBO automatically anyway).
I think it has also been important to ensure that developers are made aware of the current way they should be programming. For decades people have been taught the 'wrong' way to do things by default and vertex buffer objects have been taught as an extra.