LINUX.ORG.RU

Когда графику наконец перенесут в ядро?

 , ,


3

0

Где ей самое место.

Я ведь правильно понимаю, что сейчас при перемещении мыши происходит следующее:

  • Ядро ловит прерывание, пишет читающим из /dev/input/... инфу о перемещении мыши и пробуждает ждущих данных с соответствующего дескриптора (Xorg-сервер). Это первое переключение контекста.

  • Xorg, прочитав о перемещении мыши, дёргает drmModeMoveCursor чтобы переместить изображение курсора на экране. drmModeMoveCursor — это переключение контекста обратно в ядро.

  • Далее, Xorg-сервер посылает клиентам событие о перемещении мыши, записывая в сокет — опять переключение в ядро.

  • Клиенты читают из сокета — опять переключения контекста.

В общем, куча переключений контекста, поэтому графика заметно тормозит, что порождает темы вроде Windows работает плавнее и четче

Почему многие плюются от микроядер, говорят, что FUSE — это игрушка и реальные ФС должны быть в ядре, но при этом к идее всунуть графический сервер/композитор в ядро относятся отрицательно?

к идее всунуть графический сервер/композитор в ядро относятся отрицательно?

потому что:

  • нечего впихивать т.к. работающий графический сервер, который поднимали с колен больше 20 лет (Xorg) - заброшен и не развивается (банальное отсутствие mixeddpi и fractionaldpi в 2020 это проблема) а не заброшенный графический сервер (вяленый) не работает (с кучей приложений и в целом находится в стадии «глючное фуфло»)
  • идея запихивать графику в ядро оси, которая до сих пор не готова для нормального десктопа (банально не имея вменяемый графический сервер) - довольно посредственная

увы, это правда жизни, линух за последние 20 лет в сторону десктопа не сделал ни одного шага - многие приложения из состояния «бесплатный костыль» выросли до состояния «весьма можно использовать для работы» (гимп, блендер, равотерапия, даже раскрасочный дарктейбл), пришло много коммерческих годных приложений (резолв например) но сама ось как ставила палки в колёса так и продолжает это делать тупо ломая графическую подсистему по причине «а мы хотим писать новое хз зачем вместо того что-бы поправить старое». и это только дно айсберга, посмотри на прогресс той-же экосистемы эппла за последние 20 лет и сравни с прогрессом настольной итерации линуха, где до сих пор проблема банальная проблема открыть .doc не поломав его

rukez ()

Тут ребята китайские пробовали сделать свой ip стек вне ядра и переключений контекста и он там у них заработал значительно быстрее. Но графика то чтобы попасть в ядро должна быть написана на Си. Она должна быть легкой и простой. Она не должна быть Rio, потому что Plan9 с ней не взлетел. Собственно в Paln9 это все сделали, но вот желающих не было взять код gpl2 и всунуть его в ядро линукс от plan9 как это произошло с utf-8, procfs.

anonymous ()
Ответ на: комментарий от anonymous

Но графика то чтобы попасть в ядро должна быть написана на Си. Она должна быть легкой и простой.

Писателей драйверов ФС Си не останавливает. А драйверы ФС бывают весьма непростые, типа btrfs и ZFS.

utf8nowhere ★★ ()

когда вырастут твои дети (если будут, но и без них разберёмся), ты разучишься читать и писать (что по многим уже видно), будешь жрать только на ходу (в маках там и пр. говне), и у тебя не будет стоять в 20 лет.
Я считаю это нормально.

amorpher ★★★★★ ()
Ответ на: комментарий от AntonyRF

Штатно работает в GNOME и wlroots-композиторах, в следующем выпуске KDE сильно улучшили стабильность Wayland-сессии.

Пользоваться можно.

commagray ★★★★★ ()
Последнее исправление: commagray (всего исправлений: 1)
Ответ на: комментарий от utf8nowhere

В общем да. Но Xorg это операционная система сбоку. Тем не менее он потребляет ресурсов меньше якобы просто протокола wayland. Там еще нужно будет wlroots и прочую фигню заодно тащить, и не факт, что будет работать лучше в ядре, отрисовывая пространство пользователя. Просто вейланд иногда вылетает или например не грузится нормально после перехода в другую консоль и показывает какое-то марево. ZFS поглощает память как не в себя. А теперь представим роутер с такой вот приблудой жрущей 500 мегабайт стоя на месте. Может эта мысль неспособна поместиться в голове Линуса или он не хочет делать аналог Plan9 изобретенный на заре появления линукса.

anonymous ()
Ответ на: комментарий от anonymous

Некие ребята пробовали сделать NFS-сервер в юзерспейсе на джаве. И он работал быстрее ядерного на C. (Справедливости ради, ядерный подтянули после этого по производительности).

utf8nowhere ★★ ()

Почему многие плюются от микроядер, говорят, что FUSE — это игрушка и реальные ФС должны быть в ядре, но при этом к идее всунуть графический сервер/композитор в ядро относятся отрицательно?

Плюются, ибо работа с ФС является критической, в отличие от «иксов». Относятся отрицательно потому, что:

