请求最新版本的 OpenGL 上下文

如何解决请求最新版本的 OpenGL 上下文

我正在开发一个应用程序，它可以通过逐渐禁用某些功能和优化来使用从 4.6 到 2.0 的任何 OpenGL 版本。这意味着它可以使用 2.0，但更喜欢最新的支持版本，以便能够使用 OpenGL 3.x-4.x 的所有可用功能。此外，它处理核心上下文和兼容性上下文之间的所有差异，因此它应该适用于任何配置文件。

似乎在 Windows 上不会有问题，因为我可以省略版本和配置文件，并自动获取与最新支持版本的兼容性上下文。

但是在 macOS 和 Mesa 上的工作方式有所不同。在那里，我必须请求某个特定版本的核心向前兼容上下文，即使我不想要特定版本，但我想要最新的。

我该如何处理这个问题？在成功创建上下文之前，我是否必须循环尝试所有版本 4.6、4.5、4.4、4.3、4.2、4.1、4.0、3.3、3.2、3.1、3.0、2.1、2.0？或者有更好的解决方案吗？

如果没有更好的通用解决方案，我想知道它在不同平台上的不同驱动程序的实践中如何工作。

解决方法

如果您要求 OpenGL 版本 X.Y，系统可以为您提供任何支持的 OpenGL 版本，该版本向后兼容 X.Y。也就是说，要求 X.Y 的意思是“我的代码是针对 GL 版本 X.Y 编写的，所以不要给我一些会破坏我代码的东西。”

然而，OpenGL 3.2+ 的核心配置文件不向后兼容 2.0。事实上，这就是核心/兼容性区别的全部要点：兼容性配置文件提供对 API 更高功能的访问，同时向后兼容现有代码。核心配置文件没有。例如，2.0 缺少顶点数组对象，核心配置文件 OpenGL 没有它们就无法工作。

现在，每个配置文件的所有 OpenGL 版本都向后兼容该配置文件的所有低版本 API。因此 3.2 核心配置文件向后兼容 4.6 以及介于两者之间的所有内容。并且兼容性配置文件向后兼容所有以前版本的 OpenGL。

但是实现不需要来支持 OpenGL 的兼容性配置文件，只有核心配置文件。因此，如果您要求 OpenGL 2.0 版，那么实现将必须为您提供与 GL 2.0兼容的最高 OpenGL 版本。如果实现不支持兼容性配置文件，那么这将不是支持的 OpenGL 的最高核心配置文件版本。

如果您想同时支持 OpenGL 的核心版本和任何“兼容”版本，那么您必须为每个途径编写专门的代码。您的代码必须有 2.0 版本和 3.2 核心版本。由于您的代码有两个版本，因此您必须检查该上下文使用哪个版本。

这意味着您不需要某种方式来做您要求做的事情。尝试创建 3.2 核心配置文件版本，如果这不起作用，请创建 2.0 版本。

我做了一些快速测试。

在 Windows AMD Radeon (Ryzen 7) 上：

请求最高 2.1 的任何上下文版本会导致 4.6 兼容性上下文。这正是我想要的。
请求高于 2.1 的任何上下文版本会产生所请求版本的上下文。
我认为它在 Linux 专有驱动程序上的工作原理相同。
它在 Intel 和 NVidia 上的工作方式可能相同，但我现在无法对其进行测试。

在 Windows 20.3.2 的 Mesa 上

请求任何不超过 3.1 的上下文版本都会生成 3.1 上下文。
请求高于 3.1 的任何上下文版本都会生成 4.5 核心上下文。这正是我想要的。
我认为它在 Linux 开源驱动程序上的工作原理相同
请求 2.0-3.2 之间的任何 OpenGL ES 版本都会产生 3.2 上下文。这正是我想要的。

在 Android (Adreno 640) 上

请求 2.0-3.2 之间的任何 OpenGL ES 版本都会产生 3.2 上下文。
我认为它与 Android 上的其他供应商的工作方式相同。

似乎只有第一个上下文创建很慢。在这两种情况下，在我的系统上，额外尝试创建一个上下文会使应用程序的启动时间增加大约 4 毫秒，而使用本机驱动程序创建整个上下文 + 窗口大约需要 300 毫秒，或者使用 Mesa 需要 70 毫秒。

我没有要测试的 macOS，因此我将通过尝试向前兼容的 4.1、3.3、3.2 和 2.1 来使用保守的方法。无论如何，大多数 Mac 完全支持 4.1，因此对于它们，将在第一次尝试时创建上下文。

the documentation for iOS OpenGL ES 建议这样做：

要支持多个版本的 OpenGL ES 作为应用中的渲染选项，您应该首先尝试初始化要定位的最新版本的渲染上下文。如果返回的对象为 nil，则改为初始化旧版本的上下文。

所以在 GLFW 伪代码中，我的 OpenGL 策略如下所示：

glfwWindowHint(GLFW_CLIENT_API,GLFW_OPENGL_API);
GLFWwindow* wnd;
#ifdef __APPLE__ // macOS
const std::array<char,2> versions[] = {{4,1},{3,3},2},{2,1}};
glfwWindowHint(GLFW_OPENGL_FORWARD_COMPAT,true);
for(auto ver: versions)
{
    if(ver[0] < 3) glfwWindowHint(GLFW_OPENGL_FORWARD_COMPAT,false);
    glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR,ver[0]);
    glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR,ver[1]);
    wnd = glfwCreateWindow(...);
    if(wnd) break;
}
glfwMakeContextCurrent(wnd);
#else // Windows,Linux and other GLFW supported OSes
glfwWindowHint(GLFW_VISIBLE,false);
wnd = glfwCreateWindow(...);
glfwMakeContextCurrent(wnd);
std::string_view versionStr = glGetString(GL_VERSION);
if(versionStr[0] < '4' && versionStr.contains("Mesa"))
{
    glfwDestroyWindow(wnd);
    glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR,3);
    glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR,2);
    wnd = glfwCreateWindow(...);
    glfwMakeContextCurrent(wnd);
}
glfwShowWindow(wnd);
#endif

OpenGL ES 的代码看起来相似但更简单。移动平台将使用不同的库而不是 GLFW（GLFM/SDL 或原生 EGL）。对于 iOS，我必须先尝试 ES 3.0，然后再尝试 ES 2.0。对于 Mesa 和 Android，我只请求 2.0 上下文并获取最新的上下文 (3.2)。但是，对于 Android，我假设 Mali 和其他供应商的工作方式相同。

请在评论中告诉我您是否可以测试我的假设以确认或否定它们。