Asmxygen
Gitea
Builds
Bugs
FTP
Wiki
Telegram
Discord
Reddit
Похоже, можно и из старой таблицы кое-что еще выжать.
Я попробовал сделать графику с 8-пиксельной грануляцией.
Все пиксели экрана группируются в тайлы (4х2), все окна выровнены по границе тайла (если не выравнены - ядро их выравнивает).
Мышиную часть GUI уже отладил - окно (или граница рамки) подцепляется мышкой как раньше, но перемещается только на целое число тайлов. Никакого напряга для юзера при этом не наблюдается, окна и обои отрисовываются и раскрываются без глюков.
Осталось довести до ума самое главное: переделать все обращения к оконной карте (их оказалось около 20) с пиксельной гранулярности на тайловую.
Пока есть глюки.
Фиксю.
Ожидается заметный эффект при рисовании прямоугольников, рамок и битмапов.
Но самое главное - размер таблицы сократился в восемь раз, кэш разгружен!
Serge
"быстрый syscall" - не потому что он быстрее чем sysenter, а потому что в А-версии дополнительные системные вызовы производятся по быстрой схеме - без двойной перегрузки контекста, с передачей/возвращением данных в стеке.
Если такой финт можно реализовать с sysenter - давай попробуем вставить его в транк. Только вряд ли народ согласится. И вообще это разговор для другой ветки.
Оптимизация ядерной графики
http://blog.mikedld.com/2007/03/perform ... trunk.htmlMario wrote:Пока что никто не реализовал лучше. Особенно чтобы в тесте заметно было.art_zh wrote:Serge
Еще раз проимхою свою мысль: попиксельная карта экрана - это идиотизм в клинической стадии, и кэширование этой таблицы только усугубляет проблему, а не снимает ее.
В свое время Иван Поддубный переписал на пересылку DWORD и WORD, в Menuet вообще было побайтная пересылка - скорость возросла в 1,5-2 раза.
(кстати, интересно, что текущие результаты тестов отстают по всем параметрам кроме последнего; может кто объяснит?)
(EDIT: наверное, режим другой (32/24))
in code we trust
mike.dld
При всем прочем, то что ты делал было брошено более трех лет назад и недопилено. Вот как-то так...
При всем прочем, то что ты делал было брошено более трех лет назад и недопилено. Вот как-то так...
Mike.dld
Потрясающая скорость графики, быстрее чем у меня с перекрытым окном!
И совершенно непонятно, почему наклонная линия рисуется в 6.5 раз быстрее горизонтальной ( 920 Мпс!! )?
Что у тебя за платформа была 3.5 года назад -- с такой скоростью графического потока даже на транке?
И еще - где можно найти хоть какую-нибудь документацию о gfx-ядре,- может я тут просто велосипед изобретаю?
Потрясающая скорость графики, быстрее чем у меня с перекрытым окном!
И совершенно непонятно, почему наклонная линия рисуется в 6.5 раз быстрее горизонтальной ( 920 Мпс!! )?
Что у тебя за платформа была 3.5 года назад -- с такой скоростью графического потока даже на транке?
И еще - где можно найти хоть какую-нибудь документацию о gfx-ядре,- может я тут просто велосипед изобретаю?
- Attachments
-
-
gfx_kernel_01.png (6.27 KiB)Viewed 6035 times
Как и уточнил Марат, оно не было допилено. Наклонная линия рисуется так быстро (кстати, даже быстрее точки 
) потому, что у неё нет реализации (то есть, она не рисуется). Функция рисования линии поддерживает только горизонтальный и вертикальный варианты; тем не менее, даже они в 1.5-2 раза быстрее тех, что рисуются с использованием пиксельной карты (несмотря на то, что я указывал те три года назад, что алгоритмы неоптимизированы). Не всё так гладко, собственно, но я всё ещё уверен (и навряд ли передумаю), что клиппинг - дело хорошее (с учётом того, что он предоставляет больше возможностей и требует, в большинстве случаев, меньше памяти в отличие от карты).
Насчёт платформы - вроде бы была та же, что и сейчас (memberlist.php?mode=viewprofile&u=285).
По документации. В ядро, как таковое, я изменений почти не вносил, работал в рамках vmode драйвера. Всё, что было наработано, есть на SVN (http://kolibrios.org/repos/kernel/branc ... nel/vmode/) и вроде как не особо трудное для понимания.
) потому, что у неё нет реализации (то есть, она не рисуется). Функция рисования линии поддерживает только горизонтальный и вертикальный варианты; тем не менее, даже они в 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
Наверное, это действительно один из самых быстрых вариантов, по крайней мере для небольшого числа одновременно открытых окон.
Но имхо для ядра он слишком громоздкий. Да и допил я самостоятельно в реальные сроки не осилю.
Скоро закончу с тайлами (осталось только битмапы до ума довести) - там видно будет.
Ага, вроде в идею въехал, спасибо за разъяснение. А для проверки достаточно просто пробежаться по списку прямоугольников, закрепленных за данной задачей.
Mike.dld
Наверное, это действительно один из самых быстрых вариантов, по крайней мере для небольшого числа одновременно открытых окон.
Но имхо для ядра он слишком громоздкий. Да и допил я самостоятельно в реальные сроки не осилю.
Скоро закончу с тайлами (осталось только битмапы до ума довести) - там видно будет.
Перечитал тему и понял что не понимаю в чём смысл-то, выжимать графику на CPU, вместо GPU. Да, алгоритмы, опыт оптимизации, но в целом смысла я не догоняю.
Кстати, а что делает xdamage? Или это вообще не оттуда? Ну и как работают линуховые драйвера vesa и fbdev, это не то?
Да, в линухе я не шарю почти, не подумайте чего.
Кстати, а что делает xdamage? Или это вообще не оттуда? Ну и как работают линуховые драйвера vesa и fbdev, это не то?
Да, в линухе я не шарю почти, не подумайте чего.
Nable
Сейчас весь GUI находится в ядре, всем распоряжается CPU, а доступ к управлению железом предоставляется через VESA VBE-канал.
Этот механизм простой, но довольно медленный и очень ресурсоёмкий.
Сабж в сущности про то, есть ли эффективный способ его ускорить хотя бы на 30-50% (теоретический предел - в 2-3 раза), не ломая при этом ядро и не отвлекая еще бОльших системных ресурсов? Положительный ответ очень бы пригодился для видеоприложений, векторной графики и систем технического зрения (теперь у Колибри есть и такая работа).
GPU никакого участия в процессе не принимает. Хотя в идеале, конечно, GPU мог бы выполнять 90-99% работы в GUI. У кого есть время и желание - попробуйте запустить радеоновский шейдер через мостик, который построил Serge. Но это будет только ATI- сервис; для Intel-графики еще никто не пахал, а к NV вообще не подступишься.
Сейчас весь GUI находится в ядре, всем распоряжается CPU, а доступ к управлению железом предоставляется через VESA VBE-канал.
Этот механизм простой, но довольно медленный и очень ресурсоёмкий.
Сабж в сущности про то, есть ли эффективный способ его ускорить хотя бы на 30-50% (теоретический предел - в 2-3 раза), не ломая при этом ядро и не отвлекая еще бОльших системных ресурсов? Положительный ответ очень бы пригодился для видеоприложений, векторной графики и систем технического зрения (теперь у Колибри есть и такая работа).
GPU никакого участия в процессе не принимает. Хотя в идеале, конечно, GPU мог бы выполнять 90-99% работы в GUI. У кого есть время и желание - попробуйте запустить радеоновский шейдер через мостик, который построил Serge. Но это будет только ATI- сервис; для Intel-графики еще никто не пахал, а к NV вообще не подступишься.
Евангелие от Иоанна: стих 1[/size]
Code: Select all
; В начале было Слово:
B32: mov ax, os_stack ; Selector for ossvn =1859=
Залил новый графический движок - video/VESA20.inc полностью переделана и переименована в video/GRAPH32.inc .
В _putimage где-то еще сидит баг, отлавливаю.
Залил новый графический движок - video/VESA20.inc полностью переделана и переименована в video/GRAPH32.inc .
В _putimage где-то еще сидит баг, отлавливаю.
Евангелие от Иоанна: стих 1[/size]
Code: Select all
; В начале было Слово:
B32: mov ax, os_stack ; Selector for os1) Отловить бага в тайловой граф. системе так и не получилось. В #1930 временно вернулся к пиксельной карте экрана.
Хотя быстрая отрисовка битмапов все-таки была отлажена для режимов упаковки 32, 24, 8, 1 и 0bpp (последний режим соответствует заливке прямоугольника заданным цветом и позволяет объединить вместе функции _putimg и _drawbar).
Кого интересуют детали - см. http://redmine.kolibrios.org/projects/k ... raph32.inc
2) Я тут просмотрел что пишут в интернетах о Колибри. 90% чайников отмечают феноменальную бытроту графической подсистемы. Но есть вопрос: а насколько она быстрая?
Ради интереса, набил простенькую тестовую утилиту для Винды:
http://ftp.kolibrios.org/users/art_zh/gfx/gfxtst.exe
Сравнил с тестами в Колибри (см. стр.3-6 этой ветки). Призадумался.
Отключил драйвер видеокарты.
Вот результаты для VESA 1280х1024 в WinXP:(производительность считается по тактовой частоте CPU - в моем случае 3 ГГц)
Проверка получилась довольно неглубокая, но выводы можно сделать однозначные:
- Колибри выжимает из VESA-режима практически все, на что он способен.
- Эффективность ядерной графики в Колибри в разы выше, чем в VESA-винде.
- С современными GPU-ускорителями ядро КОС уже не может конкурировать.
Кто-нибудь сравнивал скорость отработки GUI-примитивов с Виндой и Иксами?
Хотя быстрая отрисовка битмапов все-таки была отлажена для режимов упаковки 32, 24, 8, 1 и 0bpp (последний режим соответствует заливке прямоугольника заданным цветом и позволяет объединить вместе функции _putimg и _drawbar).
Кого интересуют детали - см. http://redmine.kolibrios.org/projects/k ... raph32.inc
2) Я тут просмотрел что пишут в интернетах о Колибри. 90% чайников отмечают феноменальную бытроту графической подсистемы. Но есть вопрос: а насколько она быстрая?
Ради интереса, набил простенькую тестовую утилиту для Винды:
http://ftp.kolibrios.org/users/art_zh/gfx/gfxtst.exe
Code: Select all
425580 lines per second
166880 pixels per second
Proportional system txt, 34 chars: 23580 lines per secondОтключил драйвер видеокарты.
Вот результаты для VESA 1280х1024 в WinXP:
Code: Select all
11560 lines per second
29520 horiz. lines per second
14960 vert. lines per second
1008400 pixels per second
Proportional system txt, 34 chars: 2300 lines per secondПроверка получилась довольно неглубокая, но выводы можно сделать однозначные:
- Колибри выжимает из VESA-режима практически все, на что он способен.
- Эффективность ядерной графики в Колибри в разы выше, чем в VESA-винде.
- С современными GPU-ускорителями ядро КОС уже не может конкурировать.
Кто-нибудь сравнивал скорость отработки GUI-примитивов с Виндой и Иксами?
Last edited by art_zh on Sun May 15, 2011 5:31 pm, edited 1 time in total.
Иксы рисуются медленней. Больше уровней абстракций, плюс под Виндовс драйверы пилятся, строгаются и вылизываются куда тщательней. Хотя в случае VESA не все так однозначно. Очень сильно будет варьироваться от установленного GUI - XFCE, LXDE и прочее легковесное могут и обогнать в отдельных замерах.
-
yogev_ezra Public Relations - Posts 1879
- Joined: Mon Jun 07, 2010 12:01 pm
А в чём проблема написать под Колибри драйвер для GPU-ускорителя? Тогда ты уже не сравниваешь VESA vs GPU, а сравнишь GPU vs GPU...art_zh wrote:С современными GPU-ускорителями ядро КОС уже не может конкурировать.
yogev_ezra
...However, if you want to support high resolutions, you must write a driver for each graphics card that you want your OS to support. Only recommended if you have more than one life to waste.
(афоризм выдран отсюда)
...However, if you want to support high resolutions, you must write a driver for each graphics card that you want your OS to support. Only recommended if you have more than one life to waste.
(афоризм выдран отсюда)
-
yogev_ezra Public Relations
- Posts 1879
- Joined: Mon Jun 07, 2010 12:01 pm
Ты прав, но кто тебя заставляет писать драйвера для всех карт? Напиши для одной своей, и будет тебе счастье.art_zh wrote:yogev_ezra
...However, if you want to support high resolutions, you must write a driver for each graphics card that you want your OS to support. Only recommended if you have more than one life to waste.
(афоризм выдран отсюда)
Who is online
Users browsing this forum: No registered users and 1 guest