应用错误收集

嗯，OpenGL上下文版本背后的逻辑可能有点令人困惑。但是在历史背景下看到它确实有意义：

在当天，没有特殊的＆＃34;上下文版本＆＃34;提示。只有一种方法可以创建上下文，并且您将获得运行它的特定实现支持的最高版本。您可以查询版本字符串和扩展字符串，并检查代码实际需要的所有功能是否都可用。获得比您真正需要的更高版本是一个永远不会有问题，因为每个新的GL版本都是100％向后兼容以前的版本。（嗯，理论上，至少）。它一直保持到OpenGL 2.1。

然而，使用OpenGL 3.0，＆＃34;弃用模型＆＃34;被介绍了。第一次，功能被标记为＆＃34;已弃用＆＃34;并计划实际删除。而且在OpenGL历史上第一次不再保证向后兼容性。随后，引入了新的上下文创建机制：ARB_create_context功能（请参阅wgl version或glX version的扩展规范），其中包括请求＆＃34;上下文的可能性版本＆＃34 ;.现在您遇到的情况是，对GL3和新上下文创建机制一无所知的旧应用程序仍应像以前一样运行。那么旧方法给出的是与GL 2.1兼容的东西（或者，如果你有一个非常古老或有限的实现，它会给你一些GL 1.x版本，当更现代时不支持GL 2.x功能。）

使用OpenGL 3.2，引入了上下文配置文件。这基本上是ARB最终提出的解决方案，以解决这些兼容性问题。从GL3.2开始，定义了两个配置文件： core 和 compatibility 。在核心配置文件中，已弃用的东西被删除，而在兼容性配置文件中，您可以获得一些东西，这些内容可以回溯到支持GL中的所有内容。
事情可能很简单，但它们并非如此。实现者只需要支持核心配置文件，兼容性配置文件是可选的。这导致了我们现在的情况：取决于平台的实现和，GL上下文的选项会有所不同：

所有主要的桌面平台（Windows，Unix / Linux，OSX）都支持＆＃34; legacy＆＃34; GL使用旧的上下文创建方法。

在Windows上，使用现代GPU和驱动程序，您仍然可以获得最高的兼容性配置文件，当您使用旧版上下文创建时，GPU将支持此配置文件请求特定版本/请求版本＆lt; GL3。因此，当你在那里要求1.0时，你可以得到4.4。
在OSX上，有一个急剧下降。 Legacy GL创建最多只能为您提供GL2.1。如果您需要现代GL，则必须要求提供3.2 核心配置文件。
在Linux上，它取决于您使用的GPU驱动程序。 AMD和NVidia的专有驱动程序的行为类似于Windows案例。但是，开源mesa3D实现（官方英特尔GPU驱动程序也使用它）确实像OSX那样处理它：只支持核心配置文件。

对于GL开发人员，有几点需要考虑：

您无法在同一应用程序中可靠地混合现代（GL＆gt; = 3）和已弃用的旧版功能，因为这不会在所有平台上都可用（并且规范不要求）。如果你想去＆＃34;现代＆＃34;路线，请求某些核心资料＆gt; = GL 3.2。
如果您想使用＆＃34; legacy＆＃34; GL，您应该限制自己使用GL2.1功能集。您仍然可能最终获得更高版本的一些兼容性配置文件，但您永远不能依赖它 - 至少，如果您没有针对特定平台。但由于GL规范根本不需要实现兼容性配置文件，因此我不建议这样做。这也意味着在实践中请求兼容性配置文件是没用的。

您可以信赖的内容：如果您申请了特定的GL版本（可能是个人资料）并且您实际上获得了一个上下文，它可能不是您要求的版本，但它将是一个支持每个功能的版本你要的版本。（但反过来的结论在一般情况下无效。）

在LWJGL中更改OpenGL版本

1 个答案: