Может ли быть software rendering лучше hardware (сюда отнесу OpenGL) по задержке?

X512, мне кажется что ты знаешь ответ на эти вопросы.

Потому что каждая ненужная прослойка добавляет тормозов.

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

Вобщем, нужно только если метаданные окна (координаты и степень заслонения другими окнами) меняются чаще чем картинка в нём.

А software переключение чекбоксов по идее быстрее должно быть? Нужно всего то заполнить пару пикселей, а для hardware нужно либо заблитить отрендеренный чекбокс, либо перерисовать все окно сразу.

По задержке - почти наверняка будет лучше. Тоже это замечал.

На amdgpu-pro с композитором ux быстрый и хороший. На открытых amdgpu композитор на себя забирает много ресурсов, как-то хуже работает.

Без композитора включается glamor, который сам ускоряет окошки на 3d ускоритель.

Видимо, в gtk/qt есть спецэффекты, которые на твоем композитинге сбоят.

Видимо, в gtk/qt есть спецэффекты, которые на твоем композитинге сбоят.

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

Ну, попробуй разные композиторы. Я бы для чистоты эксперимента компиз откопал.

Может, если процессор будет писать напрямую в видеобуфер и будет успевать туда писать быстрее чем чем ты сдвигаешь что угодно на 1 пиксель.

Композитинг тормозит

Он не тормозит, просто вывод графики работает независимо. На отрисовку отправлено и всё, до свидания когда нарисуется тогда и нарисуется. Дабы внести однозначность да вводят промежуточные кадры мол пока не нарисуется следующий текущий выведен не будет. Композитинг имеет смысл тогда когда тебе надо с выводимыми данными на отрисовку ещё что-то сделать аппаратно, смешать текстуры для прозрачного заголовка или сделать анимацию какую. Если чисто прямоугольники таскать и тыкать то на CPU всё будет работать быстрее и отзывчивее просто по определению, конечно при условии что сам проц будет справляться.

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

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

Короче, смотря какой софтварь рендер и смотря какой композитинг и в каких условиях и то и это.

Чё его откапывать, он сейчас во всех репах из коробки вроде =) Оживили давно уже.

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

У меня i9, rtx 3060, я задержку очень хорошо вижу.

Если чисто прямоугольники таскать и тыкать то на CPU всё будет работать быстрее и отзывчивее просто по определению, конечно при условии что сам проц будет справляться.

Это ты имеешь виду, если будет прямой вывод в экранный буфер?

Пробовал эти - xfwm4, kwin, mutter, compiz, compton.

Я вообще не очень понимаю, зачем системному gui ускорение через opengl, как какой-нибудь 3d-игрухе. Неудели рисовать окошки с кнопочками это такая тяжелая задача? Пусть даже в 4k

Даже в FullHD перерисовка экрана без аппаратного ускорения - тяжелая задача. Можно увидеть, как он построчно рисуется.
Для того, чтобы увидеть настоящую работу без аппаратного ускорения, загрузите иксы с драйвером vesa.

Так аппаратное 2D ускорение выпилили из видеокарт, теперь приходится окошки рисовать черезжопно. А всё ради потребителя, который не отличает компьютер от плейстейшена.

Что за аппаратное 2D-ускорение?

Ну хз, в виртуалках через llvmpipe всё довольно шустро бегает.

Именно отзывчивость ui зависит скорее от input лага, т.к. современные тулкиты обрабатывают ввод на клиенте через raw input. Старые тулкиты обрабатывают ввод на стороне сервера, что делает xlib очень крутым в этом плане.

Аппаратная отрисовка для композиторов роли не играет, т.к. современный композитор работает с включенной v-sync. Т.о. на выхлопе задержка будет постоянной. Скорее пропуск кадра произойдет, но это для сложной логики(игры, например).

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

зачем системному gui ускорение через opengl

Так говнокода же полно, процессор тупо не справляется. Плюс ещё там могут системный gui реализовывать через JavaScript и CSS как в том же GNOME3

Потому что 2d ускорение из видеокарт выпилили много лет назад

Не некоторые, а после появления windows все. И ещё у них была аппаратная буферизация окон и аппаратный курсор мыши. А так как это похоже на технологию спрайтов из восьмибитных приставок... То к появлению оффтопика все были готовы

