使用较新版本而不是扩展时的性能提升？

Question

对于我的应用程序，我需要一个渲染器。渲染器使用 OpenGL 3.3 核心配置文件作为基础。在较新的 OpenGL 版本中，有一些简洁的功能，也可以通过扩展获得。如果可用，我想使用基于最新 OpenGL 版本的更新功能。由于测试可用版本和调整加载器是一团糟，我决定留在核心 3.3 并在可用的地方使用扩展（因为这是扩展，对吧？）。

在较新的 OpenGL 版本中，扩展是否与相同的功能一样快？

让我们使用GL_ARB_direct_state_access-extension。从 4.5 开始，它通过 Direct State Access 在核心中可用。后者比前者快吗？ IE。新版本中实现的功能是否比扩展更快？还是驱动程序链接到相同的功能？

E：这不是关于软件设计的问题，而是关于如何处理扩展（主要是？）以及关于性能的问题。

Answer 1

实际上，OpenGL API spec XML description 具有 alias 的好属性。一个 GL 函数别名另一个函数在语法和语义上基本上与它别名的函数相同 - 当扩展函数被提升为核心功能并更改其名称时，此功能会被大量使用。

有GL Loaders 实际使用该信息。我知道的两个例子是：

• libepoxy
• glad2（glad2 是glad loader 生成器当前正在开发的分支——但我使用它已经2 年了，没有任何问题）。您必须明确启用别名功能。还有一个web service 可以让您生成所需的文件（注意底部的“别名”按钮）。另请查看GLAD documentation。

使用这样的加载器，您不必关心特定功能是来自扩展还是来自 GL 核心功能，如果它们以某种方式可用，您就可以使用它们。

还请注意，对于较新的扩展，OpenGL ARB 更多时候是在函数和枚举名称上创建没有 ARB 后缀的 ARB 扩展，这意味着它在任何情况下都描述了完全相同的实体。这基本上是针对在这些功能被纳入核心标准之后创建的扩展完成的。他们只是为其创建一个扩展，以便可能无法满足新标准版本的某些其他要求的供应商仍然可以提供隔离功能。

第一个例子是 GL_ARB_sync 扩展，它本身与问题 #13 中的这一事实有关：

13) 为什么入口点/枚举没有附加ARB？

此功能直接进入 OpenGL 3.2 核心 并且也被定义为旧 > 平台的扩展 同时，因此它不使用 ARB 后缀，就像其他这样的 直接进入 GL 核心的新功能。

你写的：

让我们使用GL_ARB_direct_state_access-扩展名。从 4.5 开始，它通过 Direct State Access 在核心中可用。后者比前者快吗？ IE。新版本中实现的功能是否比扩展更快？还是驱动程序链接到相同的功能？

GL_ARB_direct_state_access 与GL_ARB_sync 属于同一类别。 GL 函数由名称标识，两个具有相同名称的实体意味着它们引用了 非常相同 的事物。 （你不能在一个库中导出两个同名的不同函数，*glGetProcAddress 也只接受名称字符串作为输入，所以如果有多个，它无法决定你想要哪个版本）。

但是，如何处理这种情况仍然取决于您的 GL 加载机制，因为它可能不会尝试加载您获得的 GL 版本未暗示的功能。例如，如果您选择它来生成 >= 4.5 加载器或支持 GL_ARB_direct_state_access 扩展，glad2 就可以工作。

由于测试可用版本和调整加载程序很麻烦，[...]

嗯。这在很大程度上取决于您使用的加载器。正如我所展示的，已经有一些选项基本上可以工作，不仅在绝对相同的函数名的情况下，而且在别名函数的情况下。

Answer 2

扩展是否与新 OpenGL 中的相同功能一样快 版本

扩展是某种功能的预览。当新版本到来时，标准中包含了许多（大多数？）扩展，因此性能将是相同的。

您应该查看您的目标平台。 当我运行 OpenGL Extensions Viewer 时，它告诉我的 HD3000 支持高达 3.1、70% 的 3.2 / 3.3 和 21% 的 4.0 的所有功能。 因此，您可以提前检查您需要的功能是否在您的目标平台上使用您要使用的硬件和驱动程序实现。最新的硬件将支持 4.4 / 4.5，因为它已经存在多年了。这取决于您对向后兼容性的重视程度。

当我查看自 Skylake 及更高版本支持 4.4 以来的英特尔显卡时，Skylake 是自 2015 年 8 月以来一直存在的。所有 AMD/NVidia 硬件也将支持 4.4 / 4.5。请注意，操作系统和驱动程序版本之间的支持级别可能非常不同。