а) уже такое было. Называлось Windows NT 4.0, и вся линейка «оффтопиков» 90-х и начала 00-х слыла своей «стабильностью», если вы понимаете, о чём я. Прикол про «переустанови шындоуз», кстати, пошёл именно из тех времён.

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

в) если залезут в «графику», залезут в ядро. Учитывая разгулье хакеров (причём не только китайских), это тем более не нужно.

Korchevatel ★★★★ ()

Почему многие плюются от микроядер

но при этом к идее всунуть графический сервер/композитор в ядро относятся отрицательно?

Потому, что хоть и лицемеры, но на самом деле понимают, что микроядра или даже экзо — это православно. А плюются не потому, что плохо, а потому, что нужно осиливать. Осилил бы Линус в своё время микроядро, все бы сейчас кипятком с этого писали и говорили типа фу, какая фряха со своим монолитом и мелкие с заднеприводными со своими гибридами отсталые.

WitcherGeralt ★★ ()
Последнее исправление: WitcherGeralt (всего исправлений: 2)

графика заметно тормозит, что порождает темы вроде Windows работает плавнее и четче

Дык точно такая же схема и в «оффтопике» – часть в ядре, часть в «юзерспэйсе». Это проблема конкретной реализации (Fedora).

Korchevatel ★★★★ ()
Ответ на: комментарий от Korchevatel

уже такое было. Называлось Windows NT 4.0, и вся линейка «оффтопиков» 90-х и начала 00-х слыла своей «стабильностью», если вы понимаете, о чём я. Прикол про «переустанови шындоуз», кстати, пошёл именно из тех времён.

Виндус деградировал со временем именно из-за графики в ядре?

это ненадёжно. Ибо, во-первых, если навернётся граф. подсистема, а она навернётся, то упадёт и ядро. А во-вторых, на серверах принято делать аппараты более надёжными … Ну и «графику» к серверу никто в здравом уме не будет прикручивать, ресурсы под другие вещи нужны.

А как ядерная графика на это повлияет? Сейчас ты не запускаешь Xorg на сервере, с ядерной графикой не будешь подгружать модули DRM и композитора в ядро.

если залезут в «графику», залезут в ядро.

Каким образом?

utf8nowhere ★★ ()

куча переключений контекста, поэтому графика заметно тормозит

Пруф или не было.

Ты это профайлил?

И да, если хочешь кусок винды — directx12 будет в линуксах (в wsl2), но мелкософт хочет, чтобы это было деталью имплементации и весь софт будет юзать openngl to directx.

x3al ★★★★★ ()
Ответ на: комментарий от anonymous

Дело же не в разграничении прав. Ядро предоставляет интерфейсы, а тормоза от того, что нужно подсосать то одни инструкции, то другие. Чтобы у тебя ничего не тормозило, каждая программа должна уметь самостоятельно общаться с железом, т.е. уметь в драйвера, фс, сеть, общаться с другими процессами и всё-всё-всё.

WitcherGeralt ★★ ()

Что значит «когда начнут»? Когда появится заинтересованные индивид или организация, тогда и начнут. Как обычно это будет какой-то отдельный набор патчей или форк репозитория. Большинство пользователей будут пользоваться дефолтом. Громкая часть меньшинства будет кричать «ненужно». Всё как обычно.

i-rinat ★★★★★ ()

но при этом к идее всунуть графический сервер/композитор в ядро относятся отрицательно?

Так не смотри на других — бери и «всовывай» графический сервер/композитор в ядро.
Линус ни у кого разрешения не спрашивал когда писал своё ядро.

MaxPower ★★ ()
Ответ на: комментарий от anonymous

В общем да. Но Xorg это операционная система сбоку. Тем не менее он потребляет ресурсов меньше якобы

«якобы» на старых ослонах/дюронах и 128 мб оперативки у меня он летал.
причём, ещё старый Xorg.
устроим кислотный тест?

жрущей 500 мегабайт

сцуко, зовите санитаров с формалином, пациент уже отходит, нужно срочно это ускорить!

darkenshvein ★★★★★ ()
Последнее исправление: darkenshvein (всего исправлений: 1)
Ответ на: комментарий от utf8nowhere

Виндус деградировал со временем именно из-за графики в ядре?

Он деградировал из-за индусов во главе M$, которым приспичило стать лордами Телеметрии. «Эффективные менеджеры» и мерзкие маркетологи тоже сыграли свою роль.

А как ядерная графика на это повлияет? Сейчас ты не запускаешь Xorg на сервере, с ядерной графикой не будешь подгружать модули DRM и композитора в ядро.

А, в смысле запихнуть «графику» в ядро? Ну это ещё куда ни шло, при условии сохранения отдельной подсистемы в качестве резервной.

Каким образом?

Любая «дыра» в ядре может позволить злоумышленникам либо поломать систему, либо спереть что-то ценное (или подложить, это если воры государственные).

Korchevatel ★★★★ ()
Ответ на: комментарий от darkenshvein

