LINUX.ORG.RU

Нужно чинить иксы

 , , , ,


5

5

X11 robustness: DRI3 без аппаратного ускорения (комментарий)

Сабж

Судя по всему последний раз проблема поднималась в 2018, потом все как-то забыли - да и решения там были весьма сомнительные предлагались - копмозитинг предлагается вынести в иксы, тем самым прибив модульность

В общем, без композитинга всё работает как надо, present через damage вызывает fbCopyNtoN на экранную поверхность, present отрабатывает, пусть и с тирингом.

С композитингом же всё сильно хуже - present делает такое же копирование, но в поверхность окна, для которой работает composite redirect.

Без изменений в композиторе ничего сделать не выйдет - сейчас в протоколе composite композитор получает пиксмапу окна и ожидает что после damage event в ней будут актуальные данные. Это совершенно несовместимос с подходом dri3/present, который привязвает несколько пиксмап к окну и требует лишнего копирования.

Изначальная идея в present предполагала отправлять Notify в композитор. Вероятно от неё отказались т.к это неэффективно - иксы здесь занимаются перессылкой событий и fence между процессами.

В здесь целом напрашивается получение дескриптора для отправки событий композитору напрямую, но это тоже выглядит как какой-то костыль. Но в принципе, dri3 передаёт файловые дескрипторы текстур - почему он не может так же передавать дескрипторы некоего канала с композитором? Звучит как вполне разумное решение, которое будет полезно и для xwayland т.к можно будет передать контроль wayland-композитору напрямую, минуя процесс Xwayland

VK_KHR_swapchain помимо fence оперирует с семафорами. Может можно вообще timeline semaphore задействовать? Но в любом случае надо как-то передавать индекс буфера. Расширение протокола позволит задействовать все возможности Vulkan при условии поддержки композитором. Так же vulkan’овые объекты доступны и в opengl

В общем интересно, остались ли тут разбирающиеся в устройстве иксов и vulkan люди, может кто-нибудь может подкинуть идеи

Возможная идея, что можно пересылать в композитор: https://github.com/notpeelz/monado/blob/main/src/xrt/ipc/client/ipc_client_compositor.c#L737 (freedesktop gitlab опять лежит) Здесь есть 2 варианта функции - с семафорой (включая timeline) и просто с fence. Причём создаётся семафора довольно просто - в vulkan queue отправляется пустой Submit с семафорой, которая ожидается уже другим процессом. То есть даже какая-то дополнительная поддержка со стороны приложения не нужна - дальше вся синхронизация присходит прямо в gpu.

P.S дополнение, всем фанатам и просто пользователям Вяленного, набежавишим в тред. Современный графический стек, предполагающий на каждый чих использовать opengl на клиенте немного несовместим с современными GPU, которые могут потерять все контексты в любой момент на любой чих в шейдере в любом приоложении. И даже если сделать перезапуск композитора с переподключением - это нифига не поможет от падения всего десктопного софта, который вынужден рисоваться через opengl. Почему-то на windows есть GDI и там нет этой проблемы. В иксах же есть свой аналог GDI и потенциальная возможность свести все эти отказы к единой точке, которую устранить. Достаточно избавиться от glamor в сервере, можно даже попытаться переписать его на vulkan, добавив обработку потери контекста. Я сейчас категорически не могу рассматривать рендеринг всех десктопных приложений на клиентах через opengl т.к это создаёт огромные неудобства при gpu reset. Да, можно сделать софтовый wayland композитор и нечто похожее на мой костыльный патч в modesetting, но нормально решить проблему потери контекстов просто нельзя - в архитектуре это просто не предусмотренно. Так что можно хвалить wayland, он прекрасно справляется с медиазадачами вроде 3д десктопа в виртуальной реальности, но превращается в тыкву, когда GPU не может работать

★★★★★

Последнее исправление: mittorn (всего исправлений: 5)
Ответ на: комментарий от mittorn

А теперь задумайся - почему с таким классным подходом, большинство разработчиков графического стека в Linux послали иксы лесом и перешли на активную разработку Wayland? Теория заговора? Смузихлебы? Или может быть просто этот «иксовый подход» не работал как нужно?

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

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

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

там такой прикол, что специализированная очередь копирования годится только если копировать через pci-e, в пределах видеопамяти compute шейдер многократно быстрее. там слишком много подводных камней для полумер

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

почему с таким классным подходом, большинство разработчиков графического стека в Linux послали иксы лесом и перешли на активную разработку Wayland? Теория заговора? Смузихлебы?

