Производительность Mir и XMir

Статья пытается раскрыть общее представление о производительности нового дисплейного сервера Mir, временной прослойки XMir для совместимости с X, а также пытается описать текущие узкие места и варианты исправления ситуации. Mir и XMir появятся в Ubuntu 13.10 Saucy Salamander, поэтому их работоспособность и производительность очень важны.

Mir основа будущего единения Убунту на всех платформах. Именно Mir будет скрывать для Unity Next работу с нижележащими драйверами на платформах x86-x64 или ARM.

Целью Mir и XMir является предоставление для пользователя гибкого опыта взаимодействия (User Experience, UX) как в случае обычного десктопа, так и в сложных сценариях типа 3D игр. Причём, обеспечение этого взаимодействия должно вносить минимальное влияние на производительность любого 3D приложения.

Люди часто задают вопрос разработчикам о влиянии на графическую производительность нового compositor'а. Кратко можно ответить так: "Конечно, XMir, как любой другой дополнительный слой между GPU и самим процессом рендеринга, оказывает влияние на общую производительность". Тем не менее, есть способы уменьшить накладные расходы.

Compositor собирает в процесс композитинга из множества буферных потоков (buffer streams) окончательное изображение, которое отображается на подсоединённых мониторах. В общем случае, процесс композитинга требует буферизации финального изображения, что в свою очередь требует GPU ресурсы для рендеринга отдельных областей в итоговый буфер. Итоговый буфер здесь - framebuffer. Лишний шаг рендеринга в этом графическом конвеере можно назвать накладными расходами, но преимуществом является контролирование финальной картинки, что позволяет: загрузку без мерцания, выключение, приостановка (suspend) и просыпание (resume), а так же переключение сессий.

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

Основная идея проста. Если compositor достаточно умён, он может распознать ситуацию, когда непрозрачная клиентская область целиком закрывает вывод в ситуации с полноэкранным приложением. В этом случае, процесса композитинга можно избежать и "клиенту" предоставляют framebuffer вместо буфера в графической памяти.

Кроме того, стратегия композитинга со стороны "сервера" так же может помочь, полностью пропустив финальный этап композитинга и отправить framebuffer, как есть, после сигнала "готово" от "клиента". Этот легендарный трюк с обходом называется bypass.

Архитектура Mir позволяет легко реализовать вышеописанные улучшения, что и было сделано в отдельной ветке XMir. Начальные тесты на платформе Intel не выявили никаких проблем. На картах AMD/ATI выявлены небольшие графические глюки, над исправлением которых ведётся работа. Открытый драйвер Nouveau для NVIDIA видеокарт вызывает проблемы своей медлительностью, как для X так и для Xmir, но серьёзных проблем с графическими артефактами не наблюдается.

Результаты тестирования.

Измерение производительности и составление грамотных бенчмарков является сложной задачей само по себе. К счастью, в мире свободных исходников есть инструменты для тестов. Во время разработки и обкатки улучшений, разработчики применяли в основном Phoronix Test Suite и glmark2.

Вскоре будут опубликованы результаты тестирования Intel, NVIDIA и AMD GPU в рамках обычной QA отчётности, после того как ветка попадёт в trunk. А пока результаты такие: удалось снизить накладные расходы временной прослойки XMir на ~6% в тестах Nexuiz и OpenArena.

Полные отчёты по тестированию с помощью GLMark2 так же будут доступны позднее в рамках QA отчётности, для этого отслеживайте reports.qa.ubuntu.com/graphics/.

А пока для затравки есть отчёт, сделанный на Lenovo x220, i7 vPro, Intel(R) HD Graphics 3000, и цифры обнадёживают.

Картинка большая, поэтому ткните для открытия в отдельной вкладке для удобного просмотра.

Выводы и дальнейшая работа.

Оптимизации значительно увеличили GPU производительность в бенчмаркинге. В обычной работе, пользователи вряд ли заметят разницу в графической производительности, но смогут заметить снижение энергопотребления на ноутбуках, так как system-compositor стал требовать меньше циклов CPU и GPU для выполнения своей задачи.

Сделан первый шаг в оптимизации временного моста XMir между старым дисплейным сервером X и новым Mir. Тесты GLMark2 показывают, что ещё есть поле для деятельности.

Производительность unity-system-compositor не является узким местом в системе и многие улучшения нужно делать на стороне Х сервера. Метод bypass нужно проталкивать далее, но учитывая что Compiz знает и применяет composite bypass, выходит что основные оптимизации находятся в самом Х. Основная задача состоит в том, что нужно объяснить серверу Х, что он живёт в мире вложенных compositor'ов.

Дополнительные материалы:
Установка и тестирование Mir в Ubuntu 13.10.
Планы разработчиков на Ubuntu 13.10 Saucy Salamander.
Вопросы и ответы про новый дисплейный сервер Mir.