渲染期间的高 CPU 负载答案

【问题标题】：high cpu load during rendering渲染期间的高 CPU 负载
【发布时间】：2023-04-09 01:56:01
【问题描述】：

我正在渲染由大约 500k 个三角形组成的相当重的对象。我使用 opengl 显示列表，在渲染方法中只调用 glCallList。我认为一旦将图形基元编译到显示列表中，cpu 工作就完成了，它只是告诉 gpu 进行绘制。但是现在一个 cpu 核心的负载高达 100%。

你能给我一些线索为什么会发生吗？

更新：我检查了运行 glCallList 需要多长时间，它很快，运行大约需要 30 毫秒

【问题讨论】：

你使用简单的游戏循环还是垂直同步？通常，没有sleep 的游戏循环会占用 100% 的 CPU。
30 毫秒是巨大的。 30 fps 意味着 33 毫秒/帧，所以你只剩下 3 毫秒...避免显示列表，顺便说一句。
@Scan，我用的是 FPSAnimator
@Calvin1602 显示列表有什么问题？

标签： java opengl jogl

【解决方案1】：

您很可能已达到列表长度的限制，即每个列表的顶点数为 64k。尝试将你的 500k 三角形（1500k 顶点？）分割成更小的块，看看你会得到什么。

顺便说一句，您使用的是哪种图形芯片？如果顶点是在 CPU 上处理的，那也可能是个问题

【讨论】：

我检查了哪些函数正在消耗 cpu，它们来自 atioglx2.dll。不幸的是，我无法检查现在是否达到限制，稍后一段时间。我正在使用 ATI Mobility Radeon HD 2600 显卡
@misha 你确定你没有获得软件渲染吗？如果没有，那么你打破了限制
我没有设置任何选项来进行软件渲染。该限制 64k 是针对一个显示列表还是针对所有的，例如只有一个显示列表不能超过，还是所有显示列表的总和不能超过？
@misha 这个限制是针对一个列表的。我的意思是，如果您使用硬件不支持的东西，您将获得软件渲染。

【解决方案2】：

显示列表神奇地将所有内容卸载到 GPU 有点像神话。如果确实如此，则不需要将纹理对象和顶点缓冲区添加到 OpenGL。所有的显示列表实际上是重放一系列 OpenGL 调用并希望节省一些函数调用/数据转换开销的便捷方式（请参阅here）。据我所知，我使用的所有 PC 硬件实现似乎都没有做更多的事情。也许在 SGI 工作站时代它是不同的，但现在缓冲对象是要走的路。（而像 OpenGL Distilled 这样的现代 OpenGL 书籍只在陷入新事物之前给 glBegin/glEnd 等提供了最简短的提及）。

我看到显示列表产生巨大差异的一个地方是 GLX/X11 案例，您的应用程序远程运行到您的显示器（X11“服务器”）；在这种情况下，使用显示列表确实将所有显示列表状态推送到显示端一次，而非显示列表即时模式应用程序需要使用更多带宽在每帧再次发送一堆东西。

但是，除了显示列表之外，您应该注意一些关于 vsync 和忙等待（或它的错觉）的问题...见 this question/answer.

【讨论】：