Есть пример покруче - был офигенный FreeType 1.2, который очень быстро и качественно отрисовывал ttf шрифты (особенно если в нём патентованный флаг поставить), потом был FreeType2, который стал медленным и не поддерживаемым, а теперь вообще предлагается использовать HiDPI и жить как до появления FreeType - ведь на HiDPI проблем не видно.

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

Кстати да, полезное замечание. Но такая функция была бы весьма полезна для софта, рендерящего на CPU и выводящего изображение на экран, а так же для всего, что делает обмен с другими устройствами вроде prime offload. Особенно с учётом того, что в отличие от compute очереди она не будет нагружать эти самые compute блоки GPU

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

А мне всё ещё нравятся экраны с крупными пикселями и старые шрифты. А все эти hidpi-ретины выглядят не так интересно. Но похоже, что мы теряем эту технологию

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

Мне нравятся новые HiDPI OLED экраны в ноутбуках, но мне комфортно и за моими старыми дисплеями за столом, и я не понимаю, почему они должны превращаться в тыкву (ноут у меня перед самыми глазами, как большой экран, а пара дисплеев на комфортном расстоянии - и там, и там много информации в разных окнах)

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

Я уже тут в нескольких местах объяснял, но повторюсь. dri3 это один из протоколов в иксах, нужен чтобы клиентские приложения могли отправлять gpu текстуры в иксы, а иксы их могли рисовать. Без композитинга всё работает корректно. Со включенным композитингом иксы занимаются лишним копированием текстуры т.к интеграция между протоколами present и composite не доделана. Keith Packard забросил её ещё в 2014 и спустил на тормозах, а последний раз вопрос поднимался в 2018.

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

pixman - оно. Но я не знаю, заработает ли opengl/vulkan на pixman растеризаторе.

И как это поможет в xwayland, там есть композитинг?

В самом xwayland нет, но потенциально можно прокинуть сокет синхронизации в wayland-композитор вместо иксового и миновать тем самым процесс xwayland целиком - он будет обрабатывать только иксовые ивенты. Если конечно в wayland есть аналог present, я плохо помню уже, как там surface работают, но вроде как больше похоже на dri2

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

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

А эти потери контекста с нами в одной комнате? Они как-то вообще проявляются? Сколько сотен раз в вяленом подключал-отключал и диспеи и гпухи, и удалённо работал через мобилку, ничего никогда не падало, всё абсолютно бесшовно. Понятное дело, не было и на ровном месте проблем.

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

фиговенько конечно. У меня софтовый dri3 всё-таки 40-50fps выдаёт на слабой интеловской системе, а на amdшной вообще оверхед не заметен. Но это конечно не композитинг, а только один вызов blit

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

А мне всё ещё нравятся экраны с крупными пикселями

Чур тебя, брось бяку!

старые шрифты

Другое дело - нормальный выравненный пиксельный шрифт да на современный амолед 4К+ - вот была бы бомба. Но увы парадигма разработки сейчас - раз железо позволяет говнокод то давайте говнокодить.

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

какой-нибудь невалидный код на вулкане. У меня например запуск chamferwm гарантировано роняет gfx ring. Попытка реклогинга (изменение pp_table) с какой-нибудь тяжёлой игрой запущенной

Неверные параметры в vce/uvd/vcn вешают его ринг и через какое-то время ядро всё целиком завешивает…

Но и на валидном коде были проблемы, например у меня при температуре ниже 20 градусов в комнате под нагрузкой gpu иногда резетится на ровном месте. Температуры в порядке, но это уже что-то аппаратное.

Готового примера, который весит GPU сейчас под рукой нет, я обычно такой код исправляю :)

Помню, что была команда ffmpeg’а которая гарантированно весила блок енкодера. К сожалению, не сохранилась

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

Печально - но никто чинить не будет. Иксы - это заповедник. Или музейный экспонат. Все красиво стабильно надежно - ну ровно так как спроектировали древние греки. А поскольку древних греков уже нет - увы.

opengl на клиенте немного несовместим с современными GPU

Эти клиенты должны умереть и заместиться новыми совместимыми. В это бабло вкладывают. А вот в разработку икса - увы нет.

Я не люблю вейланд и считаю его убогой пионерской поделкой проданной бигтеху хитрожопыми маркетологами, но увы это реальность - он пришел всерьез и навсегда. Ну и бабло бигтеха так или иначе сделает из этой пионерской поделки нечто работоспособное. И если есть знание и возможность слегка прокачать иксы - ну какбы слава Зевсу, но что-то мне подсказывает что просто тут не будет.

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

Надо было так и написать в заголовке, что ищутся древние греки XD

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

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

Надо было так и написать в заголовке, что ищутся древние греки XD

ВО!!! Так и надо. И приску - древним римлянам просьба не беспокоиться.

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

Qui-Gon ★★★★★
()
Ответ на: комментарий от mittorn

Понятно, т.е. кривое железо и какие-то супермаловероятные кейсы. В иксах всегда были свои проблемы - какая-то древняя игра, кажется criticalmass, гарантировано подвешивала сессию иксов. Были полоски цветные под нвидией, было съезжание дисплея по горизонтали до перезагрузки, причём обязательно по питанию, а последней каплей было то что банальное отключение монитора в какой-то момент стало вешать иксы гарантировано (после чего они у меня и пошли в помойку).

Это я к чему - то что ты перечислил слишком незначительно чтобы говорить о какой-то фундаментальной проблеме в wayland, и даже с этой проблемой, даже кривой и недоделанный, он во всём лучше иксов.

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

расскажу новость - практически любой wayland композитор может запускаться как окно в иксах. Почему? Потому что их разрабаотывали из-под иксов :)

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

Я бы возможно топил за wayland, если бы:

  1. Был протокол индиректной отрисовки или хотя бы попытка его сделать
  2. были бы модули драйверов наподобии xf86-video-*. Им не обязательно иметь архитектуру как в иксах, но они должны реализовывать аппаратно композитинг и отрисовку там, где это целесообразно. Возможно это должны быть модули render-intel, render-radeon, render-imx, render-vulkan, renger-glcore, render-gl1 и т.д. Композиторы с переключаемыми рендерерами есть, так что это вполне возможно. Тогда эта технология не будет уступать иксам, но очевидно, у таких модулей должен быть стандартный интерфейс между разными композиторами - чтобы не реализовывать везде всё заново. Этого нет.
  3. была бы обязательной поддержка server-side декораций для floating комопзиторов, если композитор предполагает использование декораций. Разраб приложения, не заточенного под определённое DE, не должен грузить в свой процесс какой-то libdecor со всеми потрохами, его не волнует как и с какой темой рисуются декорации.

Сейчас wayland - проблема потому что:

  1. Я не могу в opengl/vulkan приложении, которое не смогло создать контекст, вывести уведомление об этом пользователю. Нет, меня не интересует возможность загрузить какой-нибудь libcairo и рисовать им, меня интересует инструментарий который это сделать со стороны вашего дисплейного сервера, который как-то гарантированно рисуется
  2. Нет возможности использовать аппаратное 2д ускорение там, где оно есть. Нет, гонять gl/vulkan растеризатор всегда менее эффективно. Особенно на энергоэффективных мобильных системах gpu не стоит загружать растеризацией 2д прямоугольников.
  3. Моё приложение не будет выгляеть нативно в разных DE, потому что некоторые DE предполагают наличие декораций, а их композитор отказывается их рисовать. И нет, я не должен засорять address space своего процесса всякими libdecor с с зависимостями, моему процессу и так есть чем заняться.
mittorn ★★★★★
() автор топика
Последнее исправление: mittorn (всего исправлений: 2)
Ответ на: комментарий от mittorn

Если конечно в wayland есть аналог present, я плохо помню уже, как там surface работают, но вроде как больше похоже на dri2

Wayland работает через отправку буферов, созданных и указанных клиентом. Сервер буферы выделять не умеет. Так что это ближе к DRI 3.

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

Про декорации что-то странное пишешь, обычно композиторы дают тебе выбор между клиентовыми и серверными декорациями, причём какой-нибудь браузер может жить без декораций, даже если включены серверные, а серверные декорации могут нарисоваться в программе без декораций, даже если включены клиентские. 2д ускорение уже обсуждали, сделают, как только оно станет востребованным. Про gl1 вообще фантастически звучит, скорее, закопают всё gl в пользу вулкана.

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

ЦА гофера и других узконишевых вещей обычно пилит свои странные решения для себя и не навязывает их другим. Чего не скажешь про евангелистов Wayland, эти просто не могут пройти мимо, если кто-то смеет до сих пор колупать иксы, вот характерный пример.

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

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

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

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

То есть прямой анаолог свопчейна. Ну тогда тем более этот механизм может быть полезен xwayland, оставив процессу иксов только обработку иксовых событий в opengl/vulkan приложениях

mittorn ★★★★★
() автор топика