共享内存架构中的 OpenGL (ES 2.0) VBO 性能答案

【问题标题】：OpenGL (ES 2.0) VBO Performances in a Shared Memory Architecture共享内存架构中的 OpenGL (ES 2.0) VBO 性能
【发布时间】：2012-10-15 03:32:13
【问题描述】：

我是一名桌面 GL 开发人员，我开始探索移动世界。

为避免误解或欢迎但不重要的回复，我可以谦虚地说我非常了解 GL 和 GL|ES 机制。

简短的问题是：如果我们在共享内存架构中使用 GL|ES 2.0，那么对客户端数组使用 VBO 的意义何在？

更详细：

顶点缓冲区是原始内存块，驱动程序无法以任何方式优化任何内容，因为访问模式取决于：1) 应用程序如何配置顶点数据布局，2)顶点着色器消耗缓冲区内容，并且 3) 我们可以有许多顶点着色器以不同的方式运行，并以不同的方式获取相同的缓冲区。
对齐：单个 VBO 存储可以从最适合底层 GL 系统的地址开始；如果我只是强制（例如，尊重对齐最佳实践）将客户端数组分配到这些边界会怎样？
基于图块的渲染与即时模式架构不应发挥作用：据我了解，这与我的问题（即内存访问）无关。

我知道使用 VBO 可以让您的代码在未来平台/硬件中运行得更好/更快，而无需对其进行修改，但这不是本问题的重点。

此外，我还意识到在共享内存架构中使用 VBO 会使内存使用量翻倍（如果您出于某种原因必须保留顶点数据供您使用），并且会花费您数据的 memcpy。

与交错的顶点数组一样，VBO 的使用在开发者的论坛/博客/official_technotes 中得到了很大的“炒作”，但没有任何数据支持这些声明（即基准）。

【问题讨论】：

【解决方案1】：

我可以报告说，使用 VBO 在 Android 设备上存储顶点数据给我带来了零性能提升。在 Adreno、Mali400 和 PowerVR GPU 上进行了尝试。但是，考虑到这是 OpenGL ES 的最佳实践，我们使用 VBO。

您可以在我们的article（顶点缓冲区对象段落）中找到有关此内容的说明。

【讨论】：

非常感谢您分享这些结果。最后，从性能的角度来看，这很重要。无论如何，我无法解释自己如何在共享内存 GPU 中如此提倡 VBO 的使用，我想这只是为了营销或“准备”那些对 GL 相对较新的人了解良好实践（不告诉这一点，在目前，最好不要使用它们，因为如果您仍然需要 CPU 端它们可能会导致内存翻倍，并且因为不可避免的复制操作）。

【解决方案2】：

根据这份报告，即使保持 SMA 不变，它也取决于 OpenGL 实现（一些 VBO 工作是在 CPU 上秘密完成的）和 VBO 的大小：

【讨论】：

【解决方案3】：

我会告诉你，我对 iOS 平台的了解。 VBO 确实可以提高你的表现。

VBO 是完美的，如果你有一个静态几何图形 - 一旦复制，每次绘制调用都没有额外的开销。 CA 会在每次绘制调用时将您的数据从客户端内存复制到“gpu 内存”。如果您忘记了，它可能会重新调整数据。
VBO 可以通过 glMapBuffer 映射到 gpu - 这是一个异步操作，这意味着它几乎没有开销，但您应该记住 - 当您映射\取消映射缓冲区时，最好在取消映射操作后 2 帧使用它- 避免同步
Apple 工程师宣称，VBO 将比 SGX 硬件上的 CA 具有更好的性能，即使您每帧都重新上传它 - 我不知道细节。
VBO 是最佳实践。 CA 已弃用。更好地跟上现代趋势，并尽可能多地跨平台

【讨论】：

嗯，当然你的观点是使用 VBO 的标准原因，但不幸的是，大多数已经在问题中排除了。
没有关于缓冲区映射的内容 - 这是在 CPU 和 GPU 之间发送几何图形的最快方式，但有一定的限制
缓冲区映射不应该在我的问题中发挥作用，它的目标是更新缓冲区内容，而我询问的是在向 GL Vertex Puller（DX 术语中的 Input Assembler）提供数据。