Ускорение работы Gnome Shell.
После того как Canonical отказалась от Unity и взяла дефолтной рабочей средой Gnome Shell прошло уже почти два года. Марк Шаттлворт обозначил в те времена что Gnome Shell будет от разработчиков оригинального проекта, в том смысле что не будет патчиться на стороне Canonical. Это всё на деле подтверждалось и вот теперь мы видим даже больше. Разработчик Canonical Daniel Van Vugt проделал гигантскую работу по устранению проблем с производительностью рабочей среды и все наработки будут в оригинальном проекте и работой воспользуются все дистрибутивы, использующие Gnome Shell.
Если вы владеете техническим английским, то лучше читать оригинал Boosting the Real Time Performance of Gnome Shell 3.34 in Ubuntu 19.10
Что такое Gnome Shell?
Кратко, это среда рабочего стола, написанная на языках C и JavaScript и работающая поверх компоновщика/оконного менеджера Mutter. Большая часть логики находится в проекте Mutter, который включает графические инструменты Clutter и Cogl. Mutter состоит из 1389 исходных файлов языка С. В то время как большая часть проекта Mutter используется в Gnome Shell в качестве библиотек, mutter также существует как автономный композитор, если всё, что вам нужно, это указатель мыши и обои.
Проект Gnome Shell меньше вышеупомянутых проектов, добавляя "всего лишь" панель bling и лаунчер, подобно тому как Unity 7 была над Compiz. Gnome Shell состоит из 199 файлов-исходников языка С и 157 файлов языка JavaScript.
Следует отметить, что большая часть исходного кода находится в проекте Mutter, а не в проекте Gnome Shell. Таким образом, в целом получается что ~10% приходится на JavaScript и, учитывая Mutter, ~90% написано на С.
Проблема
Gnome Shell 3.32 в Ubuntu 19.04 работает медленнее чем Unity и другие среды. Если у вас слабый компьютер, то не ждите сглаженной работы DE. Но более печально, что если ваш ПК мощный, то разительно лучше не станет.
Предлагаемые и очевидные решения
Многие пользователи слышали что используется интерпретируемый язык JavaScript и легко и просто обвинить его во всех бедах. Но мало кто знает что только 10% кода написано на JavaScript и большую часть времени JavaScript не работает, так как в классическом варианте взаимодействия пользователя с программой XYZ используется только машинный код языка С.
Разработчики стремятся сосредоточиться на исследовании использования CPU и GPU. Есть множество способов как это сделать, но, как правило, вы профилируете свою программу и ищите "горячие точки" (hot spots), где больше всего затрачивается время CPU и GPU. Но в случае с Gnome Shell самая большая проблема была не с горячими точками, а с "холодными точками" (cold spots) - где был простой (idle) вместо плавного обновления экрана. Такие холодные точки отчётливо видны тогда, когда вы мониторите в режиме реального времени программу, а не затраченное время CPU и GPU.
Найденные и исправленные ошибки в Gnome 3.34
Gnome Shell и Mutter являются однопоточными (single-threaded) приложениями Glib с циклом событий (event loop). Любые паузы могут привести к тому, что можно пропустить следующий кадр и начнётся заикание (stuttering).
Используя профилировщики gprof или callgrind, удалось найти много ошибок:
1. Ненамеренно пропущенный кадр из-за неверно рассчитанного начала старта его рендеринга
Данный баг не случался постоянно, поэтому многие люди скептически относились к факту наличия таких ошибок. Проблема возникает когда кадр задерживается на пару миллисекунд по любой причине. Как результат исправления ситуации - более стабильный frame rate и плавность.
2. В Xorg всё было на 1 кадр медленнее, чем в сессии Wayland
Ситуация отчётливо была видна при перетаскивании окон в релизе 19.04 и это было одной из причин предпочитать Wayland. Но не было уверенности что это вина Mutter. Легко было предположить что Xorg просто медленно работает, так как Unity и другие DE показывали схожее отставание в сессии Xorg. Оказалось ошибка была в слишком раннем планировании кадра (в отличии от предыдущей проблемы) и это на ~16 мс увеличивало время между собственно рендером кадра и его визуализацией (визуальная задержка).
3. Mutter получил больше механизмов синхронизации кадров
Раньше движение курсора было искусственно ограничено частотой 60 Гц в сеансе Wayland. В результате работы это ограничение убрано и движение курсора в сеансе Wayland происходит с полной частотой (full refresh rate), как было и есть в Xorg. Некоторые системы с NVIDIA чипами больше не нагружают CPU при определённых обстоятельстах.
4. Mutter ставит в очередь все события input
И не показывает их Shell или программе до тех пор, пока не был визуализирован следующий кадр. Частота кадров обычно составляет 16 мс (1000 мс в секунду / на 60 кадров в секунду), и это достаточно близко к значению, которое многими людьми воспринимается как задержка. Это всё равно как указывать на экран слегка шаткой палкой.
5. NVIDIA в Xorg приходилось тротлить
Из-за того что драйвер NVIDIA слишком быстр для старых релизов Mutter, приходилось ограничивать возможности CPU и GPU параллельно работать с друг другом и плавно отображать кадр. Новый Mutter принесёт упрощение в механизмах пропуска кадров (дросселирование, тротлинг). Как результат, рендеринг на чипах NVIDIA стал намного быстрее и плавнее.
6. Picking больше не использует OpenGL
Picking - это процесс выяснения что находится под курсором когда мышь движется или изменяется экран. Это требует остановки конвейеров CPU и GPU до их синхронизации. Ситуация связана с историческим дизайном Clutter для охвата всех возможных дизайнов пользовательских интерфейсов. Вызывалось слишком много OpenGL вызовов что требовало больше ресурсов CPU. Теперь Picking делается чисто на стороне CPU и получилось что движение мыши теперь занимает меньше ресурсов CPU и ноль GPU. Так же обработка Picking не останавливает рендер всего рабочего стола (и приложений) под курсором движущейся мыши. Таким образом, всё началось как попытка уменьшить нагрузку на CPU, а закончилось повышением общей производительности Shell.
Найденные и НЕ исправленные ошибки в Gnome 3.34
1. Рендер в сессии Wayland с многомониторными конфигурациями тратит некоторый случайный фиксированный процент своего времени (в среднем 50%) на состояние: заблокирован, спит, не может отобразить экран или ответить пользователю.
Это вызывается блокировкой в бэкэнде Wayland (родной EGL). Поэтому в настоящее время для использования Gnome с несколькими мониторами вам нужно выбрать один из двух не оптимальных вариантов:
- Wayland: блокируется и заикается слишком часто, но не рвёт экран (тиринг).
- Xorg: Тиринг из-за DRI2 (исправлен будет в DRI3), но не блокируется и не заикается.
Вся ситуация будет исправлена в Gnome 3.36 и Ubuntu 20.04 Focal Fossa. Сессия Wayland обеспечит идеальный баланс гладкости и отсутствие разрывов.
2. Mutter иногда не может правильно запланировать следующий кадр.
При умеренной загрузке CPU (даже не высокой) может случиться данная проблема, исправление которой имеет побочные эффекты в бэкэнде Wayland. Это разные проблемы, но их нужно исправить и, возможно, в рамках Ubuntu 20.04.
Ошибки, сделанные по пути
Век живи - век учись. Учитесь на наших ошибках.
- Предполагать что умеренная загрузка CPU причина не плавной графики. Согласен, что 50% загрузки CPU i7 это перебор, но не причина и объяснение что десктоп не гладкий. Умеренная загрузка CPU пока не главная проблема.
- Сразу переходить к профилированию GPU когда простые измерения процесса рендеринга показывают его низкую загрузку.
- Предполагать что JavaScript медленнее всего на С.
- Предполагать что JavaScript используется для всего. По факту, если вы взаимодействуете только с окном приложения, JavaScript не используется. Это чистый C.
- Предполагать что всё происходит так быстро как CPU и GPU выполняют (без задержек при запуске). Ошибки при программировании или дизайнерские решения показывают что это не так.
- Не тестировать мониторы с высокой частотой обновления. Компьютер с монитором 60 Гц может достичь 30 Гц при рендеринге, но тот же ПК с монитором 120 Гц достигает 60 Гц. Значит тот же CPU и GPU не является узким местом и проблемой. Урок в том, что есть баг, приводящий к пропуску кадров и это не ограничение оборудования.
- Верить что повышенное использование ресурсов CPU это ошибка. Для примера, если вы были блокированы и достигали лишь 30 fps при 40% загрузке CPU, то устранение блокировки приведёт к 60 fps при 80% CPU. Загрузка CPU выше, но это желательный шаг вперёд для достижения полной частоты кадров. Не стоит думать, что делаешь ошибку лишь потому, что изменение кода увеличило нагрузку на ЦПУ.
- Предполагать что перетаскивание окон связано с остальными частями Shell. Это не всегда! Было обнаружено что медлительность перетаскивания окон имеет свою уникальную природу.
- Смотреть на анимацию иконок и предполагать что это связано с производительностью остальной части Shell. Но это не так! По общему признанию проблема очень похожа на JavaScript и причина ни как не связана с вашим GPU и драйверами, только с избыточным потреблением CPU.
- Тратить много времени, чтобы полностью понять вывод профилировщика. Профилировщики всегда будут генерировать больше информации, с которой человеческий мозг может справиться. Важно уметь фильтровать, анализировать и действительно тратить время на понимание того, что он вам сообщает.
- Не использовать другие операционные системы для сравнения. Нельзя понять разницу, если нет опыта работы с Mac OS X, ChromeOS, MS Windows и т.д
- Гадать без измерения.
- Профессионально гадать на основе предыдущего опыта без новых свежих измерений. Разработчики думают что знают что быстро, а что медленно. Иногда лучше забыть про свой опыт и притвориться что в действительности ничего не знаете и пусть тщательнейшее измерение вас удивит и просветит. Можете обнаружить, что те оптимизации, которые делаете по привычке - на самом деле незначительны.
Великий план наступления на производительность Gnome Shell
17.10: Gnome Shell становится дефолтной средой Ubuntu
18.04: Незначительные улучшения производительности
18.10: Незначительные улучшения производительности
19.04: Незначительные улучшения производительности
19.10: Значительное улучшение производительности: <---- Вы здесь
20.04: Цель: высокая производительность на быстрых и современных машинах
20.10: Цель: высокая производительность на медленных / старых машинах
Много проблем исправлено, но есть ещё хитрые ошибки, которые ждут своего часа исправления. Первоочередная цель разработчиков - высокая производительность на быстрых и современных машинах. Это означает реализацию полной частоты кадров вашего монитора без заиканий и тиринга. Хорошей новостью является то, что работа по исправлению ситуации делается в Mutter 3.34 для Ubuntu 19.10 и в Mutter 3.36 для Ubuntu 20.04.
Основную работу разработчики Gnome уже начали и требуется лишь дальнейшие обсуждения и советы по измерению и отладке.
После того как проблемы, мешающие раскрыть потенциал мощных машин, буду устранены, будет составлен план по исправлению ряда горячих точек для CPU/GPU, которые являются основных классом проблем для слабых машин. Вероятно данные работы будут совершены в 2020 году.
Воспринимайте работы не как Gnome Shell 3.34 в Ubuntu 19.10 сделали быстрее, а как начаты первые шаги, которые ещё улучшат и исправят ситуацию.
