Про приложения DirectX

Здесь показано, как измерить некоторые из наиболее важных показателей производительности для приложения DirectX с помощью средств XPerf и GPUView , которые поставляются в составе набора средств для повышения производительности Windows. Это не исчерпывающее руководство по пониманию инструментов, скорее их применимость для анализа производительности приложений DirectX. Хотя большинство методов, описанных здесь, относятся ко всем приложениям DirectX, они наиболее актуальны для приложений, использующих цепочки буферов, а не для приложений DirectX, созданных на XAML, которые используют анимации SIS/VSIS и XAML. Мы рассмотрим ключевые измерения времени производительности, как получить и установить средства, а также провести трассировки измерения производительности, а затем проанализировать их, чтобы понять узкие места приложений.

Сведения об инструментах

XPerf

XPerf — это набор средств анализа производительности, созданных на основе трассировки событий Windows (ETW), предназначенных для измерения и анализа подробных сведений о производительности системы и приложений и использовании ресурсов. Начиная с Windows 8 это средство командной строки имеет графический пользовательский интерфейс и называется Windows Performance Recorder (WPR) и Windows Анализатор производительности (WPA). Дополнительные сведения об этих средствах можно найти на веб-странице windows Performance Toolkit (WPT): Набор средств для повышения производительности Windows.

Трассировка событий Windows собирает запрошенные события ядра и сохраняет их в файл, называемый файлом журнала трассировки событий (ETL). Эти события ядра предоставляют подробные сведения о приложении и характеристиках системы при запуске приложения. Данные собираются путем включения отслеживания трассировки, выполнения требуемого сценария приложения, требующего анализа, остановки записи, которая сохраняет данные в ETL-файле. Затем можно проанализировать файл на том же или другом компьютере с помощью программы командной строки xperf.exe или средства анализа визуальной трассировки xperfview.exe.

GPUView;

GPUView — это средство разработки для определения производительности графического процессора (GPU) и ЦП. Он оценивает производительность обработки буфера прямого доступа к памяти (DMA) и всех других операций обработки видео на видео аппаратном обеспечении.

Для приложений DirectX , которые в значительной степени зависят от GPU, GPUView — это мощный инструмент для понимания взаимосвязи между работой, выполняемой на ЦП и GPU. Дополнительные сведения о GPUViewсм. в разделе Использование GPUView.

Как и xPerf, трассировка событий Windows сначала выполняется путем запуска службы трассировки, реализации сценария, который требует анализа для рассматриваемого приложения, остановки службы и сохранения информации в ETL-файле. GPUView представляет данные, присутствующие в ETL-файле, в графическом формате.

После установки средства GPUView рекомендуется ознакомиться с разделом "Основной дисплей GPUView" в меню "Справка ПО GPUView ". Он содержит полезные сведения о том, как интерпретировать пользовательский интерфейс GPUView .

Установка средств

XPerf и GPUView включены в набор средств производительности Windows (WPT).

XPerf поставляется в составе пакета средств разработки программного обеспечения Windows (SDK) для Windows. Скачайте windows SDK.

GPUView доступен в комплекте средств для развертывания и оценки Windows (Windows ADK). Скачайте Windows ADK.

После установки необходимо добавить каталоги, содержащие XPerf и GPUView , в системную переменную Path.

Нажмите кнопку Пуск и введите "Системные переменные". Откроется окно свойств Система. Щелкните "Изменить системные переменные среды". Выберите "Переменные среды" в диалоговом окне "Свойства системы". Переменная Path находится в разделе "Системные переменные". Добавьте в путь каталог , содержащийxperf.exe и GPUView.exe . Эти исполняемые файлы находятся в каталоге "Наборы средств производительности Windows". Расположение по умолчанию: C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit.

Измерения времени производительности

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

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

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

Ниже перечислены некоторые из наиболее распространенных метрик времени производительности.

Время запуска

Время, измеряемое с момента запуска процесса до первого попадания на экран. Это измерение более полезно, если система теплая, то есть измерение выполняется после запуска приложения несколько раз.

