Что такое отладка GPU
Обновлено: 21.11.2024
При диагностике проблем с производительностью полезно визуализировать перегрузку графического процессора. Это может показать вам, где Chrome может выполнять больше работы по рендерингу, чем необходимо, и помочь вам понять, где вы можете уменьшить накладные расходы на рендеринг.
Основной аудиторией этого инструмента являются разработчики Chrome, но его также можно использовать для диагностики проблем с производительностью веб-страниц.
Инструмент обратной связи с перерисовкой графического процессора, встроенный в Chrome, был вдохновлен функцией отладки перерисовки графического процессора, которая существует в Android, и разработчики, знакомые с этой функцией, будут чувствовать себя как дома, используя этот инструмент для улучшения пользовательского интерфейса Chrome или веб-страниц.
Чтобы визуализировать перерисовку графического процессора в Chrome, перейдите на страницу about:flags и включите эксперимент Показать отзыв о перерисовке. Если вы работаете в Chrome OS, также рекомендуется отключить эксперимент с частичной заменой, так как в этом случае результаты легче анализировать.
Если этот инструмент включен, он визуализирует перерисовку с помощью цветовой кодировки элементов интерфейса в зависимости от того, сколько элементов нарисовано под ними. Цвета элементов намекают на степень перерисовки на экране для каждого пикселя следующим образом:
Истинный цвет: без перерисовки
Синий: перерисовка один раз
Зеленый: перерасход дважды
Розовый: трижды превышено
Красный: превышено четыре или более раз
Пример вывода обратной связи о перегрузке графического процессора.
Некоторый перерасход неизбежен. Когда вы настраиваете свои элементы пользовательского интерфейса или веб-страницу, цель состоит в том, чтобы получить визуализацию, которая показывает в основном истинные цвета и 1X перерисовку синим цветом. Пользовательский интерфейс калькулятора, показанный выше, является примером нежелательной перегрузки графического процессора.
Примеры нежелательных и желательных выходных данных Debug GPU Overdraw.
Существует несколько стратегий, которые можно использовать для уменьшения или устранения перерасхода средств. Если вы работаете с пользовательским интерфейсом Chrome OS, обычно это сводится к использованию меньшего количества окон Aura с непрозрачностью, установленной на TRANSLUCENT. Для приложений Chrome и веб-страниц в целом, скорее всего, будут применяться следующие стратегии:
Если вы анализируете перегрузку графического процессора для анимации или создаете автоматические тесты производительности, может быть полезна обратная связь о перерисовке в виде событий трассировки. См. Инструмент профилирования событий трассировки (about:tracing) для получения дополнительных сведений о том, как записывать запуски трассировки. Включите категорию трассировки viz.overdraw, чтобы Chrome записывал объем перерисовки для каждого кадра. Результат представлен в виде счетчика перегрузки графического процессора, который со временем меняется по мере увеличения или уменьшения перегрузки.
Значение счетчика — это процент перерисовки в последнем представленном кадре. Отсутствие перерисовки для одной половины экрана и перерисовка в 1 раз для другой половины приводит к тому, что значение счетчика перегрузки графического процессора равно 50. Этот показатель доступен, только если доступен ARB_occlusion_query.
Вы можете отлаживать код C++, который выполняется на графическом процессоре (GPU). Поддержка отладки графического процессора в Visual Studio включает обнаружение гонок, запуск процессов и присоединение к ним, а также интеграцию в окна отладки.
Поддерживаемые платформы
Отладка поддерживается в Windows 7, Windows 8, Windows 10, Windows 11, Windows Server 2008 R2, Windows Server 2012 и Windows Server 2016. Для отладки в эмуляторе программного обеспечения, Windows 8, Windows 10, Windows 11 или Windows Требуется сервер 2012, Windows Server 2016. Для отладки на оборудовании необходимо установить драйвера для вашей видеокарты. Не все поставщики оборудования реализуют все функции отладчика. Информацию об ограничениях см. в документации поставщика.
Независимые поставщики оборудования, которые хотят поддерживать отладку графического процессора в Visual Studio, должны создать библиотеку DLL, реализующую интерфейс VSD3DDebug и предназначенную для их собственных драйверов.
Настройка отладки графического процессора
Отладчик не может сломать код процессора и код графического процессора в одном и том же приложении. По умолчанию отладчик останавливается на коде процессора. Для отладки кода графического процессора выполните один из следующих двух шагов:
В списке "Тип отладки" на стандартной панели инструментов выберите "Только GPU".
В обозревателе решений в контекстном меню проекта выберите «Свойства». В диалоговом окне "Страницы свойств" выберите "Отладка", а затем выберите "Только GPU" в списке "Тип отладчика".
Запуск и подключение к приложениям
Вы можете использовать команды отладки Visual Studio для запуска и остановки отладки графического процессора. Дополнительные сведения см. в разделе Навигация по коду с помощью отладчика. Вы также можете подключить отладчик графического процессора к запущенному процессу, но только если этот процесс выполняет код графического процессора. Дополнительные сведения см. в разделе Присоединение к запущенным процессам.
Переместить текущую плитку к курсору и запустить к курсору
При отладке на графическом процессоре у вас есть два варианта перехода к местоположению курсора. Команды для обоих вариантов доступны в контекстном меню редактора кода.
Команда Run to Cursor запускает ваше приложение до тех пор, пока оно не достигнет местоположения курсора, а затем прерывается.Это не означает, что текущий поток работает до курсора; скорее это означает, что первый поток, достигший точки курсора, инициирует прерывание. См. Навигация по коду с помощью отладчика
Команда Run Current Tile to Cursor запускает ваше приложение до тех пор, пока все потоки в текущей плитке не достигнут курсора, а затем прервется.
Отладка Windows
Используя определенные окна отладки, вы можете проверять, помечать и замораживать потоки графического процессора. Для получения дополнительной информации см.:
Исключения синхронизации данных
Отладчик может идентифицировать несколько условий синхронизации данных во время выполнения. При обнаружении условия отладчик переходит в состояние останова. У вас есть два варианта — Прервать или Продолжить. С помощью диалогового окна «Исключения» вы можете указать, будет ли отладчик обнаруживать эти условия, а также какие условия он будет прерывать. Дополнительные сведения см. в разделе Управление исключениями с помощью отладчика. Вы также можете использовать диалоговое окно «Параметры», чтобы указать, что отладчик должен игнорировать исключения, если записанные данные не изменяют значение данных. Дополнительные сведения см. в разделе «Общие», «Отладка», «Диалоговое окно параметров».
Устранение неполадок
Указание ускорителя
Точки останова в коде графического процессора срабатывают, только если код выполняется на ускорителе accelerator::direct3d_ref (REF). Если вы не укажете ускоритель в своем коде, ускоритель REF автоматически выбирается в качестве типа ускорителя отладки в свойствах проекта. Если ваш код явно выбирает ускоритель, то ускоритель REF не будет использоваться во время отладки, и точки останова не будут срабатывать, если ваше оборудование графического процессора не поддерживает отладку. Вы можете исправить это, написав свой код так, чтобы он использовал ускоритель REF во время отладки. Дополнительные сведения см. в разделах свойств проекта и Использование объектов accelerator и accelerator_view и параметров проекта для конфигурации отладки C++.
Условные точки останова
Условные точки останова в коде графического процессора поддерживаются, но не каждое выражение может быть вычислено на устройстве. Если выражение невозможно оценить на устройстве, оно вычисляется в отладчике. Отладчик, скорее всего, будет работать медленнее, чем устройство.
Ошибка: возникла проблема с конфигурацией выбранного типа ускорителя отладки.
Эта ошибка возникает при несоответствии между настройками проекта и конфигурацией ПК, на котором выполняется отладка. Дополнительные сведения см. в разделе Параметры проекта для конфигурации отладки C++.
Ошибка: Драйвер отладки для выбранного типа ускорителя отладки не установлен на целевой машине.
Эта ошибка возникает при отладке на удаленном ПК. Отладчик не может определить до времени выполнения, установлены ли драйверы на удаленном ПК. Драйверы можно получить у производителя видеокарты.
Ошибка: Обнаружение тайм-аута и восстановление (TDR) должны быть отключены на удаленном узле.
Вычисления C++ AMP могут превысить временной интервал по умолчанию, установленный процессом обнаружения и восстановления тайм-аута Windows (TDR). Когда это происходит, расчет отменяется и данные теряются. Дополнительные сведения см. в разделе Обработка TDR в C++ AMP.
Система графического процессора Chromium состоит из нескольких процессов, что может затруднить ее отладку. См. «Буфер команд графического процессора» для некоторых мелочей. Это всего лишь несколько замечаний, которые помогут при отладке.
Содержание
Код процесса визуализации
--enable-gpu-client-log
Если вы пытаетесь отследить ошибку в клиентском процессе графического процессора (композитинг, WebGL, Skia/Ganesh, Aura), то в отладочной сборке вы можете использовать флаг --enable-gpu-client-loging, который покажет каждый вызов GL, отправленный сервисному процессу графического процессора. (С точки зрения клиента GPU он вызывает функции OpenGL ES, но настоящие вызовы драйвера выполняются в процессе GPU.)
Вы также можете использовать этот флаг в сборке выпуска, указав аргумент GN:
Обычно также необходимо указать флаг --enable-logging=stderr:
Вывод выглядит следующим образом:
Проверка: GPU
Процесс GPU регистрирует множество ошибок и предупреждений. Вы можете увидеть их, перейдя к about:gpu . Журналы отображаются внизу страницы. Вы также можете увидеть их в стандартном выводе, если Chromium запускается из командной строки на Linux/Mac. В Windows вам потребуются инструменты отладки (такие как VS, WinDbg и т. д.) для подключения к выходному потоку отладки.
Примечание. Если about:gpu сообщает вам, что ваш графический процессор отключен и аппаратное ускорение недоступно, это может быть связано с тем, что ваш графический процессор не поддерживается. Чтобы переопределить это и в любом случае включить аппаратное ускорение, вы можете использовать параметр командной строки --ignore-gpu-blocklist при запуске Chromium.
Взлом при ошибке GL
В gles2_implementation.h есть такой код:
Маркировка звонков
Вывод всех ошибок, предупреждений и журналов отладки имеет префикс. Вы можете установить этот префикс, вызвав glPushGroupMarkerEXT, glPopGroupMarkerEXT и glInsertEventMarkerEXT. glPushGroupMarkerEXT добавляет строку в конец текущего префикса журнала (подумайте о пространстве имен в C++). glPopGroupmarkerEXT извлекает последнюю добавленную строку. glInsertEventMarkerEXT устанавливает суффикс для текущей строки. Пример:
Создание сокращенного тестового примера.
Часто можно создать простой сокращенный тестовый пример C++ только для OpenGL-ES-2.0, который относительно быстро компилируется и тестируется, путем добавления тестов в цель gl_tests. Эти тесты находятся в src/gpu/command_buffer/tests и являются частью сборки в src/gpu/BUILD.gn. Сборка с помощью ninja -C out/Debug gl_tests. Все те же параметры командной строки, перечисленные на этой странице, будут работать с gl_tests, плюс --gtest_filter=NameOfTest для запуска определенного теста. Обратите внимание, что тесты gl_test не являются многопроцессорными, поэтому они, вероятно, не помогут в условиях гонки, но они выполняют большую часть одного и того же кода, и их гораздо проще отлаживать.
Отладка процесса визуализации
В Linux это работает для меня:
В OSX это работает для меня:
В Windows я использую --renderer-startup-dialog, а затем подключаюсь к указанному процессу.
Примечание 1. В Linux и OSX я использую cgdb вместо gdb .
Примечание 2: GDB может занять несколько минут, чтобы проиндексировать символ. Чтобы сэкономить время, вы можете предварительно кэшировать эти вычисления, запустив build/gdb-add-index out/Debug/chrome .
Код процесса графического процессора
--enable-gpu-service-log
В отладочной сборке или выпускной сборке с dcheck_always_on=true в аргументе GN все фактические вызовы будут выводиться в драйвер GL.
Чтобы использовать его в сборках Release без dcheck_always_on = true, укажите аргумент GN enable_gpu_service_logging=true.
Для нерутированных устройств, на которых запущены рабочие сборки, мы не можем устанавливать флаги командной строки. Вместо этого используйте about://flags «Включить ведение журнала службы GPU».
Обратите внимание, что вызовы GL в драйвере в настоящее время не имеют префикса (todo?). Но из зарегистрированных команд вы можете сказать, какая команда и из какого контекста вызвали следующие вызовы GL.
Также обратите внимание, что идентификаторы клиентских ресурсов являются виртуальными идентификаторами, поэтому вызовы реального драйвера GL не будут совпадать (хотя некоторые команды распечатывают сопоставление). Примеры:
и т. д. так что вы можете видеть, что код процесса рендеринга будет использовать идентификаторы клиента, тогда как процесс графического процессора использует идентификаторы службы. Это полезно для сопоставления вызовов, если вы создаете дамп журналов GL клиента и службы.
--enable-gpu-debugging
В любой сборке будет вызываться glGetError после каждой команды
--enable-gpu-command-log
Это напечатает имя каждой команды графического процессора перед ее выполнением.
Отладка в процессе GPU
Учитывая многопроцессорность хрома, может быть сложно отлаживать обе стороны. Полезно включить ведение всех журналов и иметь небольшой тестовый пример. Одно небольшое предложение, если у вас есть некоторое представление о том, где происходит ошибка, вызов какой-то неясной функции gl, такой как glHint(), может дать вам место для перехвата команды, обрабатываемой в процессе GPU (поставьте точку останова на gpu::gles2 ::GLES2DecoderImpl::HandleHint . После этого вы можете следовать командам. Все они проходят через gpu::gles2::GLES2DecoderImpl::DoCommand .
Для отладки процесса графического процессора:
В Linux это работает для меня:
В OSX это работает для меня:
В Windows я использую --gpu-startup-dialog, а затем подключаюсь к указанному процессу.
ОШИБКА ГРАФИЧЕСКОГО ПАРСА
Отслеживание вызовов OpenGL
Передача флага командной строки --enable-gpu-service-tracing приводит к тому, что процесс графического процессора генерирует одно событие трассировки при каждом вызове API OpenGL. (См. «Производительность отладки» ниже.) Это полезно, когда вы пытаетесь понять, где находятся дорогостоящие операции в заданном наборе работы, отправленном из процесса визуализации в процесс графического процессора и обработанном под CommandBufferService::PutChanged .
Отладка производительности
Если у вас есть, что добавить сюда, добавьте это. Большая часть отладки производительности выполняется с использованием about:tracing (подробности см. в разделе Профилирование событий трассировки). В противном случае имейте в виду, что, поскольку система является многопроцессорной, вызов:
Набор инструментов разработчика Radeon™ включает в себя профилировщик графических процессоров Radeon™, визуализатор памяти Radeon™, анализатор графических процессоров Radeon™ и панель разработчика Radeon™ в одном удобном пакете.
GPU PerfStudio
Уделите больше времени написанию кода и меньше времени на отладку. GPU PerfStudio предоставляет разработчикам полный контроль за счет интеграции рабочего процесса. Выявляйте проблемы с производительностью и алгоритмами на ранних этапах цикла разработки и достигайте поставленных целей в области качества и производительности. GPU PerfStudio — это средство анализа и отладки производительности GPU второго поколения от AMD. Он предлагает разработчикам явные преимущества, сокращая время разработки программного обеспечения и улучшая качество графики.Читайте дальше, чтобы узнать больше, или нажмите, чтобы перейти к загрузкам.
Встроенные инструменты
GPU PerfStudio объединяет пять инструментов, которые являются ключевыми для современного разработчика графики. Отладчик фреймов, который позволяет визуализировать состояние графики и ресурсы в вашем фрейме, профилировщик фреймов, который позволяет выявлять проблемы производительности каждого вызова отрисовки на уровне аппаратного счетчика, отладчик шейдеров, который позволяет вам выполнять и отлаживать код шейдера. и его вывод, окно трассировки API со встроенной информацией о времени ЦП и анализатор шейдеров для оптимизации кода шейдера. На этом снимке экрана (щелкните изображение, чтобы увеличить его) показаны одновременно используемые Frame Profiler и Frame Debugger. В этом сценарии профилировщик использовался для идентификации дорогостоящего вызова отрисовки. Вызов отрисовки был выбран в синем списке справа, в результате чего отладчик фреймов перешел к этому вызову отрисовки. Буфер вершин и индексов, ресурсы текстуры и буфер глубины для этого вызова отрисовки в настоящее время отображаются. Код пиксельного шейдера можно пройти пошагово, тщательно изучив взаимосвязь между кодом и активами, чтобы выявить дорогостоящие аспекты шейдера.
Читайте также: