请求最新版本的 OpenGL 上下文
Request the most recent version of OpenGL context
我正在开发一个应用程序，它可以通过逐渐禁用某些功能和优化来使用从 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，系统可以为您提供向后兼容 X.Y 的任何受支持的 OpenGL 版本。也就是说，要求 X.Y 意味着“我已经针对 GL 版本 X.Y 编写了我的代码，所以不要给我一些会破坏我的代码的东西。”
但是，OpenGL 3.2+ 的核心配置文件不向后兼容 2.0。事实上，这就是 core/compatibility 区别的全部要点：兼容性配置文件提供对 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
- 请求任何高达 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 毫秒，而使用本机驱动程序创建整个上下文 + window 大约需要 300 毫秒，使用 Mesa 需要 70 毫秒。
我没有要测试的 macOS，所以我将使用保守的方法尝试向前兼容 4.1、3.3、3.2，然后是 2.1。无论如何，大多数 Mac 正好支持 4.1，因此对于他们来说，将在第一次尝试时创建上下文。
这是 the documentation for iOS OpenGL ES 推荐的做法：
To support multiple versions of OpenGL ES as rendering options in your app, you should first attempt to initialize a rendering context of the newest version you want to target. If the returned object is nil, initialize a context of an older version instead.
所以在 GLFW 伪代码中，我的 OpenGL 策略如下所示：
glfwWindowHint(GLFW_CLIENT_API, GLFW_OPENGL_API);
GLFWwindow* wnd;
#ifdef __APPLE__ // macOS
const std::array<char, 2> versions[] = {{4, 1}, {3, 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 和其他供应商的工作方式相同。
如果您可以测试我的假设以证实或否定它们，请在评论中告诉我。
我正在开发一个应用程序，它可以通过逐渐禁用某些功能和优化来使用从 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，系统可以为您提供向后兼容 X.Y 的任何受支持的 OpenGL 版本。也就是说，要求 X.Y 意味着“我已经针对 GL 版本 X.Y 编写了我的代码，所以不要给我一些会破坏我的代码的东西。”
但是，OpenGL 3.2+ 的核心配置文件不向后兼容 2.0。事实上，这就是 core/compatibility 区别的全部要点：兼容性配置文件提供对 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
- 请求任何高达 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 毫秒，而使用本机驱动程序创建整个上下文 + window 大约需要 300 毫秒，使用 Mesa 需要 70 毫秒。
我没有要测试的 macOS，所以我将使用保守的方法尝试向前兼容 4.1、3.3、3.2，然后是 2.1。无论如何，大多数 Mac 正好支持 4.1，因此对于他们来说，将在第一次尝试时创建上下文。
这是 the documentation for iOS OpenGL ES 推荐的做法：
To support multiple versions of OpenGL ES as rendering options in your app, you should first attempt to initialize a rendering context of the newest version you want to target. If the returned object is nil, initialize a context of an older version instead.
所以在 GLFW 伪代码中，我的 OpenGL 策略如下所示：
glfwWindowHint(GLFW_CLIENT_API, GLFW_OPENGL_API);
GLFWwindow* wnd;
#ifdef __APPLE__ // macOS
const std::array<char, 2> versions[] = {{4, 1}, {3, 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 和其他供应商的工作方式相同。
如果您可以测试我的假设以证实或否定它们，请在评论中告诉我。