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)
Ответ на: комментарий от einhander

Где мой слой совместимости с драйверами тачскрина и юсб мониторов и видеокарт? Где слой совместимости с xrandr?

Там же где и сами эти тачскрины и usb недоразумение - на помойке.

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

Ну так а я о чём говорю? Без picom, на голом ускорении через Glamor, всё кроме теней окон работает лучше. А запиливать функциональность композитора/шины для добавления функциональности в кнопочки окна - это издевательство над здравым смыслом. Ну и количество тайлинговых композиторов в сравнении с обычными намекает...

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

Без picom, на голом ускорении через Glamor, всё кроме теней окон работает лучше.

Думаю, под «всё» ты подразумеваешь не очень много. Насколько я помню, Glamor не включали по умолчанию, и не удивлюсь, если так и не включили. Попытки его использовать много лет назад дали мне ответ на вопрос «а почему оно не включается по умолчанию, если такое классное?» :) Точного перечня проблем у меня нет, но, насколько я помню, так оно и не прижилось у меня.

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

Без picom, на голом ускорении через Glamor, всё кроме теней окон работает лучше

Не знаю что там у кого работает лучше, но лично у меня на AMD Ryzen 9 3900X + AMD Radeon RX 6400 в FVWM'е тормозит RetroArch при разрешении 2560x1440. При FullHD работало нормально, да.

А при разрешении 2560x1440 RetroArch у меня нормально работает только в Wayland'е.

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

Тени прекрасно работали на WinXP, на железе, на котором современное ядро не факт что загрузиться. Про остальной гуй молчу.

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

В линаксах не осилили и этого. Вернее фыркнули в сторону рисованных теней и вот уже 20 лет пытаются рисовать цирковое представление из васянских спецэффектов.

Т.е. Некрософт всё сделал по феншую 25 лет назад, а ШВАБОДНЫЕ ЛЮДЕ заводят прозрачности, хдры и 200гц на 5090.

Два мира, два Шапиро.

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

Ещё пример. За вяленд всегда набигают петросяны.

Метро Исходус работает в 4К (а не в этом убогом щелеразрешении) на относительно скромных 5600х 6700хт

Выкиньте свое говно и руки свои туда же.

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

В amdgpu без композитора окошки целиком без артефактов именно им рисуются.

Ну и? Glamor включается без явного указания в xorg.conf? Производительность в играх не страдает? Задержка ввода не появляется?

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

Ты игры на двухчиплетном говнопроце пускаешь. Они тормозят об обмен через infinity fabric. более дешёвый 3800X такой проблемы не имеет.

А под вялендом, сталобыть, процессор превращается в более дешёвый одночиплетный? Ага, так и запишем…

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

Нет, всё работает. Glamor - это эмуляция 2D ускорения на 3D ускорителях. Если бы он не включался, у меня бы иксы дико тормозили. Пролизводительность наоборот лучше - т.к. 3D только в окне игры (как в фуллскрин)

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

Тени прекрасно работали на WinXP
В линаксах не осилили и этого.

давно осилили, и еще много свистелок, которые ни какой винде и не снились, открой для себя старый-добрый compiz

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

А зачем этот самый dri3 нужен тогда вообще? На википедии написано про аппаратное ускорение, но на NVIDIA игры играются и все хорошо.

Про swapchain тоже не понял, если бы под X11 не была доступна половина Vulkan, все Wayland-фанаты давно бы рассказали.

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

В топике есть ссылка на статью, там я описал, зачем оно нужно - текстура из opengl не может сама каким-то магическим образом оказаться в окне.

У драйвера nvidia есть какой-то свой аналог dri3 в расширении NV-GLX. Как он работает - я не знаю, документации на протокол нет. Но это решение, прибитое к конкретным GPU. DRI2 он тоже не использует, хотя возможно раньше там был похожий принцип работы.

В открытых драйверах же для этих задач DRI2 и DRI3 - первый управляет буферами внутри иксов и требует тесной интеграцией иксового драйвера с реализацией opengl. Он очень ограничен, например выводить текстуры с других GPU не может. У nvidia тоже есть эта болячка.Второй же универсален т.к работает с файловыми дескрипторами, а не привязанными к конкретному GPU GEM

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

больше 255 кодов клавиш

Ещё один, кому 255 кодов не хватило, а всем нормальным людям хватило.

скриншоты с выпадающими меню

Кстати, в винде тоже, но там другое поведение, при нажатии на скриншот - просто закрывается попап.

нормальная изоляция окон приложений

…которую предлагали в виде спеки к иксам с нормальной системой прав, а на деле оказалась никому не нужна.

быстрый композитинг

Что это?

VSync

…и в африке VSync. Ты про VRR забыл по своему списку, но он тоже работает.

HDR

Можно, но он бесполезен на десктопе.

мониторы с разным DPI и т.д.

В иксах тоже есть механизмы для этого.

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

Wayland’овый композитор реализует частично фичи иксов, а также фичи оконного менеджера и таких композиторов как picom. 3 в одном.

Вместо модульности, сделали несовместимый с остальнными серверами монолит. И сервер, и композитор, и оконный менеджер и фичи DE - в одном приложении, и так каждый раз с каждым DE.

Что также положительно влияет на скорость, поскольку отдельным приложениям надо обмениваться данными по шине

Вам эту пропаганду в уши новостями на похорониксе влили? Потому что по факту разница насколько маленькая, что пофиг. Даже пофиг в какую сторону там производительность больше.

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

