Профилирование GPU для Android - OpenGL Live Wallpaper медленный

Question

Я разрабатываю Live Wallpaper, используя OpenGL ES 3.0. Я установил в соответствии с отличным учебником по адресу http://www.learnopengles.com/how-to-use-opengl-es-2-in-an-android-live-wallpaper/, адаптировав GLSurfaceView и используя его в Live Wallpaper.

У меня есть хорошее знание лучших практик OpenGL/GLSL, и я создал простой конвейер рендеринга, где цикл ничьей настолько плотный, насколько это возможно. Нет перераспределений, используя один статический VBO для не изменяющихся данных, динамический VBO для обновлений, используя только один вызов рисования, без разветвления в шейдерах и так далее. Я обычно получаю очень хорошую производительность, но, по-видимому, случайные, но повторяющиеся времена, частота кадров падает.

Профилирование с помощью экранных стержней дает мне интервалы, когда желтая полоса («ожидая завершения команд») отстреливается и занимает все выше критического порога 60fps.

Я прочитал какие-либо ресурсы по профилированию и интерпретации этих цифр я могу получить мои руки, в том числе хорошо углубленные SO question here. Однако основной вывод из этого вопроса заключается в том, что желтая полоса указывает время, проведенное на , ожидая завершения операций блокировки и для зависимостей кадров. Я не верю, что у меня есть что-то из этого, я просто рисую все в каждом кадре. No reading.

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

Вот некоторые детали, которые могут или не могут иметь влияние:

• Я рендеринга на спрос, onOffsetsChanged является триггером (визуализироваться при загрязнен).
• Существует одна текстура (созданная и связанная только один раз), 1024x1024 RGBA. Замена одного вызова texture2D простым vec4, похоже, помогает удалить некоторые капли частоты кадров. Уменьшение размера текстуры до 512x512 ничего не делает для производительности.
• Шейдеры не сложны, и, как указано выше, не содержат разветвлений.
• В сцене мало данных. Есть только ~ 300 вершин и одна текстура.
• Systrace не обнаруживает подозрительных методов - связанные с GL методы, такие как совокупность буфера и государственные вызовы, не находятся в верхней части списка.

Update: В качестве эксперимента, я пытался оказать только каждый второй кадр, не просит вынести все onOffsetsChanged (проведите пальцем влево/вправо). Это было ужасно для внешнего вида, но почти полностью избавилось от желтых пятен. Это, кажется, говорит мне, что делать 60 запросов на фрейм слишком много, но я не могу понять, почему.

Answer 1

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

(1) Накопление состояния визуализации.Убедитесь, что вы «glClear» буферы цвета/глубины/трафарета перед началом каждого прохода рендеринга (хотя, если вы визуализируетесь непосредственно на поверхности окна, это вряд ли будет проблемой, так как состояние гарантировано будет очищено каждый кадр, если вы не установите EGL_BUFFER_PRESERVE).

(2) Буфер/текстура ореола. Рендеринг глубоко конвейерный, но OpenGL ES пытается представить аббревиатуру синхронного программирования. Если вы попытаетесь записать в буфер (обновление SubBuffer, обновление SubTexture, MapBuffer и т. Д.), Которое все еще «ожидает» в операции GPU, все еще поставленной в очередь в конвейере, тогда вам либо придется блокировать, либо ждать, либо вы принудительно копируете этот ресурс будет создан. Этот процесс копирования может быть «очень дорогим» для больших ресурсов.

(3) Устройство DVFS (динамическое масштабирование по частоте и напряжению) может быть довольно чувствительным на некоторых устройствах, особенно для контента, который, как правило, находится около точки решения уровня между двумя частотами. Если частота GPU или CPU падает, вы можете получить всплеск времени, затрачиваемого на обработку кадра. Для целей отладки некоторые устройства обеспечивают средство для исправления частоты через sysfs - хотя стандартного механизма нет.

(4) Термические ограничения - большинство современных мобильных устройств могут выделять больше тепла, чем они могут рассеиваться, если все работает на высокой частоте, поэтому максимальная рабочая точка не может быть устойчивой. Если ваш контент особенно тяжелый, вы можете обнаружить, что управление температурой запускается после «в то время» (1-10 минут в зависимости от устройства, по моему опыту) и сильно снижает частоту, пока температурные уровни не упадут в безопасных пределах. Это проявляется как несколько случайное увеличение времени обработки кадров и, как правило, непредсказуемо, когда устройство попадает в «теплое» состояние.

Если можно разделить последовательность API, который воспроизводит проблему было бы легче обеспечить более целенаправленный совет - вопрос действительно довольно общий и OpenGL ES очень широкий API;)