Board.KolibriOS.org

Official KolibriOS board
It is currently Sat Sep 19, 2020 4:06 pm

All times are UTC+03:00




Post new topic  Reply to topic  [ 249 posts ]  Go to page Previous 14 5 6 7 817 Next

Ваше мнение об оптимизации GUI ядра
Оставить как было 24%  24%  [ 16 ]
Убрать только CGA и VGA, оставить VESA1.2 7%  7%  [ 5 ]
Оставить только VESA2-режимы (без изменения) 10%  10%  [ 7 ]
Разделить 24 и 32bpp графику в условно-компилируемые блоки 25%  25%  [ 17 ]
Оставить в ядре единственный 32bpp-режим 33%  33%  [ 22 ]
Total votes: 67
Author Message
PostPosted: Fri Nov 26, 2010 1:50 am 
art_zh
Quote:
Хотя еще экономичнее в этом случае просматривать (на больше/меньше) для каждого окна его x1, y1, x2 и y2 - тут даже отдельная структура не нужна, координаты каждого окна известны. И работать будет явно быстрее, чем моя некэшируемая таблица

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

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

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


Top
   
PostPosted: Fri Nov 26, 2010 1:51 am 
Serge
Quote:
Сложноватой получится проверка. И ещё одна проблема. Карта окон используется для определения окна в точке (x,y) и установки соответствующего курсора.

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

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


Top
   
PostPosted: Sat Nov 27, 2010 3:17 am 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1412
Mario wrote:
в худшем случае придется просматривать все 255 слоев, а на каждый слой 4 проверки координат итого 256*4=1024 проверки на каждую точку.

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

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

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


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


Attachments:
TR.png
TR.png [ 12.04 KiB | Viewed 2939 times ]

_________________
Евангелие от Иоанна: стих 1
Code:
; В начале было Слово:
B32:        mov     ax, os_stack       ; Selector for os
Top
   
PostPosted: Sat Nov 27, 2010 3:48 pm 
art_zh wrote:
вызываются через быстрый AMD-syscall

Ты опять говоришь о 20-30% парка электроники на которой может запускаться Колибри.
Quote:
"Что русскому хорошо, то немцу смерть." к\ф. Брат


Top
   
PostPosted: Sat Nov 27, 2010 4:15 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1412
Mario wrote:
Ты опять говоришь о 20-30% парка электроники на которой может запускаться Колибри.

Ну а что я могу поделать - только на них работает более-менее приличный syscall (правда тоже со своим приветом - ecx теряется). Видишь - сразу прирост скорости hline на 25%.

Ну а если через int40 - тогда только на 20%.
Но зато - для всех Колибри-машин с VESA2/32bpp-режимом.


Top
   
PostPosted: Sat Nov 27, 2010 6:15 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
На Атлонах sysenter есть. И на прежних моделях работает быстрее родного syscall.


Top
   
PostPosted: Mon Nov 29, 2010 1:17 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1412
Похоже, можно и из старой таблицы кое-что еще выжать.

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

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

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

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


Top
   
PostPosted: Tue Nov 30, 2010 12:56 pm 
Offline
Site Founder
User avatar

Joined: Sun Aug 08, 2004 8:55 am
Posts: 690
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


Top
   
PostPosted: Tue Nov 30, 2010 1:27 pm 
mike.dld
При всем прочем, то что ты делал было брошено более трех лет назад и недопилено. Вот как-то так...


Top
   
PostPosted: Tue Nov 30, 2010 1:46 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1412
Mike.dld
Потрясающая скорость графики, быстрее чем у меня с перекрытым окном!
И совершенно непонятно, почему наклонная линия рисуется в 6.5 раз быстрее горизонтальной ( 920 Мпс!! )?

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

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


Attachments:
gfx_kernel_01.png
gfx_kernel_01.png [ 6.27 KiB | Viewed 2957 times ]
Top
   
PostPosted: Tue Nov 30, 2010 6:22 pm 
Offline
Site Founder
User avatar

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

_________________
in code we trust


Top
   
PostPosted: Tue Nov 30, 2010 8:22 pm 
mike.dld wrote:
и вроде как не особо трудное для понимания

Вот здесь ты несколько не прав - если что-то понятно самому реализатору (у него в мозгу уже выкристаллизовалась четкая картинка), то другому вникнуть надо сначала в идею, а потом еще и в код чужой. Между тем даже идея нигде не была толком описана. В личном разговоре ты мне помнится пытался объяснить, но я тогда так и не врубился. Из всего что я понял - рабочая область разбивается на прямоугольники, которые либо принадлежат какому-либо окну, либо принадлежат фону. Поскольку рабочих прямоугольников на пару порядков меньше чем пикселов, то данные о них занимают гораздо меньше места, но вот как проходит проверка я так и не вкурил.


Top
   
PostPosted: Fri Dec 03, 2010 3:44 am 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1412
Mario
Ага, вроде в идею въехал, спасибо за разъяснение. А для проверки достаточно просто пробежаться по списку прямоугольников, закрепленных за данной задачей.

Mike.dld

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

Скоро закончу с тайлами (осталось только битмапы до ума довести) - там видно будет.


Top
   
PostPosted: Sun Dec 05, 2010 4:38 am 
Offline
Just Flooding

Joined: Sat Jan 06, 2007 2:30 pm
Posts: 269
Перечитал тему и понял что не понимаю в чём смысл-то, выжимать графику на CPU, вместо GPU. Да, алгоритмы, опыт оптимизации, но в целом смысла я не догоняю.
Кстати, а что делает xdamage? Или это вообще не оттуда? Ну и как работают линуховые драйвера vesa и fbdev, это не то?
Да, в линухе я не шарю почти, не подумайте чего.


Top
   
PostPosted: Sun Dec 05, 2010 2:58 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1412
Nable
Сейчас весь GUI находится в ядре, всем распоряжается CPU, а доступ к управлению железом предоставляется через VESA VBE-канал.
Этот механизм простой, но довольно медленный и очень ресурсоёмкий.

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

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

_________________
Евангелие от Иоанна: стих 1
Code:
; В начале было Слово:
B32:        mov     ax, os_stack       ; Selector for os


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 249 posts ]  Go to page Previous 14 5 6 7 817 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited