为什么 CGLFlushDrawable 这么慢？（我正在使用 VBO）答案

【问题标题】：Why is CGLFlushDrawable so slow? (I am using VBOs)为什么 CGLFlushDrawable 这么慢？（我正在使用 VBO）
【发布时间】：2012-05-08 22:01:04
【问题描述】：

我的申请详情：

运行：Macbook pro 4GB RAM，ATI Radeon X1600 128MB VRAM，Opengl 版本：2.1 ATI-7.0.52

使用垂直同步（通过 CVDisplay）：是

编程语言：Lisp (Lispworks) with FFI to Opengl

像素格式信息

ns-open-gl-pfa-depth-size 32
ns-open-gl-pfa-sample-buffers 1
ns-open-gl-pfa-samples 6
ns-open-gl-pfa-加速 1
ns-open-gl-pfa-no-recovery 1
ns-open-gl-pfa-backing-store 0
ns-open-gl-pfa-virtual-screen-count 1

[1 = YES, 0 = NO] 用于布尔属性

我的应用程序中有以下网格：

14 个静态网格（不会改变）。我已经为每个具有静态绘制类型的网格定义了一个 VBO。

2 个动态网格（每帧变化）。我已经为每个具有流绘制类型的网格定义了一个 VBO。

对于这些动态网格，每帧我使用空指针绑定缓冲区数据，然后映射缓冲区，更新映射的缓冲区并取消映射缓冲区。

当我运行应用程序并使用 Opengl 分析器检查时：它显示以下（统计视图）：

CGLFlushDrawable：

平均时间（以微秒为单位）：52990.63 = 52.990 毫秒
% GL 时间：98.55
% 应用时间：43.96

难怪我的 FPS 很差，大约 6-7 FPS。

优化CGLFlushDrawable的方法是什么，因为我只是调用flushBuffer，我相信它反过来又调用CGLFlushBuffer。

【问题讨论】：

您确定其中一些渲染没有被延迟，而 CGLFlushDrawable 只是它最终执行的点，所以您最终会看到它的成本吗？
使用 VBO 是否意味着使用延迟渲染？（作为opengl的新手，我不太了解延迟渲染的概念）。从我的 opengl 驱动程序监视器中，我看到我的“当前可用视频内存”非常少，通常当前值约为 10MB，而最大值约为 128 MB VRAM 的 32 MB。这个显存数据会不会和 cglflushdrawable 的性能有关？
我的意思是，我看到分析器对在 OpenGL 渲染管道中花费的时间感到困惑，因为在您发送命令时不会立即执行命令。在移动设备上基于图块的延迟渲染器上尤其如此，但我也在 Mac 上看到过。当系统需要完成整个场景并将其呈现到屏幕上时，可以累积并最终触发这些命令，就像在 NSOpenGLContext 上使用 -flushBuffer 时一样。这会导致分析器在那里看到大量活动，而不是在您发送命令时。
@Brad，感谢您的解释。在我的应用程序事件循环中，我只是遍历网格、绑定 VBO 等，最后在我的 opengl 上下文实例上调用 flushBuffer。我再次查看了统计查看器日志。我看到在 CGLFlushDrawable 调用之间，花费的时间几乎不是 1 毫秒。但是对于 CGLFlushDrawable，我看到一些调用只需要 0.4 毫秒，而在另一个极端是 200 毫秒。这似乎很奇怪。还是opengl很正常？
您是否使用 CVDisplayLink 将更新与显示刷新率同步？这并不能解释您长时间的延迟，但是当您渲染与屏幕刷新不同步时，我看到了口吃。

标签： opengl buffer flush frame-rate

【解决方案1】：

嗯，原来是我的 ATI Radeon X1600 显卡有问题。

在没有任何更改的情况下，当我在另一台具有 Intel HD Graphics 3000 和 384MB DDR3 SDRAM 的较新的 13 英寸 Macbook Pro 上测试相同的代码时，该应用程序可以正常工作考虑到我拥有的动态网格，大约 30 FPS 这是我所期望的。

另外，CGLFlushDrawable 中没有任何瓶颈，就像我以前的情况一样 MBP。此外，在 VBO 分配后可用的 VRAM 中的内存量保持不变（又是我所期待的）。这不是我的旧 MBP 上发生的情况。

最后，我的 MBP 显示器崩溃了（虽然不够频繁），外接 LCD 显示器也无法正常工作，这表明我的显卡存在问题。

@Brad，感谢您的所有投入。

【讨论】：