GL_ARB_compatibility在核心概要中有效吗？

Question

我有一个使用OpenGL进行渲染的程序。在这样做时，它取决于有一个核心配置文件，但是即使没有可用的核心配置文件，如果只有在报告没有合适配置文件可用的错误时才能够查询驱动程序供应商和版本，我总是希望创建一个OpenGL上下文。因此，即使没有可用的核心配置文件，我也总是使用一些可用的概要文件来尝试初始化，并在初始化时检查配置文件是否符合我的先决条件，即OpenGL版本至少为3.0，并且GL_ARB_compatibility不存在。

但是，我从用户那里得到了错误报告，这些用户的驱动程序似乎违反了这些假设。下面是一个例子：

• GL_VENCOR：ATI Technologies Inc.
• GL_VERSION：4.2.11411 Core Profile Context
• GL_RENDERER：AMD Radeon HD 7610M
• GL_EXTENSIONS：. GL_ARB_compatibility .

可以看到，glGetString(GL_VERSION)说它是一个“核心配置文件上下文”，但是GL_EXTENSIONS包含GL_ARB_compatibility。

我该怎么解释呢？这是一个有效的配置吗?如果是的话，对于核心和兼容性配置文件之间的不同功能意味着什么？还是应该被认为是驱动程序的错误呢？是否有更好的方法来检查给定的OpenGL上下文是核心还是兼容性？

Answer 1

在创建上下文时，通过请求获得核心配置文件。如果您请求一个核心配置文件，则要么获得核心概要文件，要么创建上下文失败。

没有什么可解释的:如果您请求一个核心配置文件，并且创建了一个上下文，那么您就得到了一个核心概要文件。您不需要问一个概要文件是否是核心，因为您应该已经知道，因为您要求创建一个。

如果您要求一个核心配置文件，那么您不应该关心"GL_ARB_compatibility“是否可用；您甚至不应该查看它，也不应该基于它来查询函数。

但是，如果您真的想检查上下文是核心还是兼容性，可以调用glGetIntegerv(GL_CONTEXT_PROFILE_MASK。它将返回包含GL_CONTEXT_CORE_PROFILE_BIT或GL_CONTEXT_COMPATIBILITY_PROFILE_BIT的位掩码。

Answer 2

可以看到，glGetString(GL_VERSION说它是一个“核心配置文件上下文”，但是GL_EXTENSIONS包含GL_ARB_compatibility。我该怎么解释呢？

让我引述OpenGL 3.2岩心剖面规范的附录E.1 (重点是我)：

OpenGL 3.2是定义多个配置文件的OpenGL的第一个版本。通过添加H.1节中描述的特性，核心配置文件构建在OpenGL 3.1上。兼容性配置文件建立在将GL_ARB_compatibility 3.1与与OpenGL 3.1一起定义的特殊扩展结合起来的基础上，添加了相同的新特性，并在某些情况下扩展了它们的定义，以与仅在GL_ARB_compatibility中找到的OpenGL 3.1的现有功能交互。 不可能在单个GL上下文中同时实现核心配置文件和兼容性配置文件，因为核心配置文件要求兼容性配置文件中不存在功能限制。

因此，兼容性配置文件是以依赖GL_ARB_compatibility的方式明确定义的，我认为在核心配置文件中发布扩展的实现将违反规范的这一部分。