【问题标题】:Request the most recent version of OpenGL context请求最新版本的 OpenGL 上下文
【发布时间】:2021-02-07 20:09:22
【问题描述】:

我正在开发一个应用程序,它可以通过逐渐禁用某些功能和优化来使用从 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 sdl glfw glx wgl


    【解决方案1】:

    如果您要求 OpenGL 版本 X.Y,系统可以为您提供向后兼容 X.Y 的任何受支持的 OpenGL 版本。也就是说,要求 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 版本。

    【讨论】:

    • 我实际上有一个代码库,其中有很多分支检查每个功能的可用性。因此,如果该功能不可用,它会尝试通过扩展来获取它、模拟它或禁用它。例如,有一个围绕 VAO 的包装器,如果它不可用,它可以模拟它。无论如何,如果我请求 3.2 内核,它是否保证在每次实现时我都会获得最新的支持版本(最高 4.6 或 macOS 上的 4.1)?
    【解决方案2】:

    我做了一些快速测试。

    在 Windows AMD Radeon (Ryzen 7) 上:

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

    在适用于 Windows 20.3.2 的 Mesa 上

    1. 请求任何高达 3.1 的上下文版本都会导致 3.1 上下文。
    2. 请求任何高于 3.1 的上下文版本都会导致 4.5 核心上下文。这正是我想要的。
    3. 我认为它在 Linux 开源驱动程序上的工作方式相同
    4. 请求 2.0-3.2 之间的任何 OpenGL ES 版本都会导致 3.2 上下文。这正是我想要的。

    在 Android (Adreno 640) 上

    1. 请求 2.0-3.2 之间的任何 OpenGL ES 版本都会导致 3.2 上下文。
    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}, {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 和其他供应商的工作方式相同。

    如果您可以测试我的假设以确认或否认它们,请在 cmets 中告诉我。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2012-11-13
      • 2017-12-18
      • 2018-09-26
      • 2015-09-16
      • 1970-01-01
      • 2014-07-27
      相关资源
      最近更新 更多