Ты видимо наискосок прочитал. Памяти жрет вейланд больше. Иксы и правда намного менее жрущие. И да попробуй включи кеш в память на zfs и она сожрет и поболее. 500 мегабайт это дистр с легким рабочим столом на zfs без кеширования в оперативную память.

anonymous ()
Ответ на: комментарий от WitcherGeralt

Потому, что хоть и лицемеры, но на самом деле понимают, что микроядра или даже экзо — это православно. А плюются не потому, что плохо, а потому, что нужно осиливать.

Если все всё понимают, почему Hurd по-прежнему пилят полтора лесоруба? Проект вроде бы и живой, но в режиме зомби. Его бы и осилили и допилили заодно…

hobbit ★★★★★ ()
Ответ на: комментарий от Korchevatel

Он деградировал из-за индусов во главе M$, которым приспичило стать лордами Телеметрии.

Так, стоп. Ты начал про то, что Windows приходилось часто переустанавливать. Это из-за того, что там была графика в ядре?

utf8nowhere ★★ ()

Когда графику

Вся наглядность теряется сразу...
Нужен новый макет - диаграмма.
Или график - он легче для глаза,
Чем таблицы громоздкая рама.

Владимир

anonymous ()
Ответ на: комментарий от anonymous

А память у всех запущенных программ общая будет, чтобы библиотеки по сто раз в неё не загружались? И кто им её будет выделять будет? Не сами же договорятся. И так далее.

Причём здесь какие-то доступы, не понятно.

WitcherGeralt ★★ ()
Последнее исправление: WitcherGeralt (всего исправлений: 2)
Ответ на: комментарий от AntonyRF

Кста, а кто-то в курсе что там с вяленым сейчас?

Докладываю ситуацию по популярным дистрибутивам.

  • В последнем Debian по умолчанию Wayland-сеанс.
  • В Fedora уже как года два по умолчанию Wayland-сеанс.
  • В CentOS 8 и RHEL 8 по умолчанию Wayland-сеанс.
  • SUSE SLE одни из первых ынтерпрайзных дистров заюзали Wayland по умолчанию.
  • В LTS-версиях Ubuntu по умолчанию X.Org, в не LTS, насколько понимаю Wayland.

KDE с полгода назад вроде неплохо подтянули в Wayland-сеансе. Но из-за того что главный разработчик KWin, пиливший активно поддержку Wayland, отошёл от дел из-за каких-то там разногласий с KDE-дизайнерами, переход у KDE сильно замедлился.

EXL ★★★★★ ()
Ответ на: комментарий от anonymous

Два разных предложение объединил в одно, а ни первое, ни втрое не понял, красота.

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

WitcherGeralt ★★ ()

Это будет следующая «идея» для полного переписывания, когда вяленного наконец-то доведут до состояния, когда его может использовать нормальный человек. Ну тоесть лет так через 10. +)

А так в винде графика было в ядре, когда она была относительно простая и фактически для одной архитектуры. Как только в винде графон усложнился и появились другие платформы его тут же оттуда вынесли. x11 намного архитектурно сложнее виндовой граф. системы и он для многих осей и архитектур. Такое в ядро не поместить. Вяленный разрабатывался в том числе для «безопасности», пихать его в ядро как-бы, мягко говоря, не то.

а там где нужна простая графика в ядре она давно уже есть - framebuffer .

vtVitus ★★★★★ ()

По сабжу – часть графики в ядре Windows это Legacy. И помещена она была в ядро не потому, что «хаха тупые мелкософтовские говнокодеры ни шмогли в архитектуру», а потому что в те далёкие времена железо не позволяло сильно разгуляться. Зато Windows мог работать там, где иксы (XFree86) выдавали пук.

Но сегодня Microsoft и любой другой создатель ОС никогда не стал бы делать подобное. Графика в ядре это плохо. Она слишком сложна и объёмна. И Windows с ней до сих пор мучается, когда сервера хакают из-за того, что из ядра торчат графические уши. Эпичные уязвимости из-за графики в ядре:

  1. https://www.thezdi.com/blog/2019/12/16/local-privilege-escalation-in-win32ksys-through-indexed-color-palettes

  2. https://securelist.com/new-win32k-zero-day-cve-2019-0859/90435/

  3. https://www.welivesecurity.com/2019/07/10/windows-zero-day-cve-2019-1132-exploit/

И т. д.

Всем тем, кто хочет графику в ядре посвящается.

EXL ★★★★★ ()
Ответ на: комментарий от EXL

Ну да, только когда иксы жрут 20 мегабайт, bspwm 1 мегабайт, sxhkd, polybar, rogi/dmenu тоже по-слегка это все еще в разы меньше, если использовать compton, который жрет 4 мегабайта, а не 40+ мегабайт. Если не ошибаюсь, то mozc_server жрет больше иксов. А ведь это не графика а движок IME всего лишь. И враки это что иксы тормозят. Может на задохлых двуядерный ноутбуках это и так. Только это проблема говернора, а не иксов. Там 40%+ бывает прирост.

anonymous ()