Библиотека Mesa и ее отладка

Эта статья посвящена графической библиотеке Mesa 3D и нескольким доступным для всех разработчиков инструментам, которые позволяют производить отладку игр, разработанных или портированных под Linux. Также тут мы рассмотрим платформу Steam и ее возможности по отладке.

Довольно часто бывают ситуации, когда баги, возникающие в играх под Linux, разработчики чинить не хотят. Это происходит по ряду причин, в частности, из-за малого числа пользователей и отсутствия коммерческой заинтересованности. Эти баги могут относиться как к самой игре, так и к библиотеке Mesa или драйверам. Мы рассмотрим инструментарий, с помощью которого можно устранить проблемы на каждом уровне (кроме уровня игр, исходники которых закрыты).

Библиотека Mesa: основные факты

Библиотека Mesa — это open-source проект, реализующий графические стандарты OpenGL и Vulkan. Это достаточно старый проект: ему около 25 лет. После выхода первой спецификации OpenGL программист по имени Брайан Пол (Brian Paul) разработал первую реализацию библиотеки. Библиотека Mesa не сертифицирована Cronos Group (объединение компаний, которые разработали OpenGL-интерфейс и которые занимаются сертификацией), поэтому поддерживается силами open-source сообщества.

Тем не менее, сейчас Mesa используется во всех дистрибутивах Linux. Библиотека поддерживает все современные графические ускорители и работает на нескольких операционных системах (Linux, Windows и MacOS).

Поддерживаемое аппаратное обеспечение

Mesa может работать с графическими ускорителями почти всех современных производителей, таких как AMD, Nvidia, Intel, Broadcom, Qualcomm, Vivante и другими. Наиболее активными участниками разработки библиотеки являются компании Intel и AMD. Поддержка для Nvidia в основном ведется open-source разработчиками.
Помимо аппаратных реализаций, существуют еще и программные, где весь рендеринг выполняется непосредственно на центральном процессоре.

Ниже представлены некоторые из них:

• llvmpipe — использует llvm-компилятор — трансляцию кода «на лету»; может компилировать шейдеры непосредственно в x86 code, тем самым ускоряя процесс отрисовки.
• Softpipe — программный драйвер Gallium.
• Swrast — драйвер, который был реализован в Mesa изначально. В данный момент практически не используется.

Поддержка стандарта OpenGL и его расширений

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

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

На рисунке представлена поддержка различными hardware и software отрисовщиками стандарта OpenGL и его расширений:

Актуальные данные о поддержке расширений можно посмотреть здесь.

Процесс разработки

Mesa — это открытый проект: все её исходники можно скачать. Существует открытая Bugzilla, в которой силами сообщества регистрируются все найденные баги. Например, если во время игры у вас возникают проблемы с отрисовкой, вы можете регистрировать новые баги. После регистрации бага его обычно берёт в работу разработчик, но это происходит не всегда. Иногда баги могут находиться в системе по несколько лет: в основном это достаточно специфические проблемы, для решения которых необходимо приобретение платного проприетарного ПО (например, программ по 3D-моделированию) или использование специфического/устаревшего процессора.

Далее, если разработчик занялся проблемой, он решает ее и выкладывает решение в mailing thread. Подход примерно такой же, как в ядре Linux — патч с помощью команды git send-email высылается в сообщество, где проходит процесс review.

Средства отладки

Mesa Environment Variables

Mesa предоставляет набор переменных окружения, позволяющих изменить поведение библиотеки, включить дополнительную debug информацию и т. д. Один из таких примеров — переменная LIBGL_ALWAYS_SOFTWARE. Если присвоить ей значение 1, то по умолчанию будет использоваться софтверный рендеринг, несмотря на наличие в системе графического ускорителя. Проверить результат можно с помощью утилиты glxinfo — информационного инструмента, с помощью которого можно посмотреть, какой конкретный драйвер используется в данный момент, какая у него поддержка OpenGL и т. д.:

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

Ниже представлена пошаговая инструкция дампа шейдеров с последующим их изменением.

Шаг 1

Создаем директорию shaders для хранения шейдеров и еще две дополнительные директории read и dump:

# mkdir shaders
# mkdir shaders/dump && mkdir shaders/read

Шаг 2

Экспортируем переменные окружения:

# export MESA_SHADER_DUMP_PATH=shaders/read
# export MESA_SHADER_READ_PATH=shaders/dump

Шаг 3

В этом же терминале запускаем приложение, чтобы записать шейдеры, которые используются приложением:

Шаг 4

Копируем шейдеры из директории dump в директорию read и делаем необходимые изменения. При следующем запуске приложения Mesa будет использовать измененные шейдеры из директории read вместо оригинальных.

Утилита Apitrace

