Board.KolibriOS.org

art_zh

Хотя еще экономичнее в этом случае просматривать (на больше/меньше) для каждого окна его x1, y1, x2 и y2 - тут даже отдельная структура не нужна, координаты каждого окна известны. И работать будет явно быстрее, чем моя некэшируемая таблица

Насчет быстрее я бы не стал так однозначно утверждать. Потому что в худшем случае придется просматривать все 255 слоев, а на каждый слой 4 проверки координат итого 256*4=1024 проверки на каждую точку.

Только надо как-то эффективно проверять перекрытие окон - перетряхивать весь оконный стек?

В структуре которую я предложил это делается достаточно просто. Никакие слои друг с другом сравнивать не нужно. Просто перезаписать соответствующие биты при смене положения окна в стеке и все.

И потом, надо ведь не просто определить видимость одной конкретной точки (для этого, кстати, нынешняя таблица лучше всего приспособлена).

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

Serge

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

Да, с курсором еще надо подумать как быть. Впрочем можно ограничить использование сменного курсора только на верхнее окно.

С другой стороны это ведь пока только идея.

Mario wrote:в худшем случае придется просматривать все 255 слоев, а на каждый слой 4 проверки координат итого 256*4=1024 проверки на каждую точку.

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

И совершенно ясно, что кэш надо освобождать для более полезного груза. У меня, например, поток входных данных рвется при отрисовке картинки - проц буксует на простейшей выборке. И запрет кэширования таблицы конечно же не помог - рисование теперь просто засыпает.
А ведь открыты-то всего 2-3 окна, здесь "больше/меньше" просто напрашиватся.

Пока что никто не реализовал лучше. Особенно чтобы в тесте заметно было.

Последний эксперимент (кэшируемая таблица, hline и vline вызываются через быстрый AMD-syscall с передачей параметров через стек)
Результаты для транка - в крайнем правом столбце; в левом окне - баловство с закрытым окном (это то, чего можно достичь с двойной оконной буферизацией)
Левый столбец правого окна - то, что уже реализовано. По-моему, очень даже заметно.

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))

mike.dld
При всем прочем, то что ты делал было брошено более трех лет назад и недопилено. Вот как-то так...

Mike.dld
Потрясающая скорость графики, быстрее чем у меня с перекрытым окном!
И совершенно непонятно, почему наклонная линия рисуется в 6.5 раз быстрее горизонтальной ( 920 Мпс!! )?

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

И еще - где можно найти хоть какую-нибудь документацию о gfx-ядре,- может я тут просто велосипед изобретаю?

Как и уточнил Марат, оно не было допилено. Наклонная линия рисуется так быстро (кстати, даже быстрее точки ) потому, что у неё нет реализации (то есть, она не рисуется). Функция рисования линии поддерживает только горизонтальный и вертикальный варианты; тем не менее, даже они в 1.5-2 раза быстрее тех, что рисуются с использованием пиксельной карты (несмотря на то, что я указывал те три года назад, что алгоритмы неоптимизированы). Не всё так гладко, собственно, но я всё ещё уверен (и навряд ли передумаю), что клиппинг - дело хорошее (с учётом того, что он предоставляет больше возможностей и требует, в большинстве случаев, меньше памяти в отличие от карты).
Насчёт платформы - вроде бы была та же, что и сейчас (memberlist.php?mode=viewprofile&u=285).
По документации. В ядро, как таковое, я изменений почти не вносил, работал в рамках vmode драйвера. Всё, что было наработано, есть на SVN (http://kolibrios.org/repos/kernel/branc ... nel/vmode/) и вроде как не особо трудное для понимания.

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 вообще не подступишься.