Board.KolibriOS.org

Official KolibriOS board
It is currently Mon Apr 06, 2020 7:37 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 249 posts ]  Go to page Previous 1 2 3 4 517 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: Sun Nov 21, 2010 3:46 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1402
Serge wrote:
Почесал репу, есть относительно несложный способ ускорить ввод/вывод аппаратной акселерацией при помощи shadowfb. Сейчас ядро отображает первичный видеобуфер на LFB_BASE. Драйвер создаёт в системной памяти текстуру размером в экран и ремапит её вместо видеопамяти. Ставится обработчик прерывания и на обратном ходе луча текстура блиттером копируется в видеопамять. Получаем ускорение на запись в 60 раз и три порядка на чтение (если нет проблем с кешированием). Видеоплеер будет очень рад. В этом случае оптимизация кода отрисовки даст очень хороший прирост.

А как насчет совсем сумасшедшей идеи - сделать много текстур размером с программное окошко (пользовательская область + рамка) каждая, и грузить блиттером только те "текстуры", в которых в течение последнего кадра имело место рисование/перемещение?
Я тут вижу три больших плюса и один огромный минус:

+ приложение просто рисует в своем индивидуальном "фреймбуфере", а ядро только предоставляет ему линейный адрес этого буфера - все остальные инструменты рисования (putpixel, drawline, drawbox ...) могут быть легко реализованы в Круге Третьем без потерь в скорости. И даже с заметным ускорением - не надо будет гонять int40 ради каждой ерунды.

+ программные задержки сокращаются (почти) до теоретического минимума за счет исключения цепочки тупых проверок и перепроверок (перекрытия окон, попаданий в границы экрана, и т.п.), которые сейчас съедают сотни тактов на каждом пикселе.

+ код GUI ядра становится простым как табуретка (во всяком случае, в сравнении с теперешним кошмаром), что должно положительно сказаться не только на скорости и размере, но и на общей надежности ядерных служб, а также на переносимости GUI на новые графические платформы.

- единый системный фреймбуфер сейчас требует максимум 9 Мбайт системной памяти (1920х1200х4). Если у каждого окошка будет свой отдельный фрейм, то системной памяти на всех может не хватить (крайний случай: 256 распахнутых на весь экран окон требуют больше 2Гб).


Top
   
PostPosted: Sun Nov 21, 2010 5:46 pm 
Offline
Kernel Optimizer
User avatar

Joined: Mon Jan 16, 2006 7:58 pm
Posts: 657
art_zh
Можно паковать в png изображения (без потери качества) или другой подходящий формат. Количество памяти значительно сократится. Однако, можно использовать такую методику:
1) Активное окно храниться в raw формате, как и последние 5 или 10 открытых окон. Менеджер предсказывает какое из окон может понадобиться пользователю и быстро преобразует png в raw. Конечно, память будет кушать, но все будет зависеть от потребности пользователя.


Top
   
PostPosted: Mon Nov 22, 2010 12:11 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
art_zh

Это на будущее. Сначала надо сделать стабильно работающий блиттер.


Top
   
PostPosted: Mon Nov 22, 2010 9:00 pm 
Offline

Joined: Wed Sep 15, 2010 7:22 pm
Posts: 101
Цитата: "Но в любом случае имхо назрел вопрос раздельной компиляции ядра для разных платформ. Так можно снять из ядра 30-40 килобайт ненужного кода и дублирующих проверок. И только так можно обеспечить эффективную работу системы на все более непохожих друг на друга платформах.

Наилучшим вариантом здесь мне видится аналог линуксовского config.h
"

Полностью с этим согласен.


Top
   
PostPosted: Tue Nov 23, 2010 2:16 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1402
Похоже, ЭТО всё, что можно выжать из того что есть.

Для горизонтальной/вертикальной линии из N точек число умножений уменьшено с 2N (3N в случае инверсии цвета) до 2, число проверок границ - с 3N до N+3.

Дальнейшее ускорение возможно только если опрокинуть всю оконную графику вверх тормашками, построив ее не на базе PUTPIXEL (как сейчас), а с прицелом на буферизацию GUI с последующей максимально быстрой отрисовкой отдельных окон (см. выше).

Serge
этот подход можно попробовать и без блиттера, с простым копированием отдельных оконных блоков в общий экранный фреймбуфер. Работы здесь прорва, но делать ее когда-нибудь все равно придется.

_________________
Узкий специалист подобен флюсу: полнота его - односторонняя.
Козьма Прутков


Top
   
PostPosted: Tue Nov 23, 2010 2:43 pm 
art_zh
Неплохо было бы видеть результаты полученные от тестирующей программы MGB, при текущем коде и при новом.


Top
   
PostPosted: Tue Nov 23, 2010 6:08 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
art_zh

Две проверки в основном цикле hline.draw на инверсию цвета и edi=1 не есть true coolhacker assembler style. Такой вариант:
Code:
bt ecx, 24
rcl edi, 1
jmp [hline.draw_table+edi*4]

.align 4
hline.draw_table:
dd .draw
dd .draw_negative
dd .draw_forced
dd .draw_forced_negative
Четыре цикла для разных вариантов отрисовки. Заметный выигрыш будет для развёрнутых циклов при отрисовке в системную память. Адреса циклов надо обязательно выровнять.


Top
   
PostPosted: Tue Nov 23, 2010 9:49 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1402
Serge

Офигеть! :shock:

P.S. Вообще-то я электронщик, и под кулхацкера никогда не косил. Хотя с вами тут совсем опрограммёришься...

Спасибо, учту!


Top
   
PostPosted: Tue Nov 23, 2010 9:54 pm 
Ну, мой личный опыт 8 лет радиокружка, плюс 2,5 года Слесарь КИП и Автоматики - какбэ не в счет. :lol:


Top
   
PostPosted: Tue Nov 23, 2010 10:12 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
art_zh

Я подумал что таким образом легко сделать код для разных режимов и расширений команд. Общий код с проверкой координат и отсечением, а дальше вызов или переход на функцию из таблицы с кодом для ALU, MMX, SSE2
Code:
bt ecx, 24
rcl edi, 1
shl edi, 2
add edi, [hline_draw_table]
jmp [edi]
или если есть свободный регистр
Code:
mov reg, [hline_draw_table]
bt ecx, 24
rcl edi, 1
jmp [reg+edi*4]
этом случае [hline_draw_table] хранит заранее установленный адрес одной из таблицы с учётом возможностей процессора.


Top
   
PostPosted: Wed Nov 24, 2010 3:54 am 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1402
Сделал, вроде все по-уму получилось.
Замерил бенчмарк и еще раз офигел:

Реально ускорилось (на 20%) только рисование горизонтальных линий. Все остальное - в пределах процента за счет незначительной оптимизации базовой процедуры putpixel.
Конечно, в сисфункции прирост скорости заметен меньше, чем в ядре, но все равно фифект не стоил выделки.
Платформа - та же rs780 с 3.4-гигагерцовым атлоном во главе. На таких моторах на одном умножении много не сэкономишь, особенно если память притормаживает...


Attachments:
File comment: слева - оптимизированная VESA #1708, справа - дремучий транк
MGB.png
MGB.png [ 8.5 KiB | Viewed 2252 times ]

_________________
Узкий специалист подобен флюсу: полнота его - односторонняя.
Козьма Прутков
Top
   
PostPosted: Wed Nov 24, 2010 5:03 am 
Offline
Kernel Optimizer
User avatar

Joined: Mon Jan 16, 2006 7:58 pm
Posts: 657
art_zh
Как проводил замеры? Обычно, проводят 10-20 замеров, получают среднее значение. Разброс не очень велик и по некоторым тестам находится в пределах погрешности измерений.


Top
   
PostPosted: Wed Nov 24, 2010 10:58 am 
art_zh
Не переживай, так достаточно часто бывает - оптимизируешь, а в результате прироста нет.
Основные тормоза возникают на делении, даже больше чем на умножении.


Top
   
PostPosted: Wed Nov 24, 2010 1:03 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1402
<Lrz>
На скриншоте конечно - два типичных измерения. Повторные замеры пляшут плюс-минус полкопейки.
Усреднять и вычислять дисперсию особого резона не было - эффект и в самом деле чуть выше погрешностей.
На старых CPU разница должна быть более заметна, но у меня сейчас VESA-графика допилена только для ядра-А (Атлон64 и выше), проверить не на чем.

Mario
Да я особенно и не переживаю, хуже-то ведь не стало :wink:
И тот факт, что современные монстры научились разгрызать целочисленное умножение за 2-3 такта, вовсе не означает, что оптимизация стала совсем бесполезной.
Так или иначе, для сложения требуется переключить несколько десятков вентилей, а для умножения - несколько сотен. Пусть два процесса занимают одно и то же время, но в первом случае будет потребляться значительно меньшая мощность - это реальная и нужная оптимизация.

Меня совсем другое заинтересовало: почему горизонтальная линия рисуется с такой дикой скоростью (100Мпикс/с) - в 15 раз быстрее, чем аналогичная по алгоритму вертикальная?

Насколько я помню, фреймбуфер у нас не кэшируется, и ему должно быть фиолетово, как в него пишутся пиксели - по строчкам или по столбцам.
Так что причина может сидеть только в проверке экранной карты [_WinMapAddress], в которой для каждой точки на экране прописана её оконная принадлежность.

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


Top
   
PostPosted: Wed Nov 24, 2010 1:14 pm 
art_zh wrote:
Меня совсем другое заинтересовало: почему горизонтальная линия рисуется с такой дикой скоростью (100Мпикс/с) - в 15 раз быстрее, чем аналогичная по алгоритму вертикальная?

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


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 249 posts ]  Go to page Previous 1 2 3 4 517 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:  
cron
Powered by phpBB® Forum Software © phpBB Limited