Intel Graphics Performance Analyzer 2.0 — новый набор утилит для 3D разработчиков





Введение

Разработчики 3D приложений хорошо знают, как важны в их работе удобные средства по анализу построения кадра и производительности рендеринга. Современные трехмерные приложения очень сложны, и со временем эта сложность только увеличивается. Для того, чтобы программисты оптимально использовали возможности разных видеочипов, им нужны утилиты, помогающие обнаруживать ошибки и «узкие» места в их приложениях, ограничивающие производительность.

GPU и CPU в пределах каждого кадра выполняют множество различных операций графического конвейера, и общая производительность зависит от наиболее медленного участка. Именно поэтому удобные средства отладки так важны, ведь разобраться в сотнях вызовов функций, происходящих за несколько миллисекунд, без соответствующих инструментов очень сложно.

Естественно, утилиты для 3D разработчиков существовали и раньше. Можно вспомнить Microsoft PIX for Windows из комплекта DirectX SDK. Или NVPerfKit от Nvidia, или GPU PerfStudio от ATI/AMD. Microsoft заинтересована в PIX не только из-за DirectX, но и из-за игровой консоли Xbox, а AMD с Nvidia сами производят GPU. Но у нас же есть и другие производители графики, причём лидирующие на рынке графических решений. Итак, сегодня мы рассмотрим пакет Intel Graphics Performance Analyzer 2.0, который был анонсирован на только что прошедшей выставке для игровых разработчиков GDC 2009.

Graphics Performance Analyzer 2.0

Intel Graphics Performance Analyzer (GPA) 2.0 — это набор утилит для 3D разработчиков, содержащий мощные средства для анализа производительности Direct3D приложений, нахождения «узких» мест и их оптимизации. Интерфейс утилит в целом традиционный для подобных инструментов, и он похож больше на то, что мы видели в Microsoft PIX for Windows, или у ATI/AMD, чем на схожие по цели утилиты компании Nvidia, ранее рассмотренные в материалах нашего сайта.

Пакет GPA 2.0 можно получить на сайте компании Intel, предварительно зарегистрировавшись (бесплатно) в програме Visual Adrenalin.

Компоненты, входящие в состав GPA 2.0:

  • System Analyzer — графическая утилита для анализа производительности трёхмерных приложений.
  • Frame Capture — утилита для захвата данных построения кадров.
  • Frame Analyzer — приложение для детального анализа построения кадра, отладки и изменения шейдеров и состояний DX в реальном времени.
  • Remote Server — серверная часть пакета, совместно с видеодрайвером выполняющая сбор данных со счётчиков производительности, и управляющая D3D приложением.
  • SDK — средства для доступа к возможностям пакета из пользовательских приложений, с примерами исходного кода.

Системные требования пакета утилит GPA, прежде всего, обусловлены поддержкой на момент его выхода исключительно интегрированного видео компании Intel. Так как до выпуска давно ожидаемых дискретных продуктов от этой компании ещё далеко, то поддержка утилит есть на данный момент только у чипсетов: настольного Intel G45 Express и мобильного Intel GM45 Express. Именно это является основным требованием к тестовой системе.

Системные требования Intel GPA 2.0

  • Графическое ядро производства компании Intel. На данный момент это лишь два интегрированных решения: Intel G45 Express и мобильный Intel GM45 Express, с установленным видеодрайвером свежей версии.
  • Операционная система Microsoft Windows XP (SP2 и выше) или Windows Vista (32-бит и 64-бит версии) с установленным последним обновлением Microsoft DirectX runtime (в комплекте).
  • Microsoft .NET Framework 3.5 (в комплекте).

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

System Analyzer

Утилита с таким названием, которую мы рассматриваем первой, позволяет проводить анализ производительности, помогающий в определении «узких» мест (bottleneck) кода программы. Также она полезна и для других прикладных задач, например, определения упора в CPU и GPU, или в отдельные блоки видеочипа.

Анализ производительности и настройка 3D приложения — это всегда очень сложный и длительный процесс. System Analyzer облегчает подобные задачи. При помощи графического интерфейса этого приложения в удобном виде представлены многочисленные счётчики (Intel их называет метриками, но суть одна) производительности. Дополнительно можно использовать специальные обходные режимы («override modes»), при которых часть конвейера 3D рендеринга исключается из работы, что позволяет с точностью определить потенциальные «узкие» места приложения и основные характеристики системы, влияющие на общую производительность (скорость CPU, мощь текстурных модулей и т.д.).

GPA System Analyzer осуществляет сбор данных с программных и аппаратных счётчиков производительности, используя специализированный инструментальный видеодрайвер. Утилита собирает данные со счётчиков в локальную базу, чтобы затем их можно было отобразить на экране для интерактивного анализа прямо в процессе работы 3D приложения. Можно притормозить процесс исполнения приложения в любое время, и выполнить различные эксперименты (см. далее) прямо на лету, без изменения кода. Пока что поддерживаются только Direct3D 9 приложения, другие API и версии D3D на данный момент не поддерживаются, хотя в будущем обещается поддержка Direct3D 10 и 11.

Пользователь пакета GPA может выбрать для анализа несколько нужных ему счётчиков производительности, включающих счётчики D3D, CPU и GPU. Приведём список счётчиков производительности, имеющийся в Graphics Performance Analyzer 2.0 (некоторые из них могут быть недоступны в публичных версиях пакета):

Раздел CPU

  • Aggregated CPU Utilization — суммарная загрузка всех ядер центрального процессора на тестовой системе.
  • CPU Breakout Utilization — столбчатая диаграмма для всех CPU в системе раздельно.
  • CPU Multi-line Utilization — линейная диаграмма для всех ядер процессора(-ов).
  • CPU Utilization — загрузка одного из ядер CPU тестовой системы, отображается отдельно: CPU 0, CPU 1 и т.д.
  • Target Application CPU Utilization — суммарная загрузка центрального процессора системы тестовым приложением (в отличие от вышеуказанных, которые показывают полную загрузку CPU).

Раздел DX (DirectX)

  • DX Draw Calls per Frame — число вызовов функций отрисовки за один кадр
  • DX VB Locks per Frame — количество блокировок (lock) вершинного буфера (vertex buffer — VB).
  • DX VB Lock Time per Frame — время в микросекундах, потраченное на все блокировки VB.
  • DX VB Lock Percent of Frame Time — доля времени блокировок вершинного буфера ко всему времени кадра (для многопоточных приложений может превышать 100%).
  • DX IB Locks per Frame — количество блокировок индексного буфера (index buffer — IB).
  • DX IB Lock Time per Frame — время в миллисекундах, потраченное на блокировки IB.
  • DX IB Lock Percent of Frame Time — доля времени блокировок IB ко всему времени кадра (для многопоточных приложений может быть более 100%).
  • DX Locks per Frame — общее количество блокировок вершинного и индексного буферов.
  • DX Lock Time per Frame — общее время, потраченное на блокировки VB и IB.
  • DX Lock Percent of Frame Time — доля времени, проведённого во всех блокировках VB и IB от общего времени кадра.
  • DX State Changes per Frame — число смен состояний (DX state) за последний кадр.
  • Frame Time — общее время кадра в миллисекундах.
  • Frames per Second — мгновенное количество кадров в секунду, рассчитанное для текущего кадра.
  • Graphics Memory Used —- объём графической памяти, использующийся в данный момент (работает только в Windows XP).
  • Texture Memory Used — объём текстурной памяти, занятый при рендеринге текущего кадра (только в Windows XP).

Раздел GPU

  • Clipper Invocation Count — количество пиксельных потоков, которые были отсечены clipper'ом (нет поддержки у чипсета Intel GS45 Express).
  • Driver Time — время, проведённое в видеодрайвере, в миллисекундах (только Windows XP).
  • Driver Time Stalled — время простоя видеодрайвера (только Windows XP).
  • Geometry Shader Invocation Count — количество выполненных потоков геометрического шейдера.
  • Pixel Shader Invocation Count — количество выполненных потоков пиксельных шейдеров.
  • Pixels Rendered — количество пикселей, записанных в буфер (render target), считается до Z-теста и альфа-теста.
  • Primitive Count — количество треугольников перед геометрическим шейдером.
  • System Memory Read Bandwidth — полоса пропускания системной памяти (ПСП) в МБ/с, используемая при чтении данных.
  • System Memory Write Bandwidth — ПСП при записи данных в системную память.
  • System Memory Overall Bandwidth — общая достигнутая ПСП при записи и чтении.
  • System Memory Multi-line Bandwidth — линейная диаграмма счётчиков System Memory Read Bandwidth, System Memory Write Bandwidth и System Memory Overall Bandwidth.
  • Vertex Count — количество вершин, обработанных при рендеринге кадра.
  • Vertex Shader Invocation Count — количество выполненных потоков вершинных шейдеров.

По умолчанию System Analyzer запускает следующий набор счётчиков: Frames per Second, CPU Utilization, CPU Multi-line Utilization, System Memory Write Bandwidth, System Memory Read Bandwidth, System Memory Overall Bandwidth, System Memory Multi-line Bandwidth.

Выбор хороший для большинства применений, но пользователь может создать и сохранить для дальнейшего использования свой набор счётчиков. Нужно просто выбрать интересующий счётчик в списке, вызвать контекстное меню, и с его помощью добавить счётчик на нужную диаграмму. Очень удобно, что в System Analyzer можно организовать и свои группы счётчиков, со своими названиями.

При помощи System Analyzer можно собирать данные со счётчиков, анализировать их, находить «узкие» места в 3D приложениях, а также захватывать данные о построении кадра для тщательного анализа в Frame Analyzer. Запуск утилиты возможен в двух режимах: сетевом и локальном (тот же самый сетевой, но используется одна система для тестов и для анализа.

Естественно, сетевой режим является наиболее удобным, и рекомендуется к использованию. Причин этому несколько, это и удобство (полноэкранные приложения никак не проанализируешь на одной системе), и точность измерений. Последнее важно потому, что сам по себе System Analyzer также потребляет ресурсы центрального процессора, что может понизить точность измерений в том случае, если System Analyzer и тестовое приложение запущены на одной системе.

Для сетевого режима GPA нужно запустить GPA Remote Server на тестовой системе, и System Analyzer на вспомогательной. Суть такой работы в том, что вспомогательная система посылает запрос на тестовую, та запускает приложение и собирает данные со счётчиков производительности, посылая их по сети на вспомогательный ПК, который отображает собранные данные.

В случае сетевого режима нужно задать некоторые параметры в утилите System Analyzer: IP адрес, путь к исполнимому файлу приложения (на тестовой системе), рабочий каталог (если программой используется несколько исполнимых файлов) и командную строку, если это необходимо. Также есть возможность запуска с форсированной вершинной обработкой на CPU («Force CPU Vertex Processing»). В этом режиме драйвер выполняет всю обработку вершин на CPU, а не GPU.

Для того, чтобы просигнализировать пользователю, что GPA работает в данном приложении, он добавляет в верхний левый угол изображения небольшой красный квадрат. Если его нет при запуске, значит, данное приложение не является D3D9 приложением, или же GPA не смог «перехватить» его вызовы.

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

Для более детального анализа есть возможность выгрузки (экспорта) собранных данных с диаграмм. Для выгрузки всех данных есть отдельная кнопка в правом верхнем углу, также можно экспортировать данные с одной из диаграмм, вызывая контекстное меню. Данные выгружаются в распространённый формат CSV, который можно открыть в Microsoft Excel, OpenOffice Calc, или других приложениях.

Одной из важнейших возможностей System Analyzer являются так называемые обходные режимы («Override Modes»). Эти режимы являются традиционными методами для тщательного анализа производительности приложения, и отлове ошибок в коде. Обходные режимы позволяют находить узкие места, ограничивающие производительность, при помощи изоляции части 3D конвейера. Так, если использование одного из обходных режимов заметно увеличивает общую производительность рендеринга, то именно исключённая из работы часть конвейера и является «узким» местом приложения. К примеру, если при форсировании текстур размером 2х2 пикселя производительность увеличивается в разы, то именно скорость текстурных выборок ограничивает скорость рендеринга.

Утилитой поддерживаются следующие виды обходных режимов:

Disable all Overrides — нормальный режим работы, все обходные пути выключены.

Null Hardware — отключает всю обработку на GPU. Если при выборе этого режима производительность сильно возрастает, значит, общая производительность ограничена скоростью видеочипа.

Null Driver — режим отключает обработку в драйвере. Если включенный Null Driver увеличивает производительность, а Null Hardware — нет, то приложение ограничено работой CPU в драйвере. В случае, если оба режима не ускоряют рендеринг, то само приложение ограничено скоростью центрального процессора.

Wireframe — известный всем режим визуализации, когда все объекты отображаются в виде геометрических сеток. Полезен для визуального отлова ошибок при неправильной отрисовке (связанной с сортировкой или неправильным отбросом геометрии). Обычно этот режим снижает производительность, но если скорость увеличивается, то это может быть вызвано, к примеру, очень простой геометрией, но сложным пиксельным шейдером. К сожалению, буфер при этом не очищается, поэтому результат не всегда удовлетворительный:

2x2 Texture — использование маленьких текстур размеров 2х2 пикселя вместо всех загруженных приложением текстур. Этот режим позволяет определить упор в производительность текстурных модулей. Если скорость в этом режиме сильно возрастает, значит GPU не справляется с текстурными выборками, или кэширование неэффективное (например, у текстур нет сгенерированных мипуровней), или текстур очень много, а может быть, они слишком большие по размеру. Но если приложение использует внеэкранные буферы, то получается вот так:

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

1x1 Scissor Rect — в этом режиме все пиксели, прошедшие пиксельную обработку, отбрасываются, не отрисовываясь. Если скорость в этом режиме сильно растёт, то основным упором производительности является скорость заполнения (филлрейт). Это может быть вызвано интенсивным альфа-блендингом, например.

Disable Texture Filtering — режим отключает использование текстурной фильтрации, в этом случае используется point sampling. Если в этом режиме отмечен большой рост FPS, то значит именно блоки текстурной фильтрации являются ограничивающим скорость фактором. К примеру, недостаточная производительность блоков фильтрации при включении анизотропной фильтрации может вызвать серьёзное падение производительности.

Disable Z-Test и Disable Z-Write — эти режимы используются для определения ограничений производительности, связанных с работой Z-буфера. При включении режима Disable Z-Test не используется определение глубины (depth test), а в Disable Z-Write результат сравнения не сохраняется в Z-буфере. Визуально это выражается в том, что некоторые невидимые объекты могут стать видимыми на экране.

Если эти режимы увеличивают производительность тестируемого 3D приложения, то это значит, что его скорость можно увеличить при использовании специальных методов отбрасывания невидимой геометрии (culling), выполняемых до depth test. Также скорость можно увеличить при использовании сортировки, когда ближайшие объекты отрисовываются первыми.

Disable Culling, Clockwise Culling и Counter-Clockwise Culling — режимы, связанные с разными методами отбрасывания невидимой геометрии. Обычно используется определённая ориентация для всех 3D объектов: по часовой стрелке, или против, в зависимости от порядка вершин. Это определяет направление нормали для всех примитивов, которые задают направление объектов к наблюдателю/камере.

Использование режимов Clockwise Culling и Counter-Clockwise Culling отменяет растеризацию всех примитивов, невидимых камере. Режим Disable Culling может вызвать снижение производительности, так как отрисовываются и видимые и невидимые стороны примитивов. Эти режимы полезны для определения проблемных мест при неверной отрисовке сцены.

Disable Alpha Blending — данный режим отключает альфа-смешивание (альфа-блендинг), и используется при определении того, является ли альфа-смешивание ограничителем производительности. Если режим вызывает значительный рост частоты кадров, то увеличить скорость рендеринга можно или уменьшением числа объектов, использующих смешивание, или использованием других техник.

Disable Alpha Test — использование режима отключения альфа-теста позволяет оценить его вклад в общую производительность аналогично предыдущему режиму. Визуально это получается так:

Overdraw Visualization — включение этого режима позволяет визуально оценить эффективность алгоритмов по отбрасыванию невидимой геометрии, а также общую сложность сцены. В этом режиме кадровый буфер заполняется чёрным цветом, а яркость каждого пикселя показывает количество записей по его координатам. Чем большее количество раз было записано значение в пиксель на экране, тем он светлее. Высокий уровень overdraw может указывать на слабую эффективность геометрических оптимизаций.

К сожалению, в некоторых случаях текущая реализация этого режима даёт сбой, так как не принимаются во внимание пиксели, записываемые во внеэкранные буферы, если такие поверхности используются как текстуры на два треугольника (quad) с размером не на весь экран.

Кроме списка счётчиков и диаграмм с данными, в окне System Analyzer отображается общее время тестирования и текущая частота кадров. Также есть возможность захвата данных для построения кадра, который в дальнейшем можно проанализировать в Frame Analyzer. Эта возможность существует в дополнение к отдельной утилите Frame Capture, служащей исключительно для захвата кадров.

Frame Capture

Утилита Frame Capture позволяет захватывать и записывать на диск все данные отдельных кадров, а также брать данные с тестовых машин с запущенной серверной частью GPA.

Для захвата кадра или нескольких при помощи GPA Frame Capture, нужно запустить GPA Remote Server на тестовой системе, а GPA Frame Capture на той, которой будет проводиться анализ. Достаточно указать IP адрес целевой машины, соединиться с серверной частью, выбрать приложение, которое будет запущено на тестовой системе.

Далее требуется всего лишь нажимать кнопку «Capture Frame» для захвата и сохранения отдельных кадров, анализируемых в дальнейшем в GPA Frame Analyzer.

Frame Capture предоставляет возможность удобного управления файлами с захваченными кадрами. Все захваченные и сохранённые на тестовой машине кадры будут указаны на соответствующей закладке «Manage». Их можно не только переименовывать и удалять, но и записывать на локальную машину, на которой запущен GPA Frame Capture. На этом описание функциональности утилиты можно закончить. Хотя она выполняет важную работу, но основное время разработчик потратит при анализе кадра в следующей утилите.

Frame Analyzer

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

Утилита для анализа построения кадров из пакета GPA работает с ранее захваченной информацией о кадре при помощи System Analyzer или Frame Capture. Сохранённый этими программами файл содержит всю необходимую информацию о том, какие вызовы отрисовки и в какой последовательности использовались во время рендеринга.

Утилита также является клиентской частью, которая подключается к серверной, запущенной на тестовом компьютере (по сети или локально). Сначала клиент и сервер обмениваются информацией о построении кадра. Затем, Frame Analyzer повторяет процесс рендеринга сцены и собирает подробные данные о производительности. При проведении экспериментов и других изменениях (шейдеры, состояние рендера и т.п.), утилита показывает разницу в производительности между оригинальным и изменёнными кадрами, отдельно по каждому из вызовов draw call, и в целом по кадру.

Процесс работы разработчика происходит примерно так: в Frame Analyzer загружается захваченный кадр, затем он анализируется, находятся «узкие» места, сильнее всего сказывающиеся на производительности, далее разработчик запускает различные эксперименты, изменяет состояния рендера, код шейдеров и т.п., находя пути повышения производительности.

Но это всё только на вид так просто, на самом деле в этом процессе и заключается задача оптимизации 3D приложения — найти и по возможности устранить места, на которые тратится больше всего ресурсов. И такие пакеты, вроде Intel GPA, сильно облегчают задачи программиста. Рассмотрим некоторые из возможностей, которые даёт анализ построения кадра.

При помощи Frame Analyzer можно узнать время, потраченное приложением на определённые участки построения сцены. Каждый из этих фрагментов состоит из некоторого количества вызовов функций D3D, они отображаются на главном графике.

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

Также очень удобно, что можно запускать определённые эксперименты (обходные режимы), как в System Analyzer, но уже для любых вызовов draw call по желанию. То есть, можно применить любой из доступных обходных режимов (2x2 Textures, 1x1 Scissor Rect, Simple Pixel Shader), или даже все сразу, либо для одного вызова отрисовки, либо для нескольких выделенных, что даёт большую гибкость.

Обходные режимы действуют аналогично тем, что мы рассматривали выше, они модифицируют состояние рендера так, чтобы выделить работу одной из стадий графического конвейера для определения узких мест. Модификации делаются видеодрайвером, поэтому приложение не догадывается об этих изменениях. И, так же как и в случае с System Analyzer, если при включении какого-либо из режимов производительность растёт сильно, то именно эта стадия 3D конвейера и ограничивает производительность. Все представленные режимы были рассмотрены нами выше, здесь они работают аналогично.

Есть и возможность модификации состояний DX (DX state). При неправильном рендеринге сцены можно попробовать изменить некоторые из состояний в процессе поиска ошибок, чтобы визуально определить, как изменённое состояние повлияет на итоговый результат. Доступно изменение состояний рендера (Render States), состояний сэмплера (Sampler States), и др.

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

Есть три возможности подмены шейдерного кода: выбор нового источника, ручное редактирование в окне Frame Analyzer, а также вставка кода из буфера обмена. Сделанные модификации остаются в силе даже при переходе к другим вызовам draw call. Код останется модифицированным до тех пор, пока не будет возвращен исходный при помощи кнопки «Revert All Changes» в основном окне.

При помощи Frame Analyzer можно найти и наиболее требовательные к пропускной способности текстурной памяти вызовы. Для этого нужно выделить требуемые фрагменты построения кадра, и ограничить использование самыми низкими мипуровнями текстуры при помощи ползунка «Clamp to Mip». Сцена перерисуется с меньшей детализацией, и можно будет оценить изменения времени, потраченного на отрисовку. Если это изменение серьёзно увеличивает производительность, значит, полоса пропускания текстурной памяти ограничивает скорость рендеринга, являясь «узким» местом. Также этой возможностью удобно пользоваться при определении оптимального размера текстуры, ведь на отрендеренном кадре можно сразу увидеть все сделанные изменения.

Подводя промежуточный итог, можно сказать, что Frame Analyzer является весьма удобным средством для отладки и оптимизации Direct3D приложений. Разработчики графических приложений, в частности игр, смогут сразу увидеть, какие вызовы draw call требуют больше времени для отрисовки, наглядно видеть используемые текстуры, буферы отрисовки, шейдерный код, и все вызовы Direct3D при построении кадра.

Важное достоинство Frame Analyzer в том, что разработчик может на лету запускать разные эксперименты и сразу же видеть результат от своих изменений, таких как редактирование кода шейдеров, изменения в мип-уровнях текстур, а также изменение состояний DX. И всё это — в реальном времени и с удобной визуализацией.

SDK и API

Нужно обратить внимание и на прилагаемый в комплекте GPA пакет для разработчика — Software Development Kit (SDK). Этот пакет помогает лучше использовать утилиты GPA так, как это нужно разработчику. SDK даёт возможность использования счётчиков производительности из собственных приложений, будь то 3D приложение или собственная утилита для тестирования 3D производительности.

GPA Core Services API предлагает API для профилирования графических приложений, и предоставляет следующие возможности: запуск и завершение работы GPA, запуск 3D приложения для анализа и профилирования, сбор данных со счётчиков GPU, CPU и D3D, использование обходных режимов, обработка ошибок, и пр. В комплекте SDK есть требуемые библиотеки, подключаемые файлы (include) и несколько примеров использования предлагаемого API.

Выводы

Пакет Intel Graphics Performance Analyzer предлагает очень удобные и проработанные утилиты для отладки 3D приложений, поиска причин низкой производительности, оптимизации кода и устранения ошибок. Используя возможности этого пакета, очень просто определить влияние каждой составляющей графического конвейера на общую производительность, и оптимизировать найденные проблемные места.

Возможности GPA значительно упрощают поиск таких проблемных мест, а программные и аппаратные счетчики производительности предоставляют весьма важную информацию о работе тестовой системы в 3D приложении. Также, SDK из пакета GPA позволяет использовать его возможности из своего приложения. В комплекте есть уже готовые наглядные и удобные инструменты по анализу Direct3D приложений, работающие в режиме реального времени.

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

К сожалению, у пакета есть и недостатки. Пока что поддерживаются исключительно D3D9 приложения, а поддержка следующих версий ожидается только в будущем. Но самым главным недостатком можно считать ограничение аппаратное. Что и говорить, интегрированные чипсеты никогда не отличались высокой производительностью, и не все разработчики захотят использовать такие системы, если это не предусмотрено системными требованиями их приложений.

Но уже сейчас GPA позволяет разработчикам оптимизировать их приложения для интегрированной графики производства компании Intel, а в будущем GPA будет поддерживать все выходящие у Intel графические продукты, в том числе, очень вероятно, и тот самый Larrabee. Отметим, что в будущих версиях GPA обещают добавить интересные и даже уникальные изменения, которые могут быть весьма полезными для разработчиков. Поэтому есть смысл начать использование пакета для разработчиков GPA 2.0 уже сейчас, чтобы потом плавно перейти на более производительные системы и к более функциональным версиям пакета.

Подведём итог. Набор утилит Intel Graphics Performance Analyzer будет очень полезен для разработчиков современных трехмерных приложений, использующих в своей работе Direct3D API. Утилиты из пакета помогут в решении большинства непростых вопросов, возникающих в процессе 3D разработки: определении узких мест в производительности, нахождении ошибок рендеринга, оптимальном использовании возможностей GPU и CPU, и многих других.





Дополнительно

iXBT BRAND 2016

«iXBT Brand 2016» — Выбор читателей в номинации «Процессоры (CPU)»:
Подробнее с условиями участия в розыгрыше можно ознакомиться здесь. Текущие результаты опроса доступны тут.

Нашли ошибку на сайте? Выделите текст и нажмите Shift+Enter

Код для блога бета

Выделите HTML-код в поле, скопируйте его в буфер и вставьте в свой блог.