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

понаставлю vkWaitDeviceIdle везде

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

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

DWM

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

anonymous
()

https://keithp.com/blogarchive/../blogs/Present-redirect-lifetimes/
https://keithp.com/blogarchive/../blogs/Present-pixmap-lifetimes-part-deux/
В принципе, если использовать dri3 и сразу получать fd пиксмапы - больших проблем не должно быть - ведь lifetime dmabuf больше чем pixmap.
Однако в таком случак композитору не понятно, когда удалять созданные текстуры. Конечно создавать и удалять их налету будет неэффективно, да и пересылать через иксы всё тоже.
С destroy/idle notify будут работать существующие реализации opengl/vulkan, но не очень эффективно т.к всё будет пропускаться через иксы.
Для explicit sync придётся расширить протокол редиректа (посмотрел какие иксы в системе - там explicit sync всё ещё нет).
В принципе, можно это реализовать, но нормально будет рабоать только для gl композиторов. А им всё равно надо управлять ресурсами - видимо потребуется какая-то хэшмапа для текстур, но это, видимо, всё, что можно сделать в рамках существующей реализации present.
В случае же если расширять протокол со стороны mesa, можно всё заметно оптимизировать. Можно объединить пиксмапы, участвующие в свопчейне в единый объект.
Для vulkan со стороны mesa уже имеется объект свопчейна:
https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/vulkan/wsi/wsi_commo...
Для opengl понадобится что-то переделать т.к он не аллоцирует все нужные буфферы заранее и может их добавлять/удалять - при этом свопчейн логически пересоздаётся, либо же можно добавить в проткол команды удаления и обновления текстур.
https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/frontends/dr...
Свопчейн создаёт compositor connection. Если композитора нет - свопчейн не создаётся, работает обычный present.
compositor connection может создаваться через socketpair. Композитором может быть как иксовый клиент, так и реализация Xwayland или даже самого wayland - его протокол не должен оперировать объектами x11. Вместо этого он оперирует индексами изображений в swapchain. Connection со стороны mesa можно создавать и пересоздавать при PresentConfigureNotify. Закрытие connection приводит к удалению текстур на композиторе и отрисовки им pixmap'ы обычного окна Перед этим по хорошему кто-то должен скопировать текущий кадр обратно в window, например, client перед закрытием делает обычный PresentPixmap. Приложение при потере соединения с комопзитором делает обычный Present, а открывает connection только при повторном configure.
Под вопросом остаётся то, как передавать fence и sync object'ы в протколе swapchain connection, Возможно для fence тоже нужно использовать индексы, но ничего не запрещает приложению спользовать каждый раз какие-то новые фенсы/семафоры.
Нормально ли будет каждый раз их остылать дескриптором?
Индесы в swapchan могут передаваться в данных. Композитор может опрашивать все подключения через poll и читать в неблокирующем режиме каждый кадр, и оповещать о завершении после рендеринга.
Что делать с wait sync object? В случае с present flip нас интересует одно приложение, мы можем задержать весь рендеринг, но в остальных случаях - нет.
Композитор может поставит в ожидание все барьеры на cpu (отдельные потоки?), но не может поставить gpu в ожидание семафор - ведь это задержит всю остальную отрисовку. Используются ли семфоры в dri3 explicit sync?
В общем, explicit sync создаёт тут пока много вопросов. Без него вроде всё выглядит более-менее понятным.

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

Wayland — это не просто протокол. Это протокол, имеющий эталонную реализацию, libwayland, генерируемую в сишный код (клиента и сервера) из XML–описания протокола.

Поскольку wayland создавали те, кто раньше пилил иксы, то и эта фишка — появилась напрямую из основной идеи libXCB. Правда, тогда пришлось мучаться и собирать описание протокола (для автогенерации клиентской библиотеки) из бескрайней горы костылей непосредственной реализации X–сервера. А в wayland уже описание протокола первично с самого начала.

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

Не удивлюсь если причина потери производительности на ровном месте если включен композитинг схожа, особенно в оконном режиме. Речь конечно про невидию и dri3 там нет, но у меня ещё с давних времён осталась привычка конфигурировать Kwin так, чтобы он отключал свой композитор как только запускается какая-нибудь игра.

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

Нет, ты уроки делай.

Емаральды-Берилы-Компизы-Пикомы − единственное конкурентное преимучество десктопных линуксов в принципе над любыми операциоными системами своего класса прогаммного обеспечения

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

да даже просто заменяемые оконные менеджеры. В случае с wayland заменить можно только весь дисплейный сервер сразу, это слишком топорно, хоть и проще архитектурно Да, отзывчивость выше, если не надо ждать отклика отдельного процесса композитора/wm, но на этом преимущества и заканчиваются. В принципе если бы wm и композитор грузились как модули в иксы, это может быть и лучше бы было (но опять же падение композитора или wm в таком случае опять бы роняло сессию)

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

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

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