С помощью утилиты apitrace вы можете записывать и воспроизводить вызовы OpenGL, сделанные из приложения, и всю графическую информацию, передаваемую через OpenGL (исходный код шейдеров, текстуры и т. д.). Все данные записываются в трейс файл. Далее, с помощью той же утилиты, можно проиграть полученный трейс файл и полностью восстановить процесс отрисовки графики приложения. Подобный подход применяется при отладке коммерческих приложений и платных игр. Пользователи могут записывать трейс файлы, которые будут использованы разработчиками во время отладки. Найденный баг можно записать с помощью apitrace, опубликовать в баг треккере, и любой разработчик сможет воспроизвести его на своем компьютере и попытаться устранить этот баг, не покупая игру.

Утилита Frameretrace

Утилита Frameretrace базируется Apitrace, но также предоставляет графический интерфейс пользователя и более продвинутую функциональность. Она была разработана в компании Intel командой разработчиков под руководством Марка Джейнса (Mark James) путем модификации Apitrace. Главным отличием Frameretrace является возможность разбиения фрейма на отдельные элементы рендеринга и просмотра используемых шейдеров и вызовов OpenGL. Утилита позволяет изменять шейдеры и OpenGL вызовы с последующей отрисовкой фрейма. При внесении изменений в Apitrace необходимо проигрывать все фреймы сначала, а Frameretrace позволяет перерисовывать конкретные фреймы. Кроме того, Frameretrace позволяет подсветить все области на фрейме, за которые отвечал определенный шейдер и определенные вызовы GL.

Утилита Renderdoc

Renderdoc — одна из наиболее распространенных и продвинутых утилит, которые сейчас используются в игровой индустрии. Поддерживает OpenGL, OpenGL ES, Vulkan, D3D11, D3D12. Имеет открытый исходный код. В отличие от Apitrace и Frameretrace записывает только один фрейм, а не последовательность фреймов, со всей сопутствующей информацией. Поддерживает возможность изменения исходного кода шейдеров и их отрисовки, изменение параметров вызовов OpenGL, позволяет визуализировать набор вершин, приходящих в вертексный шейдер.

Набор автотестов Piglit

Piglit — набор автоматизированных юнит-тестов и системных тестов, которыми покрывается весь OpenGL. Общее число этих тестов в настоящий момент приближается к 60 000.

Существуют тесты производительности (время рендеринга) и совместимости, а также тесты, предназначенные для обнаружения регресси. Почти у всех крупных производителей видеокарт есть свои фермы устройств с различными архитектурами процессоров и видеокарт, на которых с определенной частотой запускается Piglit (обычно 1-2 р. в день). Этот процесс является частью Continuous Integration и направлен на обнаружение багов.

Тесты могут запускаться как по отдельности, так и пакетно (в составе тестовых наборов). Базовый набор тестов можно выполнить за 20 минут, а полный раунд тестирования с прохождением всех имеющихся тестов займет несколько часов. Результаты работы тестов могут быть использованы в регрессионном тестировании. Piglit помогает обнаружить нежелательные эффекты того или иного патча. Результаты тестирования записываются в формате .json. Кроме этого, возможно создание наглядных отчетов в html-формате. Piglit также имеет открытый код.

Специфика игр на Steam — настройка окружения

При запуске игры через Steam используется библиотека Mesa, установленная в операционной системе по умолчанию. Для того, чтобы игра использовала свою кастомную сборку Mesa, можно применять специальную возможность Steam, которая позволяет перед запуском игры выполнить скрипт пользователя. В скрипте можно устанавливать различные переменные окружения библиотеки Mesa, а также указать путь к самой библиотеке. Например, скрипт может иметь следующий вид:

#!/bin/bash
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/mesa/lib"$@" > /home/andriy/steam_game.log

Через переменную окружения LD_LIBRARY_PATH задается путь к библиотеке Mesa, которая будет использоваться игрой вместо библиотеки по умолчанию. $@ - выполняет запуск игры, логи которой сохраняются в файл steam_game.log.

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

• Создать скрипт (например, с именем steam_dbg.sh ) и поместить его в /home/${USER}/bin
• Открыть Steam и щелкнуть правой клавишей мыши на названии игры и выбрать Properties.
• На вкладке General щелкнуть на Set launch options.
• Указать команду запуска: steam_dbg.sh %command%

Далее при каждом последующем запуске игры Steam будет выполнять скрипт steam_debug.sh. По мере необходимости этот скрипт может быть изменен с добавлением различных комбинаций переменных окружения Mesa.

Выводы

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

Более детальную информацию об экосистеме проекта и доступных инструментов отладки можно получить по следующим ссылкам:
Mesa project, Mesa environment , Apitrace, Frameretrace, RenderDoc, Piglit.

Если вы знакомы со стандартами OpenGL и/или Vulkan и хотите внести свой вклад в библиотеку Mesa, то первым делом следует ознакомиться с существующими багами, а также подписаться на Mesa mailing list. Далее выбрать интересующие вас компоненты и баги и попытаться их разрешить. Помните, что для каждой подсистемы существуют ментейнеры, которые могут оказать помощь. Удачи!

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU