减少opengl 3 & 的技巧Linux下4帧率卡顿
近年来我为 OpenLG 2 和 ES 开发了几个小游戏和应用程序。 我现在正在尝试构建一个基于 opengl 3+ 的场景图，用于桌面系统上的休闲“3D”图形。 （没有什么比 unreal- 或rytec-engine 更复杂的了。）
我开始使用 OsX 10.7 进行开发，并对 Apple 最近发布的 ogl 3.2 印象深刻，它与 Windows 系统相比取得了相同的结果。
否则，Linux 的结果将令人失望。即使是最基本的动画也很卡顿，破坏了现实的印象。 Windows 工具包 freeglut 和 glfw 之间的结果没有差异。 （扩展加载了 glew 1.7）
我想提一下，我正在谈论新的 opengl 核心，而不是旧的 opengl 2 渲染路径，它在 Linux 下工作正常，但使用 cpu 而不是 gpu 来进行复杂的操作。
在观看了像“Unigine heaven demo”这样的专业演示之后，我认为在 Linux 上使用现代实时 3D 图形存在一个普遍的问题。
非常欢迎任何解决此问题的建议。
更新：
我正在使用： AMD Phenom II X6、Radeon HD57XX 配备最新专有驱动程序 (11.8) 和 Unity(64 位)。
您可以从工具包文档中获取我的渲染循环：
do {
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
...
} while (!glfwGetKey(GLFW_KEY_ESC) && glfwGetWindowParam(GLFW_OPENED));
我正在使用VBO，并且所有转换阶段都是通过着色器完成的。动画计时是通过glfwGetTime()完成的。此问题发生在窗口和全屏模式下。我不知道合成管理器是否会干扰全屏应用程序。但也不可能要求用户禁用它。
更新 2：
拼写错误：我使用的是 HD57XX 卡。
GLX_Extension： http://snipt.org/xnKg
PCI 转储：01:00.0 VGA 兼容控制器：ATI Juniper Technologies Inc [Radeon HD 5700 系列]
X 信息：http://pastie.org/2507935
更新 3：
禁用合成管理器可以减少但并不能完全消除卡顿现象。 （我用“ubuntu classic without Extensions”替换了标准窗口管理器） 一旦每秒动画冻结并出现丑陋的扭曲：（
图像已删除 - 不允许发布图像。）
尽管在驱动程序中启用了垂直同步并在应用程序中进行了检查。
In recent years I've developed several small games and applications for OpenLG 2 and ES.
I'm now trying to build a scene-graph based on opengl 3+ for casual “3D” graphics on desktop systems. (Nothing complex like the unreal- or crytec-engine in mind.)
I started my development with OsX 10.7 and was impressed by Apples recent ogl 3.2 release which achieves equivalent results compared to windows systems.
Otherwise the results for Linux are a disappointment. Even the most basic animation is stuttering and destroys the impression of reality. The results did not differ between the windows toolkits freeglut and glfw. (The Extensions are loaded with glew 1.7)
I would like to mention that I'm talking about the new opengl core, not the old opengl 2 render-path, which works fine under Linux but uses the cpu instead of the gpu for complex operations.
After watching professional demos like the “Unigine heaven demo” I think there is a general problem to use modern real-time 3D graphics with Linux.
Any suggestions to overcome this problem are very welcome.
UPDATE:
I'm using:
AMD Phenom II X6, Radeon HD57XX with latest proprietary drivers (11.8) and Unity(64Bit).
You could take my renderloop from the toolkit documentation:
do {
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
...
} while (!glfwGetKey(GLFW_KEY_ESC) && glfwGetWindowParam(GLFW_OPENED));
I'm using VBOs and all transformation stages are done with shaders. Animation timing is done with glfwGetTime(). This problem occurs in window and full-screen mode. I don't know if a composition manager interferes with full-screen applications. But it is also impossible to demand from the user to disable it.
Update 2:
Typo: I'm using a HD57XX card.
GLX_Extension: http://snipt.org/xnKg
PCI Dump: 01:00.0 VGA compatible controller: ATI Technologies Inc Juniper [Radeon HD 5700 Series]
X Info: http://pastie.org/2507935
Update 3:
Disabling the composition manager reduces, but did not completely remove the stuttering.
(I replaced the standard window manager with "ubuntu classic without extensions")
Once a second the animation freezes and ugly distortions appear:
(Image removed - Not allowed to post Images.)
Although Vertical synchronisation is enabled in the driver and checked in the application.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
由于您运行的是 Linux，我们需要一些详细信息：
您使用哪种硬件？
到目前为止，只有 NVidia、AMD/ATI 和 Intel 提供 3D 加速。
哪些驱动程序？
对于 NVidia 和 AMD/ATI，有专有（nvidia-glx、fglrx）和开源驱动程序（nouveau、radeon）。对于英特尔，只有开源驱动程序。
您运行合成窗口管理器吗？
合成会产生一大堆同步和计时问题。此外，您可以在某些地方的合成 WM 中找到的（某些）OpenGL 代码会让经验丰富的 OpenGL 编码人员热泪盈眶，特别是如果您有编写实时 3D（游戏）引擎的经验。
KDE4 和 GNOME3 默认使用合成（如果可用）。 Ubuntu Unity 桌面 shell 也是如此。另外，对于某些非合成 WM，默认脚本会启动 xcompmgr 以获得透明度和阴影效果。
最后但并非最不重要的一点：您是如何实现渲染循环的？
经常发现的一个错误是，使用计时器以“定期”间隔发出重新显示事件。这不是正确的做法。定时器事件可以任意延迟，而且标准定时器本身也不是很准确。
正确的方法是在紧密循环中调用显示函数并测量渲染迭代之间所需的时间，然后使用此计时来相应地推进动画。一种真正优雅的方法是使用 VSync 扩展之一来提供显示刷新频率和刷新计数器。这样，您就可以准确地获悉显示刷新周期中帧之间的提前时间，而不是使用计时器。
Since you're running Linux we require a bit of detailed information:
Which hardware do you use?
Only NVidia, AMD/ATI and Intel offer 3D acceleration so far.
Which drivers?
For NVidia and AMD/ATI there are propritary (nvidia-glx, fglrx) and open source drivers (nouveau, radeon). For Intel there are only the open source drivers.
Do you run a compositing window manager?
Compositing creates a whole bunch of synchronization and timing issues. Also (some of) the OpenGL code you can find in the compositing WMs at some places drives tears into the eyes of a seasoned OpenGL coder, especially if one has experience writing realtime 3D (game) engines.
KDE4 and GNOME3 by default use compositing, if available. The same holds for the Ubuntu Unity desktop shell. Also for some non-compositing WMs the default skripts start xcompmgr for transparency and shadow effects.
And last but not least: How did you implement your rendering loop?
A mistake oftenly found is, that a timer is used to issue redisplay events at "regular" intervals. This is not how it's done properly. Timer events can be delayed arbitrarily, and the standard timers are not very accurate by themself, too.
The proper way is to call the display function in a tight loop and measure the time it takes between rendering iterations, then use this timing to advance the animation accordingly. A truly elegant method is using one of the VSync extensions that delivers one the display refresh frequency and the refresh counter. That way instead of using a timer you are told exactly the time advanced between frames in display refresh cycle periods.