渲染期间 CPU 负载高

发布于 2024-11-10 04:28:22 字数 223 浏览 1 评论 0原文

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

你能给我一些线索为什么会发生这种情况吗?

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

I am rendering rather heavy object consisting of about 500k triangles. I use opengl display list and in render method just call glCallList. I thought that once graphic primitives is compiled into display list cpu work is done and it just tells gpu to draw. But now one cpu core is loaded up to 100%.

Could you give me some clues why does it happen?

UPDATE: I have checked how long does it take to run glCallList, it's fast, it takes about 30 milliseconds to run it

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

凉城凉梦凉人心 2024-11-17 04:28:22

您很可能会达到列表长度的限制,即每个列表有 64k 个顶点。尝试将 500k 个三角形(1500k 个顶点?)分成更小的块,看看会得到什么。

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

Most likely you are hitting the limits on the list length, which are at 64k verteces per list. Try to split your 500k triangles (1500k verteces?) into smaller chunks and see what you get.

btw which graphical chips are you using? If the verteces are processed on CPU, that also might be a problem

太阳男子 2024-11-17 04:28:22

显示列表神奇地将所有内容卸载到 GPU 的说法有点神话。如果确实如此,则不需要将纹理对象和顶点缓冲区添加到 OpenGL。所有显示列表实际上都是重播一系列 OpenGL 调用的便捷方法,并有望节省一些函数调用/数据转换开销(请参阅 此处)。据我所知,我使用过的 PC 硬件实现似乎没有做更多的事情;也许 SGI 工作站时代的情况有所不同,但现在缓冲区对象是正确的选择。 (现代 OpenGL 书籍,如 OpenGL Distilled 给 glBegin/glEnd 等仅在陷入新事物之前最简短地提及)。

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

但是,除了显示列表之外,您应该注意有关垂直同步和忙等待(或它的错觉)的一些问题...请参阅 这个问题/答案。

It's a bit of a myth that display lists magically offload everything to the GPU. If that was really the case, texture objects and vertex buffers wouldn't have needed to be added to OpenGL. All the display list really is, is a convenient way of replaying a sequence of OpenGL calls and hopefully saving some of the function call/data conversion overhead (see here). None of the PC HW implementations I've used seem to have done anything more than that so far as I can tell; maybe it was different back in the days of SGI workstations, but these days buffer objects are the way to go. (And modern OpenGL books like OpenGL Distilled give glBegin/glEnd etc the briefest of mentions only before getting stuck into the new stuff).

The one place I have seen display lists make a huge difference is the GLX/X11 case where your app is running remotely to your display (X11 "server"); in that case using a display list really does push all the display-list state to the display side just once, whereas a non-display-list immediate-mode app needs to send a bunch of stuff again each frame using lots more bandwidth.

However, display lists aside, you should be aware of some issues around vsync and busy waiting (or the illusion of it)... see this question/answer.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文