Кстати, реализация попапов в иксах максимально убогая. Это первое что надо по хорошему переделать, если делать новую версию протокола. С разными dpi у wayland конечно есть преимещества - например окно может одновременно рисоваться под 2 вывода с разными dpi и композитор это обработает, иксы такое не могут. Но честно говоря это такой ограниченный юзкейс, что ради него делать множественную отрисовку одного окна - больше на костыль похоже. И опять же обсуждение wayland тут - оффтоп, тред не ради холивара создавался, в development, а не talks…

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

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

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

А какой там ивент? В любом случае комоппозитор как-то оповещается о том, что окно обновлилось. Да, я не писал композиторы, потому не знаю подробностей

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

А, тогда понятно )

Просто я всегда считал, что damage event — это когда в иксах одно окно перекрыло другое, а потом исчезло, и надо срочно перерисовать кусок исходного. В композиторе, что в иксах, что не в иксах, такого события не наступает никогда.

А ты пишешь в том смысле, что любое событие о том, что окно изменилось.

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

Кстати, реализация попапов в иксах максимально убогая. Это первое что надо по хорошему переделать, если делать новую версию протокола.

Даже в винде на это забили.

И опять же обсуждение wayland тут - оффтоп, тред не ради холивара создавался, в development, а не talks…

Я тебя предупреждал, что тут одни смузихлёбы, которые не умеют в проектировании систем. Им сказали, что Wayland - хорошо, иксы - плохо. Своей головы подумать у них нет. Им будут рассказывать потом, что давайте выбросим Qt, GTK и будем делать приложения со своим самопальным тулкитом по спеке SuperVasyanUI, так побегут же делать и будут с пеной у рта рассказывать, как устарели фреймворки, придуманные «дидами» и т.д, а несогласные - тулкитофанатики.

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

как работает swapchain: приложение запрашивает у окнонной подсиситемы поверхность с нужным present mode, форматом, usage в ответ получает все текстуры, из которых этот чейн состоит. А вывод на них работает путём отправки объектов синхронизации и ожидание их (в идеале, мы полностью пропускаем синхронизацию на СPU и отдаём эту задачу в GPU). На dri2 можно будет реализовать только подмножество этого механизма, а синхронизация будет эмулироваться на CPU.

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

Потому что у иксов всегда был свой иксовый драйвер для каждой видюхи, а потом стали продвигать вейланд, у которого куча серверов, значит нужно делать единый драйвер, чтобы во всех серверах это работало. Сделали DRI3, modesetting. Это такой промежуточный вариант, но если есть единый сервер, то он не нужен.

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

Ещё один, кому 255 кодов не хватило, а всем нормальным людям хватило.

Так хватило, что надо изворачиваться, чтобы некоторые клавиши заработали.

Кстати, в винде тоже, но там другое поведение, при нажатии на скриншот - просто закрывается попап.

Но тут же открывается обратно, так что в итоге работает.

которую предлагали в виде спеки к иксам с нормальной системой прав, а на деле оказалась никому не нужна.

Можно не сомневаться, что там было что-то непригодное для использования нормальными людьми.

Что это?

Это когда не тормозит. Непривычно после пятнадцати лет на Xorg!

…и в африке VSync

Мне нет дела до Африки, соррян.

Можно, но он бесполезен на десктопе.

Обычный случай «не работает, значит не нужно». Нужно. И даже работает на иксах, но так, что действительно ну его.

В иксах тоже есть механизмы для этого.

О, там много для чего есть механизмы. Просто почему-то их никто не хочет использовать. Странно! 🤔

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

А я здесь и не говорю, что wayland это плохо - это открытая тема для холиваров в других разделах. Но тема топика вполне ясная - иксы и не доделанный проткол в них. Да, Keith Packard хотел сделать, но всё спустилось на тормозах. Отчасти возможно проблема в самом протоколе composite - сама идея определять текстуру окна через pixmap, а не какой-нибудь surface изначально была неправильной.

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

А я здесь и не говорю, что wayland это плохо

Вейланд - это не просто плохо, это архитектурный писец. Каких бы фич не достовало бы в иксах (ИМХО там всех фич хватает), никакими киллерфичами - этот писец оправдать нельзя. Wayland - это буквально как не надо делать архитектуру, ЧСХ она делалась для одного DE и уже как 15 лет не может нормально взлететь. Её осилят только megaDE, которые буквально делают свою операционную систему и киоски вроде Hyprland-а, где никаких десктопных фич нет, и то как осиливают, до сих пор Wayland - глюкодром на аццких костылях.

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

Может у тебя в конфиге что-то не так?

Ибо я делал просмотрщик картинок на dri3 и делал его в том числе на intel:

https://git.disroot.org/mittorn/ImageViewer

И да, dri3 функции срабатывают успешно.

А сделать его на dri2 без GBM/opengl/vulkan так и не получилось - dri2 просто не предоставляет нужной функциональности. Мне нужна была линейная текстура, в которую декодер картинки будет писать данные в реальном времени. В dri3 я могу выделить её через dumb buffer и отправить в иксы. В dri2 мне иксы отдают тайловую текстуру, которую если и получается замаппить, я даже не знаю каким образом она затайлена - это непрозрачная текстура сделанная под конкретную реализацию opengl/gbm и ничего больше. Но на amd просто маппинг не срабатывает

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

Если что, в той же Японии обычные клавиатуры, просто набор иероглифов делается иным способом.

Это тут ни при чём. Открой список известных кодов клавиш в ядре и подумай.

anonymous
()