Не обязательно, я говорю про отсутствие прослойки в виде микро игрового 2D движка, очередей отрисовки искусственных в виде логики внутренней и промежуточных текстур MRT рендеринг и вот это всё =) Когда задача GPU принять битимапы и отобразить их. Но даже тут я лишь приблизительно говорю, реализаций и подходов миллион и для некоторых случаев мои текущие слова бредом являются.

Именно отзывчивость ui зависит скорее от input лага, т.к. современные тулкиты обрабатывают ввод на клиенте через raw input. Старые тулкиты обрабатывают ввод на стороне сервера, что делает xlib очень крутым в этом плане.

Raw input это какое api? Для мыши например. И почему xlib тут лучше, я наоборот вижу задержку в твоей версии с xlib, там raw input а тут какой сервер, хотя irl я вижу что xlib легче. Какой там путь получается?

Нет. Абсолютное большинство видеокарт поддерживало только маленькую часть возможностей, из всех тех вещей, ускорение чего закладывалось в дизайн оффтопа. Потому что на самом деле это все было не нужно уже тогда.
Ускорение всего подряд до последнего делали только упоротые из matrox, но мы знаем, чем это для них закончилось.

Raw input это какое api? Сейчас XInput2.2. https://www.x.org/releases/X11R7.7/doc/inputproto/XI2proto.txt.

У ati, в принципе, не сильно хуже было.

Может. Общение CPU <-> GPU не бесплатное. Простая графика будет работать намного отзывчевее на CPU.

Чтобы что-либо сделать на GPU надо:

1. Записать командный буфер.

2. Сделать системный вызов в ядро для планировки исполнения командного буфера на GPU.

3. Дождаться пока до командного буфера дойдёт очередь исполнения.

4. Дождаться прерывания от GPU о завершении исполнения командного буфера. Переслать это событие в userland.

Для CPU отрисовки достаточно напрямую записать в память фреймбуфера.

Композитинг тормозит из за того что окна выводятся в промежуточные буферы а потом копируются в итоговый?

Дополнительным фактором тормозов композитора является vsync так что отрисованное будет показано через 1/60 сек даже если оно нарисовано намного быстрее.

Неудели рисовать окошки с кнопочками это такая тяжелая задача? Пусть даже в 4k

Если с прозрачностью, тенями и анимациями, то да.

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

Проблема в тормознутости иксов, а не в VESA. Haiku работает намного быстрее с программой отрисовкой и VESA.

По-приколу прописал Option "AccelMethod" "none" для modesetting драйвера. Получил на встройке sandy bridge почти двукратное ускорение если верить gtkperf. Да и на глаз заметно. При этом композитор в xfce не отключал, в том числе vblank. Тиринг только в самой верхней строке экрана наблюдается, как обычно и бывает при софтовом композитинге. Так что выключение DRI реально помогает, а вот насколько влияет сам по себе композитинг не очевидно. Я особой разницы с ним и без него не вижу.

На поверхности 1920x1080 (RGB888) провел тестирование рисования линий из двух цветов, по случайным, но заранее заданным координатам. Участвовали со стороны Sofware: i9, i3. И со стороны hardware: rtx 3060, rx 570.

Software i9 draw 2000 lines
Full = 0.000595, DrawTime = 0.000534, Blit = 0.000061

NVIDIA GeForce RTX 3060 draw 2000 lines
Full = 0.000284, DrawTime = 0.000265, Blit = 0.000019

Software i9 draw 178000 lines
Full = 0.045695, DrawTime = 0.045656, Blit = 0.000039

NVIDIA GeForce RTX 3060 draw 178000 lines
Full = 0.011160, DrawTime = 0.011151, Blit = 0.000010



Software i3 draw 2000 lines
Full = 0.000815, DrawTime = 0.000796, Blit = 0.000019

AMD Radeon RX 570 draw 2000 lines
Full = 0.005255, DrawTime = 0.005228, Blit = 0.000027

Software i3 draw 178000 lines
Full = 0.060055, DrawTime = 0.060030, Blit = 0.000025

AMD Radeon RX 570 Series draw 178000 lines
Full = 0.020294, DrawTime = 0.020280, Blit = 0.000013

Композитинг тормозит из за того что окна выводятся в промежуточные буферы а потом копируются в итоговый?

Дополнительным фактором тормозов композитора является vsync так что отрисованное будет показано через 1/60 сек даже если оно нарисовано намного быстрее.

Так выключи его нахрен. Я в KWin сделал 4x частоту обновления и внезапно интерфейс стал отзывчивее. Композиторы всегда вносят задержку в один кадр, и на 60fps это заметно.