linux - 使用随机暂停方法播放时驱动程序调用、openGL 调用和损坏的堆栈(A.K.A. Poor man's profiler)

Question

最近，我们面临着一个严重的性能问题。我们的游戏是一款特定 Linux 机器上的赛车游戏。我们的目标是 60 fps，但到目前为止我们只有 30 fps。

我们有自己的内部源代码级分析器，我们知道我们的热点是图形。但是，我们很难在图形模块中找到特定的热点。只是看起来一般都很慢。

看完Performance optimization strategies of last resort ，我决定在 callgrind 之前使用随机暂停方法，因为 gdb 足以完成此操作。我取了 25 个样本，发现了一个有趣的结果。

25 个样本中有 12 个来自 nVidia openGL 驱动程序:

0x4afe4f96 in ?? () from /usr/lib/libnvidia-glcore.so.270.41.06
0x00000003 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

或

0x4ad221f8 in __gmon_start__ () from /usr/lib/libnvidia-glcore.so.270.41.06
0xac08a0d8 in ?? ()
0xf72d50d9 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

25 个样本中有 4 个来自 libGL:

0xb7fff424 in __kernel_vsyscall ()
0x00854747 in poll () from /lib/libc.so.6
0x49e84af4 in ?? () from /usr/lib/libGL.so.1
0xb611ffe0 in ?? ()
0x00000001 in ?? ()
0x00000000 in ?? ()

似乎我们的游戏以某种方式对 openGL 驱动程序造成了巨大的负载。但是，由于所有这些损坏的调用堆栈，我如何确定负载来自何处？我发现几乎所有的驱动程序调用都被捕获到一些特定的地址，有没有办法找出这些函数是什么？

Answer 1

如果大部分时间花在图形驱动程序上，那么您在 GPU 上投入了过多或错误的工作。调用堆栈不会对您有太大帮助，因为现代图形驱动程序正在做很多技巧 - 在不同的线程中处理数据，或者批处理绘制调用而不是立即执行它们。

尝试这些方法来确定瓶颈在哪里:http://http.developer.nvidia.com/GPUGems/gpugems_ch28.html (图28-2)