如何知道特定扩展是否被提升为核心配置文件，是从一开始就成为核心扩展还是作为遗留扩展被删除？答案

【问题标题】：How to know whether particular extension was promoted to a core profile, was made a core extension from the start or removed as a legacy extension?如何知道特定扩展是否被提升为核心配置文件，是从一开始就成为核心扩展还是作为遗留扩展被删除？
【发布时间】：2013-04-14 20:37:36
【问题描述】：

我正在使用 OpenGL 3.3 的核心前向兼容配置文件。支持的扩展列出了 GL_ARB_MULTITEXTURE 和类似的扩展（在 OpenGL wiki 的 OpenGL 3.1 中标记为已删除），但为什么我的驱动程序报告此扩展可用？此外，GL_NV_primitive restart 报告为可用，但它不能与服务器端 OpenGL 3+ 一起使用。那么驱动程序是否可以将任意扩展报告为受支持，即使它们不应该可用或不可用？

我的结论是，我不能依赖驱动程序提供有关扩展的正确信息。此外，标准规定驱动程序也没有义务报告核心扩展，但它可能。

现在，如果我有一个使用核心配置文件报告为 GL_foo_bar 的 GL 版本 a.b 的扩展，我如何知道它是否不是该特定设置的旧扩展，我如何知道该特定扩展是否已经是一部分a.b 核心。

此伪代码不可在不同的 OpenGL 之间移植：版本：if(GL_foo_bar == TRUE) 将在 OpenGL 2 中工作，如果 GL_foo_bar 是核心的一部分并且驱动程序未报告为可用，则可能无法在 OpenGL3+ 上工作。我找不到一个万无一失的方法来知道该特定扩展是否真的不受支持或根本没有报告，所以如果我不想在每个 GL 函数调用之间有多个 if，我似乎需要一个单独的渲染路径。

题外话：为什么 glGetString(Gl_EXTENSIONS) 可以与我的核心配置文件一起使用？我认为不应该。

【问题讨论】：

"core forward-compatible profile" 请停止这样做。只需使用核心配置文件。 Forward-compatibility is pointless with profiles. "为什么 glGetString(Gl_EXTENSIONS) 与我的核心配置文件一起工作？“因为你的驱动程序有问题。
@NicolBolas 使用前向兼容有什么问题？如果某天某些东西会再次被弃用，我想立即停止我的程序工作，这样我就可以修复我的代码以备不时之需。
因为不使用 OpenGL 支持的东西是没有意义的。自 GL 3.0 起，宽线已被弃用，但它们仍然是核心 OpenGL 配置文件的一部分，尽管被标记为已弃用。事实上，核心 OpenGL 中的弃用列表中有一些项目，其中大部分已被标记为弃用多年。然而他们还在那里。 ARB 显然不愿意触发摆脱它们（特别是考虑到迄今为止核心/兼容性区分的“成功”程度）。所以假装他们注定要消失是没有意义的。
另外，如果 OpenGL Wiki 说 ARB_multitexture 已从核心 OpenGL 中“删除”，那么请说明我可以从 Wiki 中删除的位置。
@NicolBolas 就我不关心 ARB 的内部政治而言，我想确保我只使用有效的东西，而不取决于他们会或不会决定做什么未来十年。即使现在也很难理解 GL 规范混乱，我不想很快寻找在哪个版本中不推荐使用的东西。 Wiki 链接：opengl.org/wiki/GL_ARB_multitexture 如果你修复了 wiki，那么很多功能都因为版本错误而成为核心，例如：opengl.org/wiki/GLAPI/glActiveTexture 它是自 1.3 以来的核心（GL_ARB_MULTITEXTURE）。

标签： opengl

【解决方案1】：

扩展没有“删除”。您的实现支持它想要的任何扩展，无论它是否对当前版本的 OpenGL 有意义。

我的结论是，我不能依赖驱动程序提供有关扩展的正确信息。此外，标准规定驱动程序也没有义务报告核心扩展，但它可能。

这个结论似乎是从错误的方向来解决问题的。版本和扩展在一个方面对您很重要：您想要支持什么？

如果您不打算使用 NV_primitive_restart，那么核心 OpenGL 实现是否在扩展字符串中提及它与您完全无关。您不应该关心扩展字符串是否提及 ARB_multitexture，除非您希望根据它是否存在来做不同的事情。

如果您支持 GL 2.1，那么您需要确定您希望支持哪些扩展，无论是有条件的还是根据需要的功能。然后根据这些扩展和版本号编写代码。

如果 GL_foo_bar 是核心的一部分

除非 GL_foo_bar 是 core OpenGL extension，否则它从不“核心的一部分”。扩展背后的功能可以提升为核心，但扩展和核心功能仍然不同。这就是它们有后缀的原因。

ARB_vertex_buffer_object 中的缓冲区对象功能在 1.5 中被提升为核心 OpenGL。但是 ARB_vertex_buffer_object 暴露的函数的行为与核心 OpenGL 暴露的类似函数的行为不同。 GL 3.1 允许这样做：glBindBuffer(GL_UNIFORM_BUFFER, buffer);。用glBindBufferARB 调用它可能工作（很可能，它可能会），但没有保证它会工作，无论 OpenGL 版本号或存在一些扩展组合。

这就是存在核心扩展的原因。这样您就可以调用相同的函数并获得相同的行为。如果存在扩展或 OpenGL 版本 >= 适当的数字，则可以使用相同的功能。所以一般的伪代码是这样的：if(gl::exts::ARB_uniform_buffer_object || gl::VersionGEQ(3, 1))。

【讨论】：

我创建了 OpenGL 扩展可用性列表：docs.google.com/spreadsheet/… 它允许人们检查特定扩展何时被提升，它们可能在哪些版本中可用，等等......我希望大部分信息是正确的。只需通过链接即可进行编辑。
@user206334：我认为说 ARB_geometry_shader4 以任何实际方式被“提升”是错误的。 GS 的核心 3.2 功能在形式上与扩展完全不同（即使它是相同的功能），它们之间实际上没有任何关系。
这样你就可以修复，删除。我只是收集了散落在附录中的所有信息。我也觉得很奇怪，但它被列为提升，所以我把它包括在内。让我找到确切的措辞：G.3.3.40 几何着色器“几何着色器的名称字符串是 GL_ARB_geometry_shader4。它在 OpenGL 3.2 中被提升为核心功能。”我根本没有资格质疑这个项目的有效性。
还有更多对 OpenGL API 没有影响的扩展（并且明确标记它们只影响 GLSL），但被列为提升到 GL 核心。我想这意味着与该核心一起使用的着色语言默认支持这些扩展。