Время ЦП на кадр

Время, в течение которого ЦП активно обрабатывает рабочую нагрузку приложения для одного кадра. Если приложение работает гладко, вся обработка, необходимая для одного кадра, выполняется в течение одного интервала виртуальной синхронизации. При частоте обновления монитора 60 Гц это составляет 16 мс на кадр. Если время/кадр ЦП больше 16 мс, может потребоваться оптимизация ЦП, чтобы создать сбой бесплатного приложения.

Время GPU на кадр

Время, в течение которого GPU активно обрабатывает рабочую нагрузку приложения для одного кадра. Приложение привязано к GPU, когда время, затраченное на обработку данных кадра, превышает 16 мс.

Возможность понять, привязано ли приложение к ЦП или GPU, сузит проблемную часть кода.

Выполнение трассировки измерения времени производительности

Выполните следующие действия, чтобы выполнить трассировку:

1. Откройте командное окно от имени администратора.
2. Закройте приложение, если оно уже запущено.
3. Перейдите в каталог gpuview в папке Windows Performance Toolkit.
4. Введите log.cmd, чтобы начать трассировку событий. Этот параметр регистрирует наиболее интересные события. Другие доступные параметры регистрируют различные область событий. Например, режим "v" или режим подробного журнала фиксирует все события, о которых известно GPUView .
5. Запустите пример и выполните его таким образом, чтобы он охватывал путь к производительности, который необходимо проанализировать.
6. Назад в командные окна и снова введите log.cmd, чтобы остановить ведение журнала.
7. При этом в папку gpuview выводится файл с именем "merged.etl". Вы можете сохранить этот файл в другом расположении и проанализировать его на том же или другом компьютере. Чтобы просмотреть сведения о захвате стека, сохраните файл символов (PDB), связанный с приложением.

Измерения

Примечание

Измерения для примера реализации геометрии выполняются на компьютере с четырьмя ядрами с интегрированной графической карта DirectX11. Измерения зависят от конфигурации компьютера.

 

В этом разделе показано, как измерять время запуска, время ЦП и GPU для каждого кадра. Вы можете записать трассировку производительности для одного и того же примера на компьютере и увидеть различия в различных измерениях.

Чтобы проанализировать трассировку в GPUView, откройте файл merged.elt, используя GPUView.exe.

Время запуска

Время запуска измеряется общим временем, затраченным с момента запуска приложения до первого появления содержимого на экране.

Измерение времени запуска лучше всего выполнить, выполнив действия, описанные в предыдущем разделе со следующими вариантами:

• Если вы принимаете измерения запуска при первом запуске приложения, это называется холодным запуском. Это может отличаться от измерений, сделанных после запуска приложения несколько раз в течение небольшого периода времени. Это называется теплым запуском. В зависимости от количества ресурсов, создаваемого приложением при запуске, между двумя запусками может быть большая разница. В зависимости от целей приложения может потребоваться измерение того или иного.
• При регистрации сведений о производительности завершите работу приложения, как только на экране появится первый кадр.

Вычисление времени запуска с помощью GPUView

1. В GPUView прокрутите вниз до соответствующего процесса, в данном случае GeometryRealization.exe.

   

2. Контекстная очередь ЦП представляет собой рабочую нагрузку графики, поставленную в очередь на оборудование, но не обязательно обрабатывается оборудованием. При открытии файла трассировки отображаются все события, зарегистрированные между моментом выполнения трассировки. Чтобы вычислить время запуска, выберите интересующую область, увеличьте начальную часть первой очереди ЦП контекста (которая показывает активность) с помощью клавиш CTRL+Z. Дополнительные сведения об элементах управления GPUView можно найти в разделе "Сводка элементов управления GPUView". На рисунке ниже показан только GeometryRealization.exe процесс, увеличенный до первой части очереди ЦП контекста. Цвет очереди ЦП контекста обозначается прямоугольником прямо под очередью, и в пакетах данных того же цвета в очереди отображается работа GPU, поставленная в очередь на оборудовании. Пакет шаблона хэтча в очереди контекста показывает настоящий пакет. Это означает, что приложение хочет, чтобы оборудование вело отображать содержимое на экране.

   

3. Время запуска — это время первого запуска приложения (в данном случае модуль точки входа потока пользовательского интерфейса SHCORE.dll) до момента первого появления контекста (помеченного пакетом штриховки). На рисунке здесь выделена интересующая область.

   Примечание

   Фактические представленные сведения представлены в очереди пролистывания, и, таким образом, время увеличивается до фактического завершения текущего пакета в очереди пролистывания.

    

   Полная строка состояния не отображается на рисунке ниже, где также показано затраченное время между выделенными частями. Это время запуска приложения. В этом случае для машины, упомянутой выше, он вышел около 240 мс.

   

Время ЦП и GPU на кадр

При измерении времени ЦП необходимо учитывать несколько моментов. Найдите области трассировки, в которых вы выполнили сценарий для анализа. Например, в примере реализации геометрии одним из проанализированных сценариев является переход между отрисовкой примитивов 2048 и 8192, все нереализованные (например, геометрия не тесселлирована для каждого кадра). Трассировка четко показывает разницу в активности ЦП и GPU до и после перехода в количестве примитивов.

Анализируются два сценария для вычисления времени ЦП и GPU на кадр. Они являются следующими.

• Переход отрисовки 2048 нереализованных примитивов к 8192 нереализованным примитивам.
• При переходе отрисовки 8192 реализованы примитивы к нереализованным примитивам 8192.

В обоих случаях было замечено, что частота кадров резко снизилась. Измерение времени ЦП и GPU, связь между ними, а также несколько других шаблонов в трассировке могут дать полезные сведения о проблемных областях в приложении.

Вычисление времени ЦП и GPU при нереализации примитивов 2048

1. Откройте файл трассировки, используя GPUView.exe.

2. Прокрутите вниз до GeometryRealization.exe процесса.

3. Выберите область для вычисления времени ЦП и увеличьте ее с помощью клавиш CTRL+Z.

   

4. Отображение сведений о виртуальной синхронизации путем переключения между F8. Сохраняйте масштабирование, пока не будет легко увидеть данные одной виртуальной синхронизации. Синие линии — это время виртуальной синхронизации. Как правило, они происходят каждые 16 мс (60 кадров/с), но если DWM сталкивается с проблемой производительности, он выполняется медленнее, поэтому они будут происходить каждые 32 мс (30 кадров/с). Чтобы получить представление о времени, выберите от одной синей панели к следующей, а затем посмотрите на количество мс в правом нижнем углу окна GPUView .

   

5. Чтобы измерить время ЦП на кадр, измерьте продолжительность времени, затраченного всеми потоками, участвующими в отрисовке. Возможно, стоит сузить поток, который, как ожидается, будет наиболее актуальным с точки зрения производительности. Например, в примере реализации геометрии содержимое анимируется и должно отображаться на экране каждый кадр, что делает поток пользовательского интерфейса важным. Определив, на какой поток следует обратить внимание, измерьте длину отрезков в этом потоке. В среднем некоторые из них дают время ЦП на кадр. На рисунке ниже показано время, затраченное на поток пользовательского интерфейса. Он также показывает, что это время хорошо подходит между двумя последовательными v-синхронизациями, что означает, что он достигает 60FPS.

   

   Вы также можете проверить, просмотрев очередь пролистывания для соответствующего временного интервала, который показывает, что DWM может представить каждый кадр.

   

6. Время GPU можно измерить так же, как и время ЦП. Увеличьте масштаб соответствующей области, как в случае измерения времени ЦП. Измерьте длину отрезков в очереди оборудования GPU с тем же цветом, что и у очереди ЦП контекста. Пока полосы помещаются в последовательных виртуальных синхронизациях, приложение работает без проблем со значением 60FPS.

   

Вычисление времени ЦП и GPU, когда примитивы 8192 отображаются нереализованными

1. Если выполнить те же действия снова, трассировка показывает, что вся работа ЦП для одного кадра не помещается между одной виртуальной синхронизацией и следующей. Это означает, что приложение привязано к ЦП. Поток пользовательского интерфейса насыщает ЦП.

   

   При просмотре очереди пролистывания становится также ясно, что DWM не может представить каждый кадр.

   

2. Чтобы проанализировать, на что тратится время, откройте трассировку в XPerf. Чтобы проанализировать время запуска в XPerf, сначала найдите интервал времени в GPUView. Наведите указатель мыши на левую часть интервала и вправо и запишите абсолютное время, показанное в нижней части окна GPUView . Затем откройте тот же ETL-файл в XPerf и прокрутите вниз до диаграммы "Выборка ЦП по ЦП", щелкните правой кнопкой мыши и выберите "Выбрать интервал..." Это позволяет вводить текст в интересующем интервале, который был обнаружен при просмотре трассировки GPU.

   

3. Перейдите в меню Трассировка и убедитесь, что установлен флажок "Загрузить символы". Кроме того, перейдите в раздел Трассировка —> настройка путей символов и введите путь к символу приложения. Файл символов содержит отладочную информацию о скомпилированном исполняемом файле в отдельной базе данных (PDB). Этот файл обычно называется PDB. Дополнительные сведения о файлах символов можно найти здесь: Файлы символов. Этот файл может находиться в папке "Отладка" каталога приложения.

4. Чтобы получить разбивку по времени в приложении, щелкните правой кнопкой мыши интервал, выбранный на предыдущем шаге, и выберите Сводная таблица. Чтобы получить общие сведения о том, сколько времени тратится на каждую библиотеку DLL, снимите флажок "Стек" в меню "Столбцы". Обратите внимание, что в столбце "Число" показано, сколько примеров находится в заданной библиотеке dll/функции. Так как на мс берется примерно одна выборка, это число можно использовать в качестве оптимального представления о том, сколько времени затрачено на каждую библиотеку dll/функцию. Проверка "Стек" в меню Столбцы даст инклюзивное время, затраченное на каждую функцию в графе вызовов. Это поможет далее разбить проблемные точки.

5. Данные трассировки стека для нереализованных примитивов 2048 показывают, что 30 % времени ЦП тратится на реализацию геометрии. Из этого около 36% времени тратится на тесселяции геометрии и поглаживания.

6. Данные трассировки стека для нереализованных примитивов 8192 показывают, что около 60 % времени ЦП (4 ядра) тратится на реализацию геометрии.

   

Вычисление времени ЦП при реализации примитивов 8192

Из профилей видно, что приложение привязано к ЦП. Чтобы сократить время, затрачиваемое ЦП, геометрические данные можно создать один раз и кэшировать. Кэшированное содержимое можно визуализировать каждый кадр без затрат на тесселяции геометрии для каждого кадра. При просмотре трассировки в GPUView для реализованной части приложения видно, что DWM может представить каждый кадр, а время ЦП значительно сократилось.

В первой части графа показаны реализованные 8192 примитива. Соответствующее время ЦП на кадр может поместиться в пределах двух последовательных виртуальных синхронизаций. В более поздней части графа это не так.

Если взглянуть на XPerf, ЦП находится в состоянии простоя в течение длительного времени, и только около 25 % времени ЦП тратится на приложение для реализации геометрии.

Сводка

GpuView и XPerf, а также мощные средства для анализа производительности приложений DirectX. В этой статье приведены основные сведения об использовании этих средств и базовых измерениях производительности и характеристиках приложений. Помимо понимания использования инструментов, сначала важно понять, как анализируется приложение. Начните с поиска ответов на такие вопросы, как что приложение пытается достичь? Какие потоки в системе наиболее важны? Какие компромиссы вы готовы сделать? При анализе трассировок производительности начните с просмотра очевидных проблемных мест. Привязан ли ЦП или GPU приложения? Может ли приложение представить каждый кадр? Средства вместе с пониманием приложения могут дать очень полезную информацию для понимания, поиска и, наконец, решения проблем с производительностью.