Идентификация и решение проблем производительности
Монитор Драйвера OpenGL не является основным инструментом для анализа проблем производительности в приложении OpenGL. Это - резервный инструмент, который используют эксперты, когда Инструменты и Профилировщик OpenGL не показывают причину проблемы производительности. Эта глава предполагает, что Вы уже использовали другие инструменты Apple для анализа приложения OpenGL.
Стратегии, описанные здесь, могут помочь Вам идентифицировать наиболее распространенные проблемы, происходящие в приложениях OpenGL. Следует иметь в виду, что анализ трудных проблем производительности является большим количеством искусства, чем наука. Несмотря на то, что Вы захотите запуститься с этих основных стратегий, необходимо будет разработать дополнительные, адаптированные в соответствии с типом проблемы, которую Вы видите, и к тому, пытаетесь ли Вы решить проблему драйвера или приложение один.
Проверка методы наиболее успешной практики
Прежде чем Вы начнете использовать Монитор Драйвера OpenGL в качестве аналитического инструмента, это - хорошая идея проверить Ваш код, чтобы видеть, следуете ли Вы за новыми методами наиболее успешной практики для использования OpenGL. См.:
“Улучшающаяся Производительность” глава в Руководстве по программированию OpenGL для Mac для обсуждения методов наиболее успешной практики
Руководство пользователя Профилировщика OpenGL. Вы найдете уведомление относительно функций, что необходимо удостовериться, что Вы используете правильно при использовании их вообще.
Проверка скоростей передачи данных
Для проверки скоростей передачи данных контролируйте следующее:
Использование VRAM. Посмотрите, является ли использование VRAM на полной мощности путем рассмотрения Текущей Видеопамяти в Использовании (
vramUsedBytes) или текущая память бесплатного видео (vramFreeBytes). Если это на полной мощности, займитесь расследованиями, является ли система низкой на VRAM или высоко ли использование VRAM необычно для приложения, работающего на системе.Уровень подкачки. Множество параметров, таких как Буферные Подкачки (
bufferSwapCount), позвольте Вам исследовать причину необычно высоких уровней подкачки. Проверьте, чтобы видеть, являются ли подкачанные данные динамичными или статичными. Если данные статичная OS, удостоверьтесь, что Вы используете кэши, буферные объекты вершины или некоторый другой метод, это оптимизировано для статических данных. Используйте подкачки только для динамических данных, и только когда изменятся данные.Время проведено CPU, ожидающим GPU. Взгляд на CPU Ожидает GPU (
hardwareWaitTime). Если CPU проводит много времени, просто ожидая, проверьте, чтобы видеть, вызываете ли ВыglFlushилиglFinishнеуместно. Существует только несколько случаев, где фактически необходимо использовать эти вызовы, и эти случаи редки. Для получения дополнительной информации посмотрите “Улучшающуюся Производительность” глава в Руководстве по программированию OpenGL для Mac.
Проверка субоптимальную разбивку на страницы поверхности и текстуры
Необходимо удостовериться, что приложение не является текстурой разбивки на страницы и поверхностными данными излишне. Когда это действительно разбивает на страницы, необходимо использовать ускоренный графический порт (трасса AGP, которая также известна как передача DMA). Non-AGP передает медленную производительность. Можно проверить на менее оптимальную разбивку на страницы путем рассмотрения этих параметров:
Поверхностная страница от данных (Non-AGP) (
surfacePageOffBytes)Поверхностная страница на данных (Non-AGP) (
surfacePageInBytes)Страница текстуры от данных (Non-AGP) (
texturePageOutBytes)Страница текстуры от данных (Non-AGP) (
texturePageInBytes)
Передача Non-AGP приемлема, только если необходимо переупорядочить данные или выровнять их. Если возможно, используйте этот тип передачи данных во время инициализации а не во время цикла рендеринга.
Если Ваше приложение имеет большое действие разбивки на страницы, является ли это AGP или non-AGP, рассмотрите использование объектов кадрового буфера.