Оптимизация ядерной графики

Kernel-side graphics support

POLL Ваше мнение об оптимизации GUI ядра

Total votes: 68
Оставить как было
24%
16
Убрать только CGA и VGA, оставить VESA1.2
7%
5
Оставить только VESA2-режимы (без изменения)
10%
7
Разделить 24 и 32bpp графику в условно-компилируемые блоки
26%
18
Оставить в ядре единственный 32bpp-режим
32%
22

  • Serge
    Сложноватой получится проверка. И ещё одна проблема. Карта окон используется для определения окна в точке (x,y) и установки соответствующего курсора.
    Да, с курсором еще надо подумать как быть. Впрочем можно ограничить использование сменного курсора только на верхнее окно.

    С другой стороны это ведь пока только идея.
  • Mario wrote:в худшем случае придется просматривать все 255 слоев, а на каждый слой 4 проверки координат итого 256*4=1024 проверки на каждую точку.
    У меня нет 255 задач. И у тебя нет. И ни у кого нет. Тем более чтобы все были развернуты и что-то там себе рисовали.
    20-30 маленьких окошек реально перекрывают весь экран, т.е. просмотр потребует (пусть не в худшем, но в "очень плохом" случае) около сотни проверок.
    Скорость вывода отдельных пикселей не очень критична (если только буквы не рисуются попиксельно). Надо думать как нам пробить стену в скорости горизонтальной заливки (особенно для битмапов).
    Да, 20% ускорение в hline - это конечно хорошо.
    Но уже сейчас видно, что можно быстрее.

    И совершенно ясно, что кэш надо освобождать для более полезного груза. У меня, например, поток входных данных рвется при отрисовке картинки - проц буксует на простейшей выборке. И запрет кэширования таблицы конечно же не помог - рисование теперь просто засыпает.
    А ведь открыты-то всего 2-3 окна, здесь "больше/меньше" просто напрашиватся.
    Пока что никто не реализовал лучше. Особенно чтобы в тесте заметно было.
    Последний эксперимент (кэшируемая таблица, hline и vline вызываются через быстрый AMD-syscall с передачей параметров через стек)
    Результаты для транка - в крайнем правом столбце; в левом окне - баловство с закрытым окном (это то, чего можно достичь с двойной оконной буферизацией)
    Левый столбец правого окна - то, что уже реализовано. По-моему, очень даже заметно.
    Attachments
    TR.png
    TR.png (12.04 KiB)
    Viewed 5988 times
    Евангелие от Иоанна: стих 1

    Code: Select all

    ; В начале было Слово:
    B32:        mov     ax, os_stack       ; Selector for os
    [/size]
  • art_zh wrote:вызываются через быстрый AMD-syscall
    Ты опять говоришь о 20-30% парка электроники на которой может запускаться Колибри.
    "Что русскому хорошо, то немцу смерть." к\ф. Брат
  • Mario wrote:Ты опять говоришь о 20-30% парка электроники на которой может запускаться Колибри.
    Ну а что я могу поделать - только на них работает более-менее приличный syscall (правда тоже со своим приветом - ecx теряется). Видишь - сразу прирост скорости hline на 25%.

    Ну а если через int40 - тогда только на 20%.
    Но зато - для всех Колибри-машин с VESA2/32bpp-режимом.
  • На Атлонах sysenter есть. И на прежних моделях работает быстрее родного syscall.
  • Похоже, можно и из старой таблицы кое-что еще выжать.

    Я попробовал сделать графику с 8-пиксельной грануляцией.
    Все пиксели экрана группируются в тайлы (4х2), все окна выровнены по границе тайла (если не выравнены - ядро их выравнивает).

    Мышиную часть GUI уже отладил - окно (или граница рамки) подцепляется мышкой как раньше, но перемещается только на целое число тайлов. Никакого напряга для юзера при этом не наблюдается, окна и обои отрисовываются и раскрываются без глюков.

    Осталось довести до ума самое главное: переделать все обращения к оконной карте (их оказалось около 20) с пиксельной гранулярности на тайловую.
    Пока есть глюки.
    Фиксю.
    Ожидается заметный эффект при рисовании прямоугольников, рамок и битмапов.
    Но самое главное - размер таблицы сократился в восемь раз, кэш разгружен!

    Serge
    "быстрый syscall" - не потому что он быстрее чем sysenter, а потому что в А-версии дополнительные системные вызовы производятся по быстрой схеме - без двойной перегрузки контекста, с передачей/возвращением данных в стеке.
    Если такой финт можно реализовать с sysenter - давай попробуем вставить его в транк. Только вряд ли народ согласится. И вообще это разговор для другой ветки.
  • Mario wrote:
    art_zh wrote:Serge
    Еще раз проимхою свою мысль: попиксельная карта экрана - это идиотизм в клинической стадии, и кэширование этой таблицы только усугубляет проблему, а не снимает ее.
    Пока что никто не реализовал лучше. Особенно чтобы в тесте заметно было.

    В свое время Иван Поддубный переписал на пересылку DWORD и WORD, в Menuet вообще было побайтная пересылка - скорость возросла в 1,5-2 раза.
    http://blog.mikedld.com/2007/03/perform ... trunk.html
    (кстати, интересно, что текущие результаты тестов отстают по всем параметрам кроме последнего; может кто объяснит?)
    (EDIT: наверное, режим другой (32/24))
    in code we trust
  • mike.dld
    При всем прочем, то что ты делал было брошено более трех лет назад и недопилено. Вот как-то так...
  • Mike.dld
    Потрясающая скорость графики, быстрее чем у меня с перекрытым окном!
    И совершенно непонятно, почему наклонная линия рисуется в 6.5 раз быстрее горизонтальной ( 920 Мпс!! )?

    Что у тебя за платформа была 3.5 года назад -- с такой скоростью графического потока даже на транке?

    И еще - где можно найти хоть какую-нибудь документацию о gfx-ядре,- может я тут просто велосипед изобретаю?
    Attachments
    gfx_kernel_01.png
    gfx_kernel_01.png (6.27 KiB)
    Viewed 6015 times
  • Как и уточнил Марат, оно не было допилено. Наклонная линия рисуется так быстро (кстати, даже быстрее точки ;)) потому, что у неё нет реализации (то есть, она не рисуется). Функция рисования линии поддерживает только горизонтальный и вертикальный варианты; тем не менее, даже они в 1.5-2 раза быстрее тех, что рисуются с использованием пиксельной карты (несмотря на то, что я указывал те три года назад, что алгоритмы неоптимизированы). Не всё так гладко, собственно, но я всё ещё уверен (и навряд ли передумаю), что клиппинг - дело хорошее (с учётом того, что он предоставляет больше возможностей и требует, в большинстве случаев, меньше памяти в отличие от карты).
    Насчёт платформы - вроде бы была та же, что и сейчас (memberlist.php?mode=viewprofile&u=285).
    По документации. В ядро, как таковое, я изменений почти не вносил, работал в рамках vmode драйвера. Всё, что было наработано, есть на SVN (http://kolibrios.org/repos/kernel/branc ... nel/vmode/) и вроде как не особо трудное для понимания.
    in code we trust
  • mike.dld wrote:и вроде как не особо трудное для понимания
    Вот здесь ты несколько не прав - если что-то понятно самому реализатору (у него в мозгу уже выкристаллизовалась четкая картинка), то другому вникнуть надо сначала в идею, а потом еще и в код чужой. Между тем даже идея нигде не была толком описана. В личном разговоре ты мне помнится пытался объяснить, но я тогда так и не врубился. Из всего что я понял - рабочая область разбивается на прямоугольники, которые либо принадлежат какому-либо окну, либо принадлежат фону. Поскольку рабочих прямоугольников на пару порядков меньше чем пикселов, то данные о них занимают гораздо меньше места, но вот как проходит проверка я так и не вкурил.
  • Mario
    Ага, вроде в идею въехал, спасибо за разъяснение. А для проверки достаточно просто пробежаться по списку прямоугольников, закрепленных за данной задачей.

    Mike.dld

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

    Скоро закончу с тайлами (осталось только битмапы до ума довести) - там видно будет.
  • Перечитал тему и понял что не понимаю в чём смысл-то, выжимать графику на CPU, вместо GPU. Да, алгоритмы, опыт оптимизации, но в целом смысла я не догоняю.
    Кстати, а что делает xdamage? Или это вообще не оттуда? Ну и как работают линуховые драйвера vesa и fbdev, это не то?
    Да, в линухе я не шарю почти, не подумайте чего.
  • Nable
    Сейчас весь GUI находится в ядре, всем распоряжается CPU, а доступ к управлению железом предоставляется через VESA VBE-канал.
    Этот механизм простой, но довольно медленный и очень ресурсоёмкий.

    Сабж в сущности про то, есть ли эффективный способ его ускорить хотя бы на 30-50% (теоретический предел - в 2-3 раза), не ломая при этом ядро и не отвлекая еще бОльших системных ресурсов? Положительный ответ очень бы пригодился для видеоприложений, векторной графики и систем технического зрения (теперь у Колибри есть и такая работа).

    GPU никакого участия в процессе не принимает. Хотя в идеале, конечно, GPU мог бы выполнять 90-99% работы в GUI. У кого есть время и желание - попробуйте запустить радеоновский шейдер через мостик, который построил Serge. Но это будет только ATI- сервис; для Intel-графики еще никто не пахал, а к NV вообще не подступишься.
    Евангелие от Иоанна: стих 1

    Code: Select all

    ; В начале было Слово:
    B32:        mov     ax, os_stack       ; Selector for os
    [/size]
  • Who is online

    Users browsing this forum: No registered users and 0 guests