Про Linux на встроенной графике Intel

Я уже довольно долго собираю и настраиваю десктопы с Linux для дома и офиса, и последнее время не без удовольствия выбираю конфигурации со встроенной графикой Intel. Когда‑то я начинал с машинки, в которую поставил с Core i3–2105, (HD Graphics 3000), позднее — более новый Core i3–9000 (UHD Graphics 630), а совсем недавно мне очень недорого достался Intel NUC5PPYH, разумеется тоже с фирменным графическим контроллером Intel.

Сразу хочу сказать, что если вы не играете в коммерческие игры в Linux, то графические «встройки» Intel — это лучший выбор в плане стабильности и поддержки производителя. Видеодрайвер уже много лет есть в ядре, и он просто работает: с аппаратным ускорением из коробки, без тиринга, без дополнительных проприетарных блобов и прочей головной боли. Более того, таких драйверов минимум два: это традиционный 'intel' и более новый 'modesetting'. Графика Intel с самого начала лучше всего работала в Wayland, не будем забывать и об этом.

Поводом для этой заметки стало наблюдение: эффекты рабочего стола могут тормозить на старых «встройках» Intel при том, что в OpenGL‑приложениях может быть вполне высокий FPS и хорошая плавность. Я наблюдал разные признаки торможения в двух самых популярных рабочих окружениях (KDE Plasma 5 и Gnome 4) как в X11, так и в Wayland. Я хочу поделиться советом про то, как ситуацию можно исправить на примере дистрибутива Fedora $releasever (на момент описания это 37).

Итак, дано: вы ощущаете, что анимация рабочего стола тормозит (ключевые слова: laggy, jerky, stuttering).

Если речь идёт о Gnome, то решением может стать включение динамической тройной буферизации кадров. Прямо сейчас это изменение ещё не принято в Mutter, но для Fedora есть отдельный Copr‑репозиторий с нужными патчами. Сходите по ссылке, там есть все нужные инструкции. Кстати, в Ubuntu 22.04 подобный патч уже применён.

Далее, на скорость отрисовки интерфейса влияет работа framebuffer. Есть смысл включить сжатие фреймбуфера ради повышение FPS в анимациях (и не только). Для этого следует создать файл /etc/modprobe.d/i915.conf с таким содержимым:

options i915 enable_fbc=1

И дать команду:

sudo dracut --force

Эффект наступит после перезагрузки машины.

Если у вас KDE Plasma, то фокус с Mutter, разумеется, не актуален. Plasma имеет свойство более медленно работать в Wayland нежели в X11, что иногда расстраивает (например, если хочется погонять Waydroid). Однако, я случайно нашёл быстрый фикс. Посмотрите, какой вывод у вас даёт команда:

cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

Почти наверняка там будет либо 'powersave', либо 'schedutil'. Изменим его на 'performance':

echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

Вопреки распространённому мнению, это не приведёт ни к опустошению батареи ноутбука, ни к излишнему нагреву CPU. Смысл изменения: расширить рамки динамического регулирования частоты CPU и GPU. Изменения по‑прежнему будут происходить по запросу. Здесь есть интересные детали.

В контексте KDE Plasma 5 указанный фикс делает анимации оконного менеджера Kwin мягкими и шелковистыми. Да, это похоже на костыль, но он работает. Если вам и этого мало, попробуйте отключить в эффектах Размытие, это поможет точно.

Наконец, нашёлся ещё один, довольно неожиданный способ победить «необъяснимые тормоза» эффектов рабочего стола Plasma. Внезапно, иногда kwin не может правильно определить частоту обновления кадров вашего монитора и требует ручной настройки. Попробуйте в файл ~/.config/kwinrc в разделе [Compositing] добавить такие строки:

MaxFPS=60
RefreshRate=60

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

Спасибо, что дочитали. Надеюсь, что мои советы помогут кому‑нибудь.

@Writer
02.03.2023 16:43 UTC
Первоисточник

Комментарии

@fk0
02.03.2023 12:20 UTC
+8

У меня нет wayland, plasma, mutter, и чего-то там ещё. У меня X11, fvwm3 и xterm, мне тыщу лет я вылез из тьмы. И не тормозит ничего. Текст в xterm прокручивается с первой космической скоростью. Чего не сказать о konsole, gnome-terminal и прочей новомодной ерунде. И работает на любой видеокарте. Без всяких композитных менеджеров.

Хотя да, включение tripple buffering для просмотра кино нужно. Или включение композитного менеджера. Из-за tearing'а.

@Kreastr
02.03.2023 12:30 UTC
+1

При всем уважении к xterm, alacritty все же быстрее за счёт рендеринга через OpenGL.

02.03.2023 14:06 UTC
0

у меня почему-то alacritty тормозит в сравнении с foot

02.03.2023 15:50 UTC
0

Возможно особенности Wayland. У меня foot вообще не запустится.

02.03.2023 22:14 UTC
+1

