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)
Ответ на: комментарий от Merionet
To implement the HWC:

    Implement a nonoperational HWC and send all composition work to GLES.
    Implement an algorithm to delegate composition to the HWC incrementally. For example, delegate only the first three or four surfaces to the overlay hardware of the HWC.
    Optimize the HWC. This may include:
        Selecting surfaces that maximize the load taken off the GPU and sending them to the HWC.
        Detecting whether the screen is updating. If it isn't, delegate composition to GLES instead of the HWC to save power. When the screen updates again, continue to offload composition to the HWC.

То, о чём ты говоришь - третий пункт. А второй как раз про аппаратную имплементацию того, то wayland за редкими исключениями делает в opengl. Да, его можно пропустить, но у того же qualcomm есть blit engine и я подозреваю, что он задействован. А на мобилках с 4k экранами выгружать всё в gpu растеризатор - пустая трата энергии. Возможно разница в производительности не сильно заметна будет, только вот греться будет железо в разы меньше.

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

для поиска единомышленников

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

gaylord
()

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

Поможет, это уже реализовали в Qt.

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

Раз он может выводить картинку из декодированного видео без конвертации, значит, некоторые аппаратные штуки уже реализованы, он скейлит и преобразовывает формат с помощью специальных процессоров. Если обычный композитинг с множеством окон на столе грузит 3д, то он всё равно довольно эффективен, т.к. применяется damage tracking. Нужно ли применять для этого 2д - покажет время, в той статье тоже говорится о постепенном внедрении hwc. Вполне возможно, что это оставят так, из-за совместимости.

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

Реализовали только обработку падения композитора. А вот что произойдёт внутри клиента - ещё большой вопрос. Так, навскидку, если он продолжит вызывать opengl функции - получит сегфолт. Кстати говоря, решить проблему со стороны glamor или gl рендера в wayland композиторе скорее всего можно, обернув его в angle, который уже будет рисоваться через vulkan. Вроде как он умеет обрабатывать потерю рендерконтекста. Но какая там будет производительность - я боюсь предположить. к тому же что wayland что glamor понадобится обмениваться текстурами с gbm - не знаю, насколько это будет работоспособно

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

Реализовали только обработку падения композитора.

Нет. Реализовали переподключение клиентов.

Так, навскидку, если он продолжит вызывать opengl функции - получит сегфолт.

Все работает, уже вот прямо сейчас. Клиенты с акселерацией переподключаются, все хорошо. Это даже в SDL принесли:

We have all the stuff in the OpenGL context that doesn’t /need/ to get thrown away just because you’ve restarted - and a lot of toolkits didn’t do a good job of handling a context loss. I wanted the burden of work to be on the toolkit devs not application devs.

Ты какую-то проблему выдумал. GPU прекрасно работают что в играх, отрисовывая мне PDF. Единственные проблемы – это когда драйвер лялекса в очередной раз память портит, но к потере OpenGL контекста это не имеет никакого отношения.

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

Человек же в заголовке написал, что вопрос по иксам, и поставил соответствующий тег. Нет, набежали фанбои, замусорили тему.

Темы не существует, автор ничего не будет делать, будет ныть. Была куча времени придти в иксы и героически все починить. Никто этого не сделал, их закопали. Все, они мертвы. Напрочь. Окончательно. Бесповоротно. Выкинуты из роадмапа следующих версий Fedora, GTK и KDE. Выкинуты из релизящейся версии RHEL. Все. Приехали. Надо осознать реальность. Поезд ушел ещё пять лет назад, и все это время об этом кричали на каждом углу. Настало время похорон.

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

Ты путаешь падение композитора с падением GPU. Во втором случае приложения должны пересоздавать контекст. Однако когда последний раз я с этим экспериментировал - работало это только в vulkan, opengl же молча крашил gpu повторно из-за неверных данных в ib

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

Ты путаешь падение композитора с падением GPU. Во втором случае приложения должны пересоздавать контекст. Однако когда последний раз я с этим экспериментировал - работало это только в vulkan, opengl же молча крашил gpu повторно из-за неверных данных в ib

Так opengl на помойку вынесли. А падение GPU это настолько редкая проблема, что когда ты наконец-то разберешься как её починить с OpenGL, его закопают окончательно.

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

Автор уже реализовал dri3 фоллбэк без glamor. Но да, конечно пилить что-то в иксах, тем более изменение протолола, без опыта и коллективного мнения наверно как-то не совсем правильно. Нет, я наветно вкостыляю себе редирект в форк compton (уже сделан) и оставлю пару патчей в /etc/portage/patches, раз тут такая активная незаинтересованность…

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

Автор уже реализовал dri3 фоллбэк без glamor. Но да, конечно пилить что-то в иксах, тем более изменение протолола, без опыта и коллективного мнения наверно как-то не совсем правильно. Нет, я наветно вкостыляю себе редирект в форк compton (уже сделан) и оставлю пару патчей в /etc/portage/patches, раз тут такая активная незаинтересованность…

Да, все это никому не нужно. Потрать время с пользой, не насилуй труп.

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

opengl живее всех живых, vulkan просто не осиливают. Уровень неосиляторства вулкана варьируется от использования opengl до «я просто забью на валидацию и понаставлю vkWaitDeviceIdle везде», но оно и понятно, такое API требует особого подхода. Ну и первый вариант тут хотя бы работает

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

Выкинуты из роадмапа следующих версий Fedora, GTK и KDE. Выкинуты из релизящейся версии RHEL.

В списке кстати нет ничего из того, чем я пользуюсь, что очень характерно. Да, меня эти проекты волнуют даже меньше, чем другие ОС

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

В списке кстати нет ничего из того, чем я пользуюсь, что очень характерно. Да, меня эти проекты волнуют даже меньше, чем другие ОС

А зря, потому что все эти проекты иксы и пилили.

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

А иксы запилили и больше их пилить и не надо. Ну. Почти. Тред как раз про ту забытую недоделку, которую надо доделать. И работы здесь по сравнению с доведением wayland до того же состояния меньше в миллиард раз.

Я прекрасно понимаю что этотлучше было сделать раньше. Но я не пользовался композитином последние 10 лет и не знал об этой проблеме. Да, наверно если бы это всё начали обсужлать в 2015-2017 году активно - Keith бы что-нибудь придумал. Но нет, не было никаких обсуждений, а один аппаратно ускоренный blit обычно не создаёт заметного эффекта. К тому же этот эффект могли списать на недоработку композитора. Чисто случайно, реализовав софтовый фоллбэк, я наткнулся на ОХРЕНЕТЬ КАКУЮ регрессию производительности. Вот и появился этот тред.

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

А иксы запилили и больше их пилить и не надо. Ну. Почти. Тред как раз про ту забытую недоделку, которую надо доделать. И работы здесь по сравнению с доведением wayland до того же состояния меньше в миллиард раз.

Ну как бы надо, потому что их из тулкитов уже выпиливают :)

Я прекрасно понимаю что этотлучше было сделать раньше. Но я не пользовался композитином последние 10 лет и не знал об этой проблеме. Да, наверно если бы это всё начали обсужлать в 2015-2017 году активно - Keith бы что-нибудь придумал. Но нет, не было никаких обсуждений, а один аппаратно ускоренный blit обычно не создаёт заметного эффекта. К тому же этот эффект могли списать на недоработку композитора. Чисто случайно, реализовав софтовый фоллбэк, я наткнулся на ОХРЕНЕТЬ КАКУЮ регрессию производительности. Вот и появился этот тред.

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

gaylord
()
Ответ на: комментарий от gaylord
$ cd weston//                                                                 $ grep -nr vulkan .                                                                            ./.gitlab-ci/build-deps.sh:155: -Dgallium-drivers=llvmpipe -Dvulkan-drivers= -Dvideo-codecs= \ ./.gitlab-ci/debian-install.sh:84:      libvulkan-dev \                                        

Референсный wayland между прочим

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

Софт не заработает под иксами - я запущу его в weston/kwin/etc под иксами. Воросы?

Никаких вопросов нет, просто мне странно смотреть на это безумие. Ты правда не понимаешь почему пытаться в трех никому не известных человек вытащить технологию, которую признал мертвой весь линуксовый десктоп – бессмысленно?

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

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

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

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

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

Да нет, её дропнули в первую очередь задроты из wlroots, которые в соло затащили почти все полезные протоколы.

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

На кого?

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

RHEL, Fedora, etc…

Никто из этих людей Wayland не пилит. Там есть swick, но его вклад это обычно соавторство. По большей части Wayland пилят аутисты и Collabora. Чтобы RHEL замержил в гнум какие-то полезные протоколы обычно требуется аутичная бригада, которая три года старательно ноет им в багзиллу.

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

ку коль они ничего кроме fatpak не пилят - так к чему их вообще тогда вспоминать?

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

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

Чисто случайно, реализовав софтовый фоллбэк, я наткнулся на ОХРЕНЕТЬ КАКУЮ регрессию производительности.

Там случайно не используется чтение видеопамяти процессором? Если да, то это ОЧЕНЬ МЕДЛЕННО и не надо так делать. Надо сначала через GPU скопировать видеопамять в обычную память. Так оно работает довольно быстро.

В Haiku пока нет аппаратного ускорения вывода на экран, но есть экспериментальная поддержка рендеринга на новых Nvidia видеокартах. После рендеринга содержимое сейчас копируется в обычную память и выводится на экран програмно. И это выдаёт 1000+ FPS.

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

Не совсем. Используется gbm_bo_map с направлением трансфера на чтение. Запись идёт в dumb buffer, это может быть медленнее. Но это так же работает и без композитинга - ведь на экран тоже выводится dumb буффер. Может замена pixman_blt на memcpy исправит проблему, но я хочу в принципе избавиться от лишнего копирования там, где могу отдать в композитор текстуру напрямую. И под это даже протокол есть, но он так и не был реализзован. А с низкой производительностью uncached чтения я уже столкнулся, потому использую прямой маппинг только для записи. Регрессия производительности кстати есть только на intel, на amd это всё быстро работает. Но я опять же не хочу забивать проц лишним копированием

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

Падение GPU в AMDGPU происходит сплошь и рядом. И это зачастую баг в железе.

У меня AMDGPU, ничего не падает, кроме драйвера. А когда падает драйвер, падает ядро, потому что память портят. Слава б-гу вроде уже починили, и портить память он перестал.

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

Используется gbm_bo_map с направлением трансфера на чтение.

Если это делается для буфера в видеопамяти, то это оно самое. Надо запомнить как правило: мапить видеопамять для чтения нельзя, это очень медленно. Для записи мапить можно. Флаги трансфера GBM могут не помочь.

Вам по хорошему надо импортировать два буфера в OpenGL/Vulkan и сделать копирование через видеокарту.

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

О, интересно. Хороший ответ тем. кто тут писал, что dri3 не нужен. А так, все xorg драйвера для поддерживаемых main месой gpu и dri3 поддерживают, так что это не удивительно. Есть правда недоделки в виде сломанного exa в nouveau, но по моему опыту этот иксовый nouveau вообще давно сломан

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

это «по хорошему» может обернуться фиаско когда gpu зависнет. Но да, gbm в этом плане бесполезен - я не могу ему сказать, мол используй только трансфер.На amdgpu и iris gbm возвращает именно cpu копию. Но вообще я рассматриваю возможность сделать vulkan бэкенд для softdri3 вместо gbm - там я могу явно указать host_cached read/write и вместо ремаппинга вызыват flush. Мешает тут непонятка с drm modifier - в dri3 текстуры могут прилететь без указанного modifier и в vulkan их импортировать нельзя, не угадав его, gbm же с этим прекрасно справляется. Так же вулкан ничего не говорит о тайлинге и когда придёт затайленная текстура - придётся создавать copy command buffer. И я не знаю, что буде с маппингами, если gpu резетнется, что если все маппинги станут невалидными и прилетит SIGBUS? В общем, gbm тут пока что - самый близкий к этой задаче способ - он весь трансфер сам организует. А если видеопамять uncached - не должен её маппить напрямую. но на полноэкранном glxgears на интеле получается 40fps - это прям мало

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

Окстись, где ты там вообще увидел евангелизм в приведённой тобой ссылке?

Челик в теме по ссылке вместо того, чтобы взять адекватный и современный фреймворк (любой по вкусу и даже на самих иксах!) и быстро выполнить описанную им же задачу – какого-то хрена полез в протухшие потроха Xlib и решил ручками дёргать всякие XDrawLine.

Заметь, не я один и даже не я первый покрутил там пальцем у виска. Это просто совет (не только мой) по экономии времени ТС в той теме на которую ты оставил ссылку.

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

это «по хорошему» может обернуться фиаско когда gpu зависнет.

Там есть таймаут. Надо обрабатывать device lost и пересоздавать контекст.

Мешает тут непонятка с drm modifier - в dri3 текстуры могут прилететь без указанного modifier и в vulkan их импортировать нельзя, не угадав его, gbm же с этим прекрасно справляется.

По идее OpenGL должен импортировать любой буфер, поддерживаемый GBM, потому что в Mesa OpenGL и GBM реализованы тем же самым драйвером.

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

opengl - да. Но я пытаюсь отойти от opengl, так как иксы с glamor после резета иногда сегфолтят и с импортом в opengl произойдёт то же самое. Сам по себе gbm пока что не создавал проблем - только текстуры opengl окон иногда становились чёрными, что решалось уводом системы в suspend и обратно. В общем, если удастся подружить dri3 fds с вулканом гарантированно, чтобы для всех приложений работал, то можно попытаться на него переделать

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

почитал по ссылке - похоже, реализации exa столкнулись с похожими проблемами. Правда там, где есть exa - есть и возможность быстро скопировать pixmap, так что это решаемо, при условии что кто-то возьмётся за эти драйвера. Для amdgpu я нашёл относительно простой код копирования текстур через sdma, но во-первых не факт, что он будет работать на gfx10+, а во вторых он только для линейных, а для тайловых код будет сильно сложнее.
LINUX-ORG-RU, тебе тоже желательно посмотреть, как обстоят дела с dri3 на твоих GPU, если dri3 ломает ускорение, а dri2 выкидывают - код надо чинить, чем раньше - тем лучше.

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

А ведь, если исправить сабж, можно взять код 2д рендера из xf86-video-nouveau/ati/etc и реализовать на основе него клиентский аппаратно ускоренный композитор. Правда, это никак не моможет с ускорением иксовых вызовов отрисовки, но софт, рисующий всё на клиенте, будет быстро работать

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

Ты слишком высокого мнения о моих способностях. Но ради прикола попробую сесть и почитать исходники, только придётся читать много, от модуля ядра сквозь mesa сквозь иксы и обратно по вызовам. Там контекста мама не горюй и не факт что я вообще что-то пойму, точечно читать нет смысла, у меня пока в голове картина общего концепта логики взаимодействия подсистем на уровне реализации (а не бумажек) не родится, я беспомощный, так как визуал, мне надо буквально видеть проект в голове =).

Это из разряда, что происходит от нажатия кнопки, то появления символа на экране =)

Надо выделить время, чтобы понять как оно работает в реальности всё, а не абстрактно, на данный момент что там происходит после вызова glXSwapBuffers я понятия не имею, а там целая карусель карусель, начинаает рассказ, это сказки, песни и весееелье! :)

Но спасибо за информацию, может попробую…

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от LINUX-ORG-RU

Да не, надо просто врубить dri3 и посмотреть что будет для начала
P.S
https://bugs.freedesktop.org/show_bug.cgi?id=95475

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

, на данный момент что там происходит после вызова glXSwapBuffers я понятия не имею

Мне чтобы это понять наверно несколько лет понадобилось. Если не знать, где искать - код будет не понятен. С точки зрения gl/glx это чёрный ящик.
Для dri3 это Present, и он устроен сильно проще, чем dri2:
https://keithp.com/blogs/dri3_extension/
https://keithp.com/blogs/Present/
Итоговый протокол получился несколько сложнее, но суть в блоге описана.
Если коротко:
При создании окна приложение аллоцировало буфферы в виде dmabuf (kernel objects) и для каждого через DRI3 создало пиксмапу - у приложения теперь есть массив из Pixmap, каждый соответствует одной из opengl текстур. Всё это происходит внутри реализации opengl
При вызове SwapBuffers приложение отправляет последний отрисованный кадр через функцию PresentRegion. Так же передаётся барьер Idle, который сигнализируется, когда этот кадр можно снова использовать. В итоговом протоколе добавился барьер окончания рендеринга.
Иксы в этот момент если окно полноэкранное - отправляют эту текстуру прямо в drm на экран, если нет - копируют в back буффер туда, где рисуется окно. Вот здесь у тебя может быть сломано что-то со включенным dri3+EXA.
Со включенным композитором по идее иксы не должны копировать текстуру, а вместо этого отправлять PresentRedirectNotify в композитор. Вот это вот не было сделано, и на это я сейас бомблю тут. Потому что да, я не использовал комопзитинг последние 10 лет и о проблеме не знал.

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

Вот кстати пример использования present без gpu. dri2 так не может
https://gist.github.com/gnif/351bba74a5dfd29536b2b212d802540f
И вот пример, где я использую только dri3, без present, вместо этого render:
https://git.disroot.org/mittorn/ImageViewer/src/commit/b938da00f7574d3fdad2d0...
https://git.disroot.org/mittorn/ImageViewer/src/commit/b938da00f7574d3fdad2d0...
В проекте лежит неудачный эксперимент с попыткой сделать это на dri2, он не работает.

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