Board.KolibriOS.org

Official KolibriOS board
It is currently Sat May 30, 2020 9:30 pm

All times are UTC+03:00




Post new topic  Reply to topic  [ 249 posts ]  Go to page Previous 1 2 3 4 5 617 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: Wed Nov 24, 2010 4:09 pm 
Offline
Kernel Developer
User avatar

Joined: Thu Sep 03, 2009 1:52 pm
Posts: 1624
qemu при настройках по умолчанию эмулирует видеокарту Cirrus, не знающую про 32-битные видеорежимы - только 8-, 16- и 24-битные. Я считаю, что не стоит выкидывать код для 24-битного VESA2 - в том числе выкидывать из бинарного файла ядра условной компиляцией - по крайней мере, пока не будет 16-битного VESA2.

_________________
Сделаем мир лучше!


Top
   
PostPosted: Wed Nov 24, 2010 4:49 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1407
CleverMouse wrote:
qemu при настройках по умолчанию эмулирует видеокарту Cirrus, не знающую про 32-битные видеорежимы - только 8-, 16- и 24-битные. Я считаю, что не стоит выкидывать код для 24-битного VESA2 - в том числе выкидывать из бинарного файла ядра условной компиляцией - по крайней мере, пока не будет 16-битного VESA2.

Синьорита,
Вы дарите нашему занудному форуму всего пять с половиной слов в день,

(в среднем)
Но каждое Ваше слово - чистое золото!


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

(голосование и обмен мнениями продолжаются)


Top
   
PostPosted: Wed Nov 24, 2010 5:04 pm 
art_zh wrote:
о том и речь: реальное ускорение будет при буферизации оконной графики с последующим "построчным" копированием окна в главный фреймбуфер.
Нет блиттера - и movsd сгодится...

Пока несколько не понятно какой размер памяти стоит выделять под такую операцию. Выделять такой-же объем как сама отображаемая видеопамять - жаба давит.

Хотя с другой стороны именно так я в свое время ускорил запись в VGA режиме. Вернее там уже был буфер, но память записывалась попиксельно, а буфер использовался исключительно для операций чтения - возвращения 24-х битового значения точки. Учитывая, что для каждого цветового семпла приходилось устанавливать свой флаг, то запись производится в три захода для каждой точки. Если же записывать не одну точку в 4 бита а все 32 бита, то ускорение получилось значительное. А потом вообще реализовал запись областями. Т.е. запоминаются предельные границы измененного прямоугольника, они выравниваются на границу dword записываемого в VGA. Дальше копируется построчно весь блок.

В случае 24-х и 32-х битного режима для горизонтальной линии вероятно придется копировать непрерывный кусок в экран. Не сожрут ли накладные расходы по пересылке пустых dword получающийся прирост еще вопрос неопределенный. Может статься, что и овчинка выделки не окупит.


Top
   
PostPosted: Wed Nov 24, 2010 7:33 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1407
Mario
Да, если нет аппаратного ускорения (по крайней мере в виде пакетных пересылок данных), то из всей затеи выйдет пшик.
Или надо делать очень громоздкую проверку контента, чтобы не перегружать всё окно ради одной точки.

Serge
В версии 1710 я сделал экранную карту некэшируемой. В результате производительность графики упала в разы.
Особенно заметно замедление на 2-мерных примитивах: прямоугольник - в 20 раз, рисунок - в 24, окно - в 17.
Линии теперь рисуются с одинаковой скоростью: вертикальная - 13.9тыс линий в секунду (почти вдвое медленнее), горизонтальная -18тыс (но она на 30% короче), наклонная - 13700 (в ней больше точек).
Текстовый вывод замедляется почти в 4 раза, случайные пиксели - в 2.3 раза.

Так что дело все-таки не во write-combined буфере вывода, а в системном кэше, однозначно.
(кстати, в этом можно было убедиться и не ковыряя ядро - просто прогони тест MGB при разных видеорежимах - чем меньше точек, тем быстрее работает)


Top
   
PostPosted: Thu Nov 25, 2010 12:14 am 
Offline
Kernel Developer

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

Ну естественно. У тебя процессор просто встал на чтении карты. По одному байту за цикл. Некешируемая память - никакой предвыборки, запись и чтение строго упорядоченны. Скорость видеопамяти здесь уже не играет роли.
Attachment:
00.png
00.png [ 8.47 KiB | Viewed 2262 times ]
слева транк, справа видеопямять без write combining. Видно что сильнее всего просела hline со строго последовательным доступом. А теперь сравним:
vline 350*36981=12 943 350
hline 270*47656=12 867 120 - обе близко к результатам Single Pixel.
для сравнения write combining hline
139616*270*4 =143.8 Mb/c близко максимальной скорости записи.

Кстати после первого вызова hline и vline данные из оконной карты будут в кеше L2 и сравнительное влияние промахов кеша на скорость при последующих вызовах очень сильно уменьшится.


Last edited by Serge on Thu Nov 25, 2010 11:35 am, edited 2 times in total.

