5

标题几乎说明了一切。我昨天在浏览 Stack 时第一次听说了OpenGL Loader Generator项目,我检查了它以研究它比GLEW有什么优势。在项目网站上,他们声明:

这个加载器生成系统用于为您的特定需求创建 OpenGL 头文件和加载代码。与其将每个扩展和核心枚举器/函数都放在一个巨大的标题中,不如只得到你真正想要和要求的东西。

虽然我知道这种方法肯定比 GLEW 更简洁,但我不明白这种方法如何改进编译时间、应用程序性能或与 OpenGL 驱动程序的交互。此外,使用它的过程似乎需要更多维护,因为每次需要使用附加扩展时都必须重新生成扩展源。在使用 GLEW 时(与不使用相比)我从未注意到任何性能损失,所以我很好奇为什么这个项目的开发人员觉得他们有问题需要解决。我错过了什么吗?

4

2 回答 2

14

为了全面披露,我编写了 OpenGL Loader Generator。

虽然我知道这种方法肯定比 GLEW 更简洁,但我不明白这种方法如何改进编译时间、应用程序性能或与 OpenGL 驱动程序的交互。

它是一个 OpenGL 函数加载库。除了“Function CPP”风格内联转发函数之外,它只是调用函数指针。就像 GLEW 一样。

两者之间唯一可能的性能差异在于加载这些函数所需的时间(即:初始化例程)。由于这是一个初始化函数,它的一次性性能是无关紧要的,除非它非常慢。

简而言之,提高“应用程序性能或与 OpenGL 驱动程序的交互”不是该工具的目的。它存在干净的标头,其中包含您打算使用的 OpenGL 部分。此外,它还可以让您轻松使用 GLEW 或 GLee 风格的函数初始化,只要您认为合适。

至于“编译时间”性能,我想编译一个 100KB 的标头比一个 800KB 的标头便宜。但由于 GLEW 和我的工具都没有使用元编程或模板等高级 C++ 技术,因此任何编译时间节省的可能性都非常小。

此外,使用它的过程似乎需要更多维护,因为每次需要使用附加扩展时都必须重新生成扩展源。

这当然是使用该工具的一种方式。使用该工具的另一种方法是提前找出适合您的扩展,然后使用它们。

一般来说,当您编写真正的 OpenGL 应用程序时,您会针对特定的 OpenGL 版本编写该代码。此版本由您要支持的最低硬件决定。如果你想支持从过时的 Intel 945“GPU”到 AMD 和 NVIDIA 最新的高端产品的所有东西,你必须针对 GL 1.4(也许是 2.1,如果你感觉真的很勇敢并且愿意做很多事情的话)针对英特尔驱动程序进行测试)。如果您想支持更新的硬件,您可以针对 OpenGL 3.x 版本之一(3.1)编写代码,具体取决于您希望为英特尔 GPU 提供多少支持。

从那里,您可以决定您打算支持哪些更高版本的可选功能,或者仅支持特定于硬件的功能。您有一个您打算使用的东西的列表,因此您检查这些扩展并根据需要有条件地使用或不使用它。

这就是该工具的用途:当您确定了一组特定的扩展和 OpenGL 版本时。如果您想更加灵活,您可以只生成一个包含更多扩展的标头,即使您不使用它们。或者你可以使用 GLEW;我的工具是一个选项,而不是一个要求。

该工具并不意味着适合所有人。它适用于那些知道自己想要什么的人,他们想要拥有不包含他们永远不会使用的千字节 垃圾 扩展 的标题。

它也适用于自动完成等。有了一个干净的标题,你必须筛选出更少的垃圾,你根本不想跟注。哦,它有助于防止您意外使用您忘记检查的扩展程序中的某些内容。因为它不在您的标头中,所以任何调用此类函数或使用这些枚举的尝试都将导致编译器错误。

另一个好处是易于使用。看看这个网站上有多少关于 GLEW 和“未解决的外部”的问题。出现这种情况的部分原因是 GLEW 可以编译为静态或动态库。因此,您必须在代码中使用 a#define在它们之间切换(在 Windows 上)。那很糟。

使用生成器,您只需将标题和源代码粘贴到您的常规构建中。没有要构建或链接的库。只是几个额外的头文件和源文件。

这就是我编写该工具的原因。

于 2013-04-01T08:55:36.797 回答
1

我认为没有明显的性能提升,但是您只需使用 OpenGL 函数声明获得更小的头文件/源文件。

GLEW/GLEE 在库中具有所有版本组合 + 扩展 - 这使得它非常大。例如 GLEW 1.7 的头文件有 834kb。

OpenGL Loader为所需的 OpenGL 版本制作自定义文件。这些要小得多(例如(对于核心 opengl 4.2,大约 120kb 标头 + 130kb 源文件)。这将比GLEW 库编译得更快,当然它的输出代码更小。

于 2013-04-01T07:30:36.993 回答