opengl - GL_ARB_compatibility 在核心配置文件中是否有效?
问题描述
我有一个使用 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 上下文是核心还是兼容性?
解决方案
您可以通过在创建上下文时询问它来获得核心配置文件。如果您要求提供核心配置文件,您将获得核心配置文件或上下文创建失败。
没有什么可以解释的:如果你要求一个核心配置文件,并且你创建了一个上下文,你就会得到一个核心配置文件。您不需要询问个人资料是否是核心,因为您应该已经知道,因为您要求制作一个。
如果您要求提供核心配置文件,那么您不应该关心“GL_ARB_compatibility”是否可用;你甚至不应该看它,你绝对不应该基于它查询函数。
但是如果你真的想检查一个上下文是核心还是兼容性,你可以调用glGetIntegerv(GL_CONTEXT_PROFILE_MASK
. 它将返回一个包含GL_CONTEXT_CORE_PROFILE_BIT
或的位掩码GL_CONTEXT_COMPATIBILITY_PROFILE_BIT
。
推荐阅读
- java - 如何更改图像位深?
- spring - 使用@value将bean值注入属性不起作用
- java - Java Stream lifecycle callbacks
- google-bigquery - BigQuery - WITH 语句 - 在后面的子查询中引用 WHERE 条件中的早期子查询
- python - PIP 升级会影响什么?
- android - 如何使用 SVG 创建动画
- string - 使用 pyspark 将字符串转换为日期
- java - Guice 配置错误没有绑定实现
- django - 如何从对 django 的前端响应中捕获错误和异常数据以添加更多上下文
- c# - 是否有向现有控制器添加/搭建单一方法的方法?