В вашем alarcritty всё лажает (от слова lag) в буквальном смысле слова: https://www.reddit.com/r/linux/comments/jc9ipw/why_do_all_newer_terminal_emulators_have_such_bad/

Нажимаешь буковку и, и, и, видишь её на экране. Будто через ssh работаешь. При том что xterm за пару миллисекунд отрабатывает. Ну и памяти жрёт на порядки меньше.

Не говоря уж про такие мелочи, как возможность работать через иксовый протокол вобще (и гонять через него не графику, а тексты), работу в палитровом 8-битном цвете в VNC (где аппликации с 32-битным цветом еле шевелятся).

Не понятно как в alarcritty (да и многих прочих терминалах) с альтернативным экраном (очень неудобно, посмотрел ман, вернулся -- а с экрана всё потёрли...), с записью всего выводимого на экран в файл, с вводом паролей с монопольным фокусом (чтоб какой-нибудь браузер не подсматривал).

Про эмуляция графического Tektronix ещё можно вспомнить. Если нужно сделать простейшую программу чтоб простейший график нарисовала -- вполне себе вариант, много быстрей и проще, чем любой GUI-тулкит. Особенно если это вообще программа на микроконтроллере и только в компорт команды терминалу посылает.

07.03.2023 09:07 UTC
0

Нажимаешь буковку и, и, и, видишь её на экране. Будто через ssh
работаешь. При том что xterm за пару миллисекунд отрабатывает.

