Вызов драйвера, вызов openGL и поврежденный стек при игре с методом случайной паузы (A.K.A. Бедный профилировщик) - PullRequest
0 голосов
/ 30 января 2012

В последнее время мы столкнулись с серьезной проблемой производительности. Наша игра - это гоночная игра на конкретной коробке с Linux. Наша цель - 60 кадров в секунду, но у нас пока только 30 кадров в секунду.

У нас есть собственный профилировщик на уровне исходного кода, и мы знаем, что наша горячая точка - это графика. Тем не менее, мы едва ли можем найти конкретную горячую точку в нашем графическом модуле. Просто кажется, что это вообще медленно.

Прочитав Стратегии оптимизации производительности последней инстанции , я решил поиграть с методом случайной паузы перед callgrind, так как GDB достаточно, чтобы сделать трюк. Я взял 25 образцов и нашел интересный результат.

12 из 25 образцов взяты из драйвера 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?)

4 из 25 образцов взяты из 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. Но, со всеми этими поврежденными стеками вызовов, как я могу определить, откуда происходит загрузка? Я обнаружил, что почти все вызовы драйверов были перехвачены по определенным адресам, есть ли способ узнать, что это за функции?

Ответы [ 3 ]

2 голосов
/ 30 января 2012

Если большая часть времени тратится на графический драйвер, значит, вы слишком много работаете или неправильно работаете с графическим процессором. Стек вызовов не очень вам поможет, потому что современные графические драйверы делают много хитростей - обрабатывают данные в другом потоке или группируют вызовы отрисовки вместо их немедленного выполнения.

Попробуйте эти методы, чтобы определить, где находится ваше узкое место: http://http.developer.nvidia.com/GPUGems/gpugems_ch28.html (Рисунок 28-2)

1 голос
/ 30 января 2012

Вы пробовали профилирование с OProfile?

В любом случае: тратить столько времени на водителя - это признак того, что вы делаете что-то в корне неправильно. Вы проверяли следующее:

  • Рисование непрозрачных объектов сортируется по текстурам -> шейдеры -> спереди назад - переключение текстур снижает производительность
  • Используются ли Vertex Arrays или лучше объекты Vertex Buffer?
  • Размер пакета для glDrawArrays, glDrawElements где-то между 500 и 2000 примитивами?
  • Не использовать немедленный режим (glBegin glVertex glEnd).
1 голос
/ 30 января 2012

Драйвер, вероятно, скомпилирован с опущенными указателями кадров, что затруднит или сделает невозможным отслеживание стека.К сожалению, я не знаю каких-либо простых обходных путей, если это закрытый исходный код.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...