Настройка производительности iPhone openGLES

Question

Сейчас я довольно долго пытаюсь оптимизировать частоту кадров моей игры, не добиваясь прогресса. Я работаю на новейшем iPhone SDK и имею устройство iPhone 3G 3.1.2.

Я вызываю около 150 разрозненных вызовов, в результате чего получается около 1900 треугольников (все объекты текстурированы с использованием двух текстурных слоев и мультитекстурирования. Большинство текстур получаются из одной текстуры textureAtlasTexture, хранящейся в сжатой текстуре pvrtc 2bpp). Это делает мой телефон на скорости около 30 кадров в секунду, что мне кажется слишком низким только для 1900 треугольников.

Я пробовал много вещей для оптимизации производительности, в том числе пакетирование объектов, преобразование вершин в ЦП и рендеринг их в одном вызове. в результате получается 8 вызовов (в зависимости от 150 вызовов), но производительность примерно такая же (частота кадров падает примерно до 26 кадров в секунду)

Я использую 32-байтовые вершины, хранящиеся в чередующемся массиве (позиция 12 байтов, нормали 12 байтов, ультрафиолетовые 8 байтов). Я рендеринг triangleLists и вершины упорядочены в порядке TriStrip.

Я провел профилирование, но не знаю, как его интерпретировать.

1. приборы для отбора проб с помощью инструментов и сэмплирования получается такой результат: http://neo.cycovery.com/instruments_sampling.gif говорит мне, что много времени тратится в "mach_msg_trap". Я гуглил это, и кажется, что эта функция вызывается, чтобы ждать некоторых других вещей. Но ждать чего ??

2. приборы-OPENGL инструменты с модулем openGL дают такой результат: http://neo.cycovery.com/intstruments_openglES_debug.gif но здесь я действительно понятия не имею, что эти цифры говорят мне

3. профилирование акул: профилирование с акулой мне тоже мало что говорит http://neo.cycovery.com/shark_profile_release.gif наибольшее число составляет 10%, тратится DrawTriangles - и все остальное тратится в функции очень маленький процент

Может ли кто-нибудь сказать мне, что еще я мог бы сделать, чтобы выяснить узкое место и помочь мне интерпретировать эту информацию профилирования?

Большое спасибо!

Answer 1

Возможно, вы привязаны к процессору. Статистика использования тайлера / рендерера в инструменте OpenGL ES показывает, что рабочий цикл графического процессора составляет 20-30% для рендеринга со скоростью 20-30 кадров в секунду, что говорит о том, что графический процессор может работать со скоростью 60 кадров в секунду, если подаётся достаточно быстро. Похоже, есть несколько вещей, которые вы могли бы сделать, чтобы получить больше информации от Инструментов и Акулы о том, что преследовать:

По умолчанию Sampler показывает каждый образец из каждого потока, что означает, что в основном в представлении будут доминировать вспомогательные потоки, созданные в основном системными фреймворками. Чтобы лучше понять, что на самом деле делает процессор, убедитесь, что отображается подробный вид (третья кнопка слева в левом нижнем углу) и измените Sample Perspective на Running Sample Times, чтобы исключить образцы, где поток простаивает / блокируется. .

Я не вижу никаких образцов в следе Акулы из самого вашего приложения. Это может быть связано с тем, что ваш код достаточно быстр, чтобы его не было нигде в списке горячих функций, но также потому, что Shark не может найти символы для вашего приложения. Возможно, вам придется настроить пути поиска в его настройках или вручную указать Shark на двоичный файл вашего приложения. Кроме того, Shark по умолчанию показывает список функций, упорядоченный по тому, сколько процессорного времени затрачивается на них. Может быть полезно изменить представление на нечто более похожее на обычное дерево вызовов, чтобы вы могли визуализировать, как ваш общий цикл рендеринга тратит свое время. Для этого измените параметр «Вид» в правом нижнем углу на «Дерево (сверху вниз)». (Если вы не видите здесь ни названия своего приложения, ни функций, то Акула определенно пропускает ваши символы.)

Answer 2

Если вы используете glFlush или glFinish, удалите все из них.

Answer 3

Без полного источника трудно точно сказать, что происходит.Трассировка инструментов показывает использование рендера на 20%, что немного ниже.Это, вероятно, означает, что вы связаны с процессором.Однако, если бы это было так, я бы ожидал увидеть больше точек выборки для вашего приложения в вашей первой трассировке.

Мой совет - бросить ваш собственный класс синхронизации.Примерно так (c ++):

#include <sys/time.h>

class Timer
{
public:
    Timer()
    {
        gettimeofday(&m_time, NULL);
    }
    void Reset()
    {
        gettimeofday(&m_time, NULL);
    }
    // returns time since construction or Reset in microseconds.
    unsigned long GetTime() const
    {
        timeval now;
        gettimeofday(&now, NULL);
        unsigned long micros = (now.tv_sec-m_time.tv_sec)*1000000+
                               (now.tv_usec-m_time.tv_usec);
        return micros;
    }
    protected:
        timeval m_time;
};

Время ваших разделов кода, чтобы точно знать, где ваше время тратится.

Также еще одним быстрым решением является отключение набора команд Thumb.Это может повысить производительность с плавающей запятой на 20% и более за счет размера исполняемого файла.

Answer 4

К сожалению, я не очень разбираюсь в OpenGL, но вот некоторые вещи, которые можно выделить из трех результатов:

1) Из инструмента «Выборка» может быть установлено какое-то фоновое веб-соединение?

2) Процент визуализации использования мне кажется низким (хотя я не знаю, как их улучшить).

3) Хотя 10% кажется низким, это похоже на хорошую точку атаки - однако почти в равной степени подозрительно, что в memcpy столько времени проводят. Также ValidateState является довольно большой суммой и может сдерживать вас.

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