144 Гц монитор => 7 мс. А если у Вас еще и клавиатура USB, а не ps/2, то нужно не забыть добавить 5-20 мс на опрос ( https://youtu.be/wdgULBpRoXk?t=1767 ). Уже сравнимо с "плохими современными терминалами". В статье на реддитте ссылка на оригинальный замер производительности. Да, xterm в некоторых ситуациях видимо имеет меньшую latency. Но вот, например здесь ( https://lwn.net/Articles/751763/ ) у alacritty измерена latency 15 ms под i3 (как раз мой случай), то есть вероятно, что и у Вас alacritty тоже работает медленнее, чем могла бы совсем не сама по себе, а из-за оконного менеджера или даже среды или драйверов. Так что я бы не стал делать выводы даже по таким бенчмаркам. К сожалению, у себя на компьютере сейчас сравнить производительности не могу, потому что тестовый софт, который использовался в статье, у меня падает. А узнать было бы интересно, конечно. По себе скажу, что на моей системе и моем железе xterm ощущается существенно более картонным и тормознутым, чем alacritty, хотя он действительно совсем не медленный сам по себе. Только в сравнении. И да я чаще скролю логи, чем печатаю в терминале. Это наверняка сказывается на моем восприятии скорости.

Ну и памяти жрёт на порядки меньше.

Для ПК с 512 Мб памяти (а еще лучше без видеокарты) это бесспорно аргумент. Я не настаиваю на том, что ВСЕ задачи нужно решать при помощи alacritty.

Не понятно как в alarcritty (да и многих прочих терминалах) с
альтернативным экраном (очень неудобно, посмотрел ман, вернулся -- а с
экрана всё потёрли...)

Я для этого использую оконный менеджер. Переключать экраны в терминале не приходится. На крайний случай есть screen.

Не говоря уж про такие мелочи, как возможность работать через иксовый
протокол вобще (и гонять через него не графику, а тексты), работу в
палитровом 8-битном цвете в VNC (где аппликации с 32-битным цветом еле
шевелятся).

И часто Вам приходится гонять через иксовый протокол запущенный на сервере xterm, вместо того, чтобы, собственно, использовать ssh? Мне не доводилось, но если рекомендуете, то обязательно попробую.

Про эмуляция графического Tektronix ещё можно вспомнить. Если нужно
сделать простейшую программу чтоб простейший график нарисовала -- вполне
себе вариант, много быстрей и проще, чем любой GUI-тулкит. Особенно
если это вообще программа на микроконтроллере и только в компорт команды
терминалу посылает.

Интересная фича. Не знал о ее существовании. Спасибо. Сильно она лично мне погоды не сделает, правда. Мои программы на МК либо выдают данные, либо поднимают веб сервер с REST API или HMI.

07.03.2023 11:45 UTC
0
Я для этого использую оконный менеджер. Переключать экраны в терминале не приходится. На крайний случай есть screen.

как я понял, речь совсем не про переключение между сеансами, а вот про это:


$ echo 123
123
$ less /etc/motd 

по выходу из less вы снова видите 123 (в некоторых тупых терминалах это не работает)

07.03.2023 16:17 UTC
0

А, понял, но к alacritty это точно не относится. Все работает, как Вы и описали. По выходу из less все еще 123 показывает.

@V1tol
02.03.2023 15:39 UTC
0

Тиринг можно починить с помощью TearFree, но нужна свежая меса если используется modesetting (пулл реквест для него смержили только три месяца назад). Для amdgpu доступен уже достаточно давно.

@
02.03.2023 16:41 UTC
0
НЛО прилетело и опубликовало эту надпись здесь
02.03.2023 22:16 UTC
+1

Лигатура и моноширинный шрифт, очевидно, не очень совместимые понятия. Не поддерживает.

Ещё там нет смайликов (emoji), так что вообще ни в какие ворота. А старые пердуны могут дальше выписывать в ASCII-art'е.

02.03.2023 22:53 UTC
0
НЛО прилетело и опубликовало эту надпись здесь
03.03.2023 08:54 UTC
0

xterm умеет юникод, причём стал уметь несколько раньше, чем, к примеру, rxvt. По-крайней мере, может показать то, что есть в используемом шрифте (как минимум, показал мне ¹²³‰↑∞←→↓, остальное доступное мне для ввода пробовать не стал).
По поводу того, появился ли юникод в xterm раньше, чем в konsole - хз, ибо xterm с юникодом я в первый раз запускал примерно тогда же, когда юникод в дебиане стал по-умолчанию.
Про undercurl не скажу - не требуется в консоли сейчас и не требовалось во времена использования мной xterm.

Личное: xterm хорош как терминал, но настройка его несколько неоднозначна при наличии альтернатив, а фичи типа альтернативного экрана невостребованы, отчего и был заброшен при очередной смене рабочего места.

02.03.2023 22:22 UTC
0

Вообще эмулятор терминала работает по протоколу VT220 или похожему. Откуда там всё это?

@Stanislavvv
03.03.2023 08:42 UTC
0

/etc/X11/xorg.conf.d/55-intel.conf:

Section "Device"
Identifier "Intel"
Driver "intel"
Option "TearFree" "on"
EndSection


Как раз для просмотра кино.

@rmrfchik
06.03.2023 14:11 UTC
0

Только xterm медленнее konsole.

@Nnnnoooo
02.03.2023 13:33 UTC
0

Трюк со scaling_governor работает и с mutter-ом
Также если есть проблемы с микрофризами мыши или клавы, как вариант подключать их через USB2 порт. Если такого порта нет, то поможет даже дешевый usb хаб. Я хз с чем єто связано, но у меня NUC 12-го поколения и міша с клавой периодически лагали (особенно под нагрузкой), после их подключения через внешний usb2 хаб — проблема пропала (ну почти пропала, кроме неизлечимой проблемы однопоточного mutter-а)

@edo1h
02.03.2023 13:54 UTC
0

а в dmesg не смотрели? это может быть отваливание и переподключение usb-устройства

02.03.2023 15:02 UTC
0

не там все ок. Это какая-то старая проблема связанная опять же с профилями электропитания и вылазит почему-то только на новых usb3 и выше контроллерах. И только при прямом подключении мыши и клавы к ним — через хаб уже все ок.
На старых нуках подключал все к usb2 портам, а на новых их уже нет.


Да и как-то желания сильно разбираться не было — мне главное чтобы все просто работало. Если можно решить проблему просто используя хаб (который все равно нужен), то я буду решать таким способом

@neon1ks
02.03.2023 13:33 UTC
+1

В защиту AMD скажу, что здесь тоже норм!

@kemsky
02.03.2023 16:26 UTC
0

На ноуте 22.04 (XPS 17), но все равно периодически она тупит. Видео поверх картинки или видео плюс idea - начинаются фризы, причем я в дуалбуте и на винде тоже присутствует. В чем причина я не знаю, но наблюдалось на всех ноутах, что у меня были.

@
02.03.2023 16:45 UTC
0
НЛО прилетело и опубликовало эту надпись здесь
@alexkuzko
03.03.2023 08:25 UTC
0

Добавлю свои копейки: в основном работаю через гном, но замечаю что через некоторое время все начинает безбожно тормозить. Перезагрузка помогает. Пробовал возврат к xfce, e17 и чего только не пробовал... Сейчас балуюсь второй месяц с Awesome (прикольный, но после сборки требует доработки напильником даже для простых вещей...)

Так к чему это я? Оказалось что всё-таки основной причиной являются браузеры и все их производные (электрон...). Закрываешь всё и снова хорошо.

Решить эту проблему нормально не получается, поэтому пока что просто перезапускаю с восстановлением вкладок. Для электронов то же решение.

Возможно это графика и влияет (core i3 пятилетний, поменял с i5 случайно между другим своим и долго разницы не видел, что прикольно), но это самая раздражающая вещь, которую пока никак побороть не могу.

@ReaM
03.03.2023 08:49 UTC
0

Почему xfce забыли:( тормозит-то точно так же как и все остальное!

@alexkuzko
03.03.2023 09:39 UTC
0

А я выше написал :)

Похоже тормоза всё-таки не только из-за оконного менеджера...

@delvin-fil
04.03.2023 14:50 UTC
0

Gentoo
i3 CPU 530, 4Гб DDR3
IceWM
Хрома нет.
Тормозов не наблюдаю.

@Writer
04.03.2023 16:40 UTC
0

В чём преимущество IceWM?

06.03.2023 15:07 UTC
0

Настройка проста как угол дома и миниатюрность.