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 не может работать