VBO 或显示列表 - GPU 兼容性答案

【问题标题】：VBOs or Display Lists - GPU compatibilityVBO 或显示列表 - GPU 兼容性
【发布时间】：2011-05-03 23:42:18
【问题描述】：

我正在开发一个新的 OpenGL 应用程序，并且知道显示列表将在 OpenGL 3.1 中被弃用（以及许多其他有用的功能，这（对我来说）似乎有点傻）并被顶点缓冲区对象取代。我在 NVidia 卡上使用 VBO 成功绘制了一个三角形，但该示例无法在我上网本的英特尔芯片上运行，因为它不支持 glGenBuffers。 OpenGL 中似乎存在一个关键缺陷（新旧 GPU/GMA 之间的兼容性中断）。作为一家小型企业，我的游戏需要与尽可能多的系统兼容，但我不希望我的程序无法在较新的显卡上运行（因为它依赖于显示列表，这些显示列表已从 OpenGL 4.1 中删除）规格）。这将为我提供最广泛的显卡支持（旧的和新的）。显示列表，还是顶点缓冲对象？

【问题讨论】：

标签： c# opengl compatibility opentk

【解决方案1】：

如果您的应用程序将在 GMA 上运行，则您的多边形数量必然较低。因此，在新显卡的驱动程序中模拟显示列表的低效率将不是问题，它们有可用的带宽。

如果您仍然关心效率，请务必使用glVertexPointer/glDrawArray 来最大化批量大小。这可以与显示列表结合使用，但会减少列表中单独操作的数量，从而减少仿真问题。

最坏的情况，如果某些平台确实不支持显示列表，您可以将glCallList 替换为函数调用。

【讨论】：

它们是在驱动程序中模拟，完全从 GPU（包括驱动程序）中删除，还是必须使用“兼容性上下文”才能使其在 GPU 上工作？
@IDWMaster：当您请求兼容性上下文时，驱动程序支持（或旧版本的 OpenGL，如果您支持 GMA，您必须使用 1.5 左右）。是 100% 仿真还是部分硬件加速取决于芯片，但无论如何它应该跟上英特尔 GMA 可以处理的任何几何形状。
谢谢！不知道 glDrawArray 函数！这肯定会提高性能！我会在 3 分钟内接受答案。
@IDWMaster: glDrawArray（或glDrawElements）也是 VBO 的一部分。最初，您将系统内存指针传递给glVertexPointer，使用 VBO，您传入一个 GPU 内存指针。但是代码的整体结构是一样的。无论有没有 VBO，它都比glBegin/glEnd 提供了显着的性能优势。
@Ben：“如果你支持 GMA，你肯定用的是 1.5 左右”你不乐观吗！ :)

【解决方案2】：

您的英特尔卡确实支持 VBO，但只能通过 ARB 接口。尝试glGenBuffersARB（以及将所有其他 VBO 代码转换为使用 ARB 版本）。它适用于 nVidia 和 Intel GMA。

【讨论】：

ARB 接口与标准接口相比有什么缺点吗？为什么有两种不同的方式来绘制 VBO？
ARB 接口来自于添加新功能（架构审查委员会）的提案，并在最终确定之前代表接口。在给定的驱动程序（同时支持两者）中，通常 ARB 和常规接口的行为几乎相同（假设在提案被采纳时规范没有太大变化）。
@IDWMaster：大多数 OpenGL 功能从供应商扩展开始，然后成为 ARB 批准的扩展，最后被添加到核心规范的未来版本中。这可以防止核心规范因失败的功能而变得混乱。扩展没有向后兼容性要求，而核心接受的功能永远存在（至少在兼容性配置文件中）。
@IDWMaster：在这种特殊情况下，唯一实际的缺点是您必须检查 GL_EXTENSIONS 的扩展名（在加载函数指针之前），并且每个函数必须再输入 3 个字符，并且常量（不过，您可以甚至使用非 ARB 名称）。这是因为这个特定的扩展与核心功能 100% 相同，只是符号名称不同。其他所有内容，包括常量，都是相同的（对于每个扩展，不是正确）。

【解决方案3】：

或者，您可以查询系统支持的 OpenGL 版本并相应地使用 DisplayLists 或 VBO，而不是依赖一种方法来与每个 OpenGL 版本兼容。通过这种方式，您可以确定您使用的是最新、最有效和最快的绘图方式，无论系统支持什么方法（显示列表/VBO）。

此外，这样的实现可以轻松扩展以支持未来的绘图方法，例如 OpenGL 4.4 或 OpenGL 5.0。但是，这可能会导致多段代码在功能上执行相同的操作：告诉 GPU 做什么，这可能会增加代码大小和复杂性。

【讨论】：