Top
   
PostPosted: Thu Nov 25, 2010 2:02 am 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1407
Serge
Да, предвыборка экранной карты может где-то помочь при выводе фигур, символов, горизонтальных и (возможно) наклонных линий, но это - малосущественные детали.

Главное - что эксперимент однозначно показал: основная причина всех задержек - это малоэффективная проверка попадания каждого пикселя в открытую область рисования. Там, где эти проверки можно минимизировать/кэшировать, скорость зашкаливает за 100 мегапикселей в секунду, тогда как совсем некэшируемые проверки тормозят процесс до 2-4 Мпс.

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


Top
   
PostPosted: Thu Nov 25, 2010 2:13 am 
art_zh wrote:
Serge
Еще раз проимхою свою мысль: попиксельная карта экрана - это идиотизм в клинической стадии, и кэширование этой таблицы только усугубляет проблему, а не снимает ее.

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

В свое время Иван Поддубный переписал на пересылку DWORD и WORD, в Menuet вообще было побайтная пересылка - скорость возросла в 1,5-2 раза.


Top
   
PostPosted: Thu Nov 25, 2010 2:22 am 
Offline
Kernel Developer

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

Вот как раз однозначно и не показал. Смотри мои результаты выше. hline с транка практически упирается в скорость записи для моей системы.


Top
   
PostPosted: Thu Nov 25, 2010 3:28 am 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1407
Serge wrote:
Вот как раз однозначно и не показал. Смотри мои результаты выше. hline с транка практически упирается в скорость записи для моей системы.

1)Ты убрал write-combining, и скорость hline села в 3 раза. Я убрал кэширование - падение в 21 раз. И какой эффект эффектнее?

2) мою hline-скорость после пляски с бубном удалось-таки поднять на 20% по сравнению с транком (см. скриншот на 3-й странице). И сдается мне, что это еще не предел.

Но опять-таки, это только для hline (и с оговорками - для некоторых горизонтально-заливаемых фигур). Только для них кэширование экранной карты имеет смысл благодаря очень высокому проценту попаданий. Отключи кэширование (при побайтной проверке таблицы) - и hline в точности сравняется в скорости с vline. Надеюсь, хоть с этим вы с Mario согласитесь ?

3) На всем остальном кэширование дает очень скромный прирост (в 2-4 раза) по сравнению с проверкой по некэшируемой байт-таблице. И это - на моторах с мегабайтыми кэшами! Чем короче кэш - тем скромнее фифект.

4) Но суть то и не в этом (ну казалось бы работает - и кэш с ним, пусть работает). Но ведь эта экранная карта занимает до 9Мб памяти, она даже в Феномовский кэш целиком не влезет. И даже во времена VGA не влезала (тогда кэшей таких не было). Значит, все разговоры о том, что ядро Колибри "почти целиком" сидит в процессорном кэше - пустая болтовня. Могло бы там сидеть, но его оттуда сдувает любое переключение окошка...

5) Может, и это оставим как оно есть?


Top
   
PostPosted: Thu Nov 25, 2010 10:46 am 
art_zh wrote:
5) Может, и это оставим как оно есть?

Не, хочу обидеть, но... :lol: я отписал об этом вероятно самым первым. :wink:


Top
   
PostPosted: Thu Nov 25, 2010 12:59 pm 
Offline
Kernel Developer

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

9 Мб ??? У нас таких режимов нет. _WinMapAddress - 1 байт на пиксель.
Quote:
3) Отключи кэширование (при побайтной проверке таблицы) - и hline в точности сравняется в скорости с vline. Надеюсь, хоть с этим вы с Mario согласитесь ?
Я не сомневаюсь, что сравняются. Обе намертво упёрлись в чтение из некешированной таблицы. Для процессора это жуткий тормоз. То есть с отключённым кешированием процессор еле выдаёт 4.8 мегапикселя в секунду.

Сделай тесты без проверки таблицы или вообще с прямым доступом к видеопамяти и ты получишь близкие результаты и для vline и для single pixel. Обе функции показывают максимальную скорость заполнения видеопамяти при произвольном доступе. И обе в неё упираются в обычном ядре.

Сравнительные результаты MGB для vline и hline в обычном ядре очень слабо зависят от кеша. После первого вызова функций все необходимые данные из байтовой таблицы будут в L1 кеше. 270 байт hline и 350*16 или 350*32 hline по сравнению 64 кБ L1 data на Атлонах совсем немного. В этих тестах процессор работает с максимально возможной скоростью и на 99.9% процентов не вылазит из L1 кеша. По этому разница в скорости заполнения vline и hline вызвана не промахами кеша, их там очень очень мало, а особенностями работы комбинированной записи.


Top
   
PostPosted: Thu Nov 25, 2010 2:46 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1407
Serge wrote:
9 Мб ??? У нас таких режимов нет. _WinMapAddress - 1 байт на пиксель.


пардон, 1920x1200 = 2 300 000. К феному в L3 может и влезет.

Serge wrote:
Сделай тесты без проверки таблицы или вообще с прямым доступом к видеопамяти и ты получишь близкие результаты и для vline и для single pixel. Обе функции показывают максимальную скорость заполнения видеопамяти при произвольном доступе. И обе в неё упираются в обычном ядре.

Байтовая карта экрана эффективно работает только для горизонтально-заливаемых линий / фигур. Но на негоризонтальных линиях, свободных пикселях и тексте процент попадания в кэш очень невысок, поэтому в обычном ядре ни vline, ни putpixel совсем не "упираются" в максимальную скорость.

Serge wrote:
Сравнительные результаты MGB для vline и hline в обычном ядре очень слабо зависят от кеша. После первого вызова функций все необходимые данные из байтовой таблицы будут в L1 кеше. 270 байт hline и 350*16 или 350*32 hline по сравнению 64 кБ L1 data на Атлонах совсем немного. В этих тестах процессор работает с максимально возможной скоростью и на 99.9% процентов не вылазит из L1 кеша. По этому разница в скорости заполнения vline и hline вызвана не промахами кеша, их там очень очень мало, а особенностями работы комбинированной записи.

Про hline - согласен. А вот для vline придется закачивать в кэш 350 строчек (в каждой кэш-строке 64байт, емнип), так что для полного кэширования одной-единственной vline-карты потребуется 350x64=22кбайт. Для случайных пикселей и текста все гораздо хуже: придется кэшировать карту всей области рисования. Хуже всего - при полнооконном рисовании, а также при перемещении/переключении окон - там кэш забивается дурными данными для всех видимых областей всех окон.

При этом сама 2мегабайтная таблица состоит из нескольких широченных полей, всю информацию из которых можно упаковать в 100-200 байт...
Если это не идиотизм, то что?

P.S. Вот еще пища для размышлений:

На ядре 1710 (с обескэшеной таблицей) я попробовал прогнать цифродробилку FHT.
Результат (время вычисления FHT по 1024 точкам) = 68533 плюс-минус 122 такта
с включенным кэшированием экранной таблицы : 68976 плюс-минус 487 тактов
замер проводился по 32 прогонам


Last edited by art_zh on Thu Nov 25, 2010 3:04 pm, edited 1 time in total.

Top
   
PostPosted: Thu Nov 25, 2010 3:00 pm 
art_zh wrote:
При этом сама 2мегабайтная таблица состоит из нескольких широченных полей, всю информацию из которых можно упаковать в 100-200 байт...
Если это не идиотизм, то что?

Я уже вообще запутался о какой таблице идет речь?

У нас ведь область используется для проверки какому окну принадлежит видимая точка.
Соответственно 1920*1200* 256 (глубина оконного стека) = 2,2 Мб. Как можно эту информацию упаковать в 100-200 байт? Даже если хранить только координаты окна и хитро высчитывать это получается уже 16 байт (4 dword координат, чтобы не терять время на всякие левые преобразования) на 256, итого 4 Кб. Однако у меня большие сомнения, что дополнительные вычисления для окон не съедят полученную прибыль от уменьшения размера области данных. Потому что придется также для каждой точки вычислять на лету все пересечения и наложения окон и придется это делать чаще, поскольку в текущем виде данные в области перерасчитываються лишь при изменении порядка окон в буфере.

Есть правда идея хранить только по Х и Y две области данных, что кстати будет значительно меньше.
1920 +1200 = 3120 байт. Однако это еще надо продумать.

З.Ы. Вообще-то требуется больше памяти - на каждую точку нужно 256 битное число, чтобы каждый бит отвечал за свой слой. В этом случае:
1920*32 + 1200*32 = 61440 + 38400 = 99840 байт или 97, 5 Кб. В общем около 100 Кб в противовес 2,2 Мб.


Top
   
PostPosted: Thu Nov 25, 2010 3:16 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1407
Mario
Я не говорю про 255 раскрытых окон (хотя даже и в этом случае на экране будут видны только 20-30 из них)

Типичный случай: на экране висят 3-4 окна (иконки и панель задач не счет).
Экранная карта в этом случае представляет собой массив из длинных цепочек одинаковых байтов, к тому же с очень высокой степенью повторяемости.

Прогони такую структуру через 7z - упакуется байт в 200, не больше


Top
   
PostPosted: Thu Nov 25, 2010 3:21 pm 
art_zh
Можно и без упаковки - если вспомнишь как реализуется доступ к матрице в цветомузыкальной установке например (пример из электроники). Я дописал пост после З.Ы.
Получается использование проецируемой трехмерной матрицы. Коду придется проверить установлены ли биты в текущем слое в обоих областях и есть ли до них биты в более верхних слоях.

С упаковкой проблема в том, что место динамически приходится выделять и освобождать , плюс сама распаковка делается не мгновенно. Так что в худшем случае будет кушать те-же 2 Мб.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 249 posts ]  Go to page Previous 1 2 3 4 5 617 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 2 guests


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