Инструменты и советы по отладке для интегрированных графических адаптеров серий 3000 и X3000

 

Решить проблемы при работе с интегрированными графическими адаптерами Intel® окажется проще, если понимать некоторые самые основные принципы и уметь применять инструменты, которые имеются в распоряжении разработчиков программного обеспечения. Все методы, описанные в данном документе, просты в использовании и позволяют портировать, отлаживать и разрабатывать код для интегрированных графических адаптеров так же легко, как и для любого другого современного графического оборудования.

 

Прежде всего, необходимо помнить, что Intel выпускает два типа решений для интегрированных графических адаптеров: серии 3000 и X3000. Как и для более ранней линейки GMA 900 компании Intel, для серии 3000 операции преобразования и освещения (Transform and Lighting, TnL) выполняются программно (на ЦП) с помощью графического конвейера для процессора (Processor Specific Graphics Pipeline, PSGP) в слое HAL Direct3D. В серии X3000 операции TnL частично выполняются аппаратно, в зависимости от требований приложения. Некоторые приложения, например основанные на DirectX версии 8 или более ранней, лучше подходят для обработки ЦП-PSGP, чем для конвейера DirectX9 в механизме серии X3000.

 

 

В течение нескольких последних лет одним из самых полезных средств может считаться инструмент 3dAnalyze сторонних производителей (см. рис. 1).

 

Рис. 1. Инструмент 3DAnalyze

 

Первое, что делают инженеры Intel при тестировании приложения, которое не работает с графическими адаптерами серии 3000, — проверяют, поддерживает ли это приложение программное выполнение TnL. Возможно, приложение рассчитано на аппаратное выполнение TnL, которое адаптеры серии 3000 не поддерживают. Инструмент 3DAnalyze* имеет много полезных функций, одна из которых состоит в том, чтобы заставить приложение "поверить", что графическая карта поддерживает аппаратное выполнение TnL. Разработчик просто устанавливает флажок emulate HW TnL caps (Эмуляция аппаратную поддержку TnL) (см. верхнюю часть рис. 1), а затем выполняет приложение непосредственно из 3dAnalyze. Если проблема возникает из-за того, что приложение не распознает программное выполнение TnL, это сразу станет понятно. Если же приложение нормально работает в режиме аппаратной эмуляции TnL, значит, имеет место проблема игры, связанная с программной поддержкой TnL.

 

Другой тест состоит в том, чтобы обеспечить программную поддержку TnL в 3DAnalyze при наличии установленной аналогичной графической карты среднего уровня. Если приложение по-прежнему не работает, значит, проблема не имеет отношения к графической карте или драйверу Intel: это проблема игры, связанная с программной поддержкой TnL. Если же приложение работает нормально, проблема, возможно, связана с ошибкой драйвера Intel, и о ней необходимо сообщить на форуме разработки программного обеспечения для интегрированных графических адаптеров Intel (расположенном здесь) и на веб-узле поддержки графических адаптеров компании Intel.

 

Кроме того, в 3dAnalyze* можно установить флажок "debug logging" (Ведение журнала отладки). После этого при тестировании приложения в его каталоге или папке будет создан файл журнала. Если в файле отладки появляются следующие записи: D3DCREATE_PUREDEVICE или D3DCREATE_HARDWARE_VERTEXPROCESSING, но нет записи D3DCREATE_SOFTWARE_VERTEXPROCESSING, приложение не будет работать с графическим адаптером серии 3000. Такие записи означают, что разработчик приложения Direct3D* не включил в него поддержку программной обработки вершин.

 

Если приложение не предназначено для работы именно с графическими адаптерами Intel, это тоже можно выяснить с помощью 3dAnalyze*. Для этого нужно явно указать код производителя и устройства той графической карты, с которой приложение точно работает. Для этой цели в 3dAnalyze* имеются специальные поля. Материал под названием "Распространенные заблуждения в области интегрированных графических адаптеров Intel" в сети Intel® Software должен помочь развеять любые сомнения разработчика по поводу возможностей интегрированных графических адаптеров Intel.

 

Если есть основания предполагать, что приложение имеет ограниченную скорость отрисовки, в 3dAnalyze можно установить флажок "disable textures" (Отключить текстуры). Этот способ чаще применяется для тестов производительности, чем для игр, но при необходимости его можно использовать. Он позволяет эффективно удалять из системы текстуры, уменьшая тем самым затраты ресурсов на отрисовку.

 

Если можно предположить, что приложение работает медленнее из-за низкой производительности построителя текстуры, с помощью 3dAnalyze* можно сделать так, чтобы приложение по умолчанию использовало более раннюю версию (например, 1.1).

 

Этот метод может оказаться полезным при отладке построителей текстуры с интегрированными графическими адаптерами Intel.

 

 

Сначала необходимо выяснить, какие компоненты поддерживает данный интегрированный графический адаптер. Для этого предназначено средство DX Caps viewer, которое входит в состав пакета Direct X SDK (в папке Utilities). Выходные сообщения при отладке сразу станут более понятными. Свойства нужного адаптера можно найти в папке <Устройство>->D3D Device Types (Типы устройств D3D)->HAL (Слой HAL)->Caps (Свойства). Особенности каждого свойства описаны в документации пакета Direct X SDK.

 

Один из самых полезных методов решения проблем, связанных с Direct3D*, состоит в том, чтобы вначале включить режим отладки Direct3D*. Прежде всего необходимо убедиться, что в системе установлен самый последний пакет DirectX 9.0 SDK* (его можно загрузить с веб-узла Microsoft бесплатно). Обычно этот пакет обновляется раз в два месяца. Чтобы включить режим отладки, нужно перейти к панели управления Direct X, которую можно найти в папке Utilities пакета SDK.

 

В этом режиме можно использовать такие инструменты как DebugView* или DebugMon*, чтобы записать сообщения об ошибках и понять, в какой момент возникает ошибка работы того или иного приложения. После окончания тестирования необходимо переключиться из режима отладки в обычный режим. Не рекомендуется использовать средства 3dAnalyze* или FRAPS*, когда включен режим отладки или выполняется переключение режимов, поскольку при этом возникает конфликт (эти средства тоже переходят в режим отладки).

 

 

Следует отметить, что инструмент PIX подходит только для приложений на основе Direct3D. Для приложений OpenGL* можно использовать glIntercept. В этой статье описывается только работа с PIX*. Это мощный инструмент, который помогает решить проблемы с производительностью, позволяя взглянуть на отдельные видеокадры или их последовательность. Являясь, фактически, построителем DirectX, отладчик переходит от кадра к кадру, позволяя оценить входные и выходные данные. Такая информация может пригодиться любому разработчику.

 

На рис. 2 показан стартовый экран настройки для отладки приложения с помощью PIX.

 

 

Рис. 2. Microsoft PIX

 

В расширенном режиме просмотра можно выбрать дополнительные параметры. Константы построителя и блокировки этих констант — хороший индикатор, который показывает, какие факторы ограничивают производительность. Кроме того, полезно взглянуть на число вызовов SetRenderTarget на один кадр. Если выполняется больше одного такого вызова на один видеокадр, это может влиять на производительность, а если таких вызовов больше 10 на один видеокадр, снижение производительности в случае интегрированных графических адаптеров Intel может быть очень значительным.

 

Самый полезный способ получения нужных сведений состоит в том, чтобы записать отдельный видеокадр или их последовательность в файл, зашифровать его и направить на веб-узел /en-us/forums/user-community-for-intel-graphics-technology. Обычно файлы PIX с записью одного видеокадра или их последовательности используются для отладки после аварийного завершения приложения. Такие файлы имеют одинаковое расширение: .PIXRun. Чтобы обсудить результаты, полученные с помощью PIX, в сообществе разработчиков Intel, лучше всего зашифровать эти файлы и передать сообществу. Следует помнить, что образцы потока видеокадров, полученные с помощью PIX, могут иметь очень большой размер, поэтому нужно выбирать самые показательные фрагменты, которые лучше всего помогут прояснить общую картину.

 

Рекомендуется всегда использовать самую последнюю версию PIX. Этот инструмент обновляется регулярно. Еще одна возможность, которую он предоставляет, — это захват отдельного кадра (на этапе рендеринга). Выбор собственно инструмента (PIXWIN*) — это прием, к которому многие разработчики прибегают, чтобы избежать выполнения операций, не относящихся к рендерингу. Для этого достаточно воспользоваться параметром командной строки : "–playstandalone <имя>.pixrun". Этот способ гораздо больше подходит для приложений, создающих большую нагрузку (а именно, для тестов производительности и для игр), но его можно использовать и для менее объемных задач.

 

Чтобы понять, почему приложение не работает, очень важно записать в файл последовательность кадров, но и захват отдельных видеокадров тоже может оказаться полезным. Если записанную последовательность видеокадров можно воспроизвести с помощью графического процессора, отличного от Intel, вероятно, в драйвере Intel имеется ошибка. Она сразу привлечет внимание группы разработки драйверов графического адаптера и, возможно, будет исправлена в следующей версии драйвера. Чтобы выполнить захват потока, достаточно выбрать параметр "Call replayable stream" (Записать поток с возможностью воспроизведения) в эксперименте.

 

Существует еще один способ оптимизации, который заключается в том, чтобы применять вместо списков треугольников ленты треугольников. Это позволяет использовать буфер вершин менее интенсивно. Обычно это делается с помощью средств создания содержимого, таких как Maya или 3D studio max. Это общий совет по оптимизации, который улучшает работу кода на всех графических адаптерах.  

 

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

 

 

Чак ДеСильва — технический руководитель в области приложений в группе решений и программного обеспечения компании Intel. Он и его группа отвечают за оптимизацию производительности самого современного клиентского программного обеспечения на настольных системах Intel. Прежде чем перейти к оптимизации программного обеспечения, Чак занимался разработкой драйверов в корпорации Intel. Он принимал участие в разработке и развертывании первых драйверов для устройств USB и AGP (GART), а также для первых графических адаптеров Intel (i740/810(e)).