Board.KolibriOS.org

Official KolibriOS board
It is currently Sun May 19, 2019 11:44 pm

All times are UTC+03:00




Post new topic  Reply to topic  [ 117 posts ]  Go to page 1 2 3 4 58 Next
Author Message
PostPosted: Fri Feb 24, 2012 10:53 pm 
SVN r. 2398 я справил количество выделяемой под Shadow buffer памяти в VGA режимах. Ранее выделялось аж 0x280000 (или 2621440) байт память для эмитации LFB. Буфер используется для ускорения работы с видео и чтобы было откуда считывать настоящие 24 бит (из 32-х бит верхние 8 не используются) цвета на точку, поскольку в VGA у нас только 16 и 256 цветов в зависимости от размера. Реальная потребность 640*480*4 = 1228800 байт плюс 32*640*4=81920 на курсор, который отрисовывается за экран. Итого 1310720 байт или 0x140000. Почему не сделана отсечка в нижней части для курсора мыши неизвестно.

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

У меня есть идея. В свое время я переделал для VGA систему копирования из области эмитирующей LFB в область собственно VGA. Раньше (как в Menuet) копирование было по точечное. Что при необходимости записывать значение каждого из трех цветов по отдельности, приводило к сильным тормозам. Сейчас в коде (написанном более 6 лет назад) копируется до 32 точки за раз для каждого цвета (т.е. 32 точки красной составляющей, 32 точки зеленой, 32 точки синей составляющей), если это не точечная запись навроде шрифтов и рисования линий. Точечная запись естественно осталось прежней. Напоминаю речь идет о старом VGA режиме с извратным способом доступа.

Поскольку написание драйвера для NVidia еще очень не скоро, а моргающий курсор в Vesa все же нехорошая вещь, и еще памяти в современных системах хоть жопой кушай, а в Колибри она не используется по большому счету. Потеря от силы 8 Мб памяти вряд ли будет сильно заметна. К тому же можно выделять только когда памяти достаточный запас.

Так вот идея сделать почти то же самое как для VGA, но еще и курсор не будет отключаться. Реально курсор будет висеть в настоящем LFB, а код будет записывать в область эмитирующую LFB и в саму LFB, но уже с учетом положения курсора, если записываемая точка попадает на курсор.

Из плюсов чтение из LFB (расположенного непосредственно в памяти видеокарты) в VESA гораздо медленней чем из ОЗУ основного. Соответственно из реальной памяти видеокарты считываться не будет вообще, туда будет только запись. Как тут на форуме уже выясняли товарищи разработчики - запись в память видеокарты в разы быстрее чем чтение из нее.

Как минус мы поимеем небольшое замедление (за счет удвоения записи), но оно должно нивелироваться полным отсутствием отключений и включений курсора.

Вероятно я не стану корректировать код Vesa 1.2. Поскольку таких видеокарт исключительно мало. Зачастую на большинстве из них приходится режим VGA включать, поскольку процедура переключения банков памяти (64 или 128 Кб окно доступа Vesa 1.2) тупо отсутствует для нужной карточки. В связи с тем что жадные производители в свое время скрывали всю документацию, а некоторые до сих пор скрывают.


Top
   
PostPosted: Sat Feb 25, 2012 12:18 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Я предлагаю удалить VESA1.2 совсем. Необходимость эмуляции VGA 16 и VGA256 тоже большой вопрос.


Top
   
PostPosted: Sat Feb 25, 2012 12:35 am 
VGA лучше оставить - вдруг придется запускать на очень старой платформе, которая не держит VESA 2 и выше. Может со временем Колибри будет работать как роутер или как файл-сервер с использованием строго оборудования. Разумеется доступ через телнет и веб-интрерфейс могут решить проблему, но первичную настройку иногда приходится делать.


Top
   
PostPosted: Sat Feb 25, 2012 1:37 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Железке должно быть лет 17. Это "вдруг" стремится к нулю. Стоит ли держать такой код в ядре. Это ещё и к VESA1.2 относится. Там код работает в одной единственной конфигурации.


Top
   
PostPosted: Sat Feb 25, 2012 1:42 am 
C Vesa 1.2 я как раз согласен, но вот VGA код не так уж и много занимает, а работает на многих железках.


Top
   
PostPosted: Sun Feb 26, 2012 3:37 am 
SVN r. 2407 - код работы с Vesa 1.2 закомментирован в файлах, которые ранее его использовали. Файл Vesa 1.2 я не стал удалять - может кому пригодится еще. Русскоязычное ядро уменьшилось на 1840 байт.


Top
   
PostPosted: Tue Feb 28, 2012 9:51 pm 
Процесс идет. Осталось допилить код блиттера (ф. 73 - недокументированная! может автор сам допилит? :wink: ), код меняющий отображаемый курсор и возможно VGA (если не надоест ломать голову над конверсией существующего кода).

На сегодня имею следующие тесты в "голом" Vesa2 на дохлом Roverbook U800 (до eBox руки не дошли пока протестировать).

Стандартное ядро, синтетический тест MGB:
Spoiler: Show
Attachment:
1.png
1.png [ 4.82 KiB | Viewed 3454 times ]

Новое ядро с неморгающим курсором:
Spoiler: Show
Attachment:
2.png
2.png [ 5.5 KiB | Viewed 3454 times ]

Итого как видим три самых первых показателя сильно провалились.
Однако на реальном приложении эффект не столь заметен. Шестеренки показывают 46 попугаев на стандартном ядре, и 30 на новом. Провал не в 2 раза, а в 1,5.
Разумеется это не конечная стадия работы с кодом, но сомневаюсь что удастся много выжать. Слишком велик для процессора штраф кэша, при пересылке данных из области Shadow buffer к области LFB.
Ну и на вкусненькое - десерт:
Spoiler: Show
Attachment:
kernel.7z [74.12 KiB]
Downloaded 112 times

И еще одно ограничение пока режимы выше 1024*768 не поддержаны, поскольку надо процедуру выделения памяти переделать.


Top
   
PostPosted: Tue Feb 28, 2012 11:26 pm 
Offline
Designer
User avatar

Joined: Thu Jan 25, 2007 3:33 pm
Posts: 5047
Запустил на реальном железе и чуть не прослезился от счастья. Оно прекрасно... Марат, молодец!
В Qemu, конечно, скорость упала заметно... но это лишь эмулятор. Реально ли сделать опциональное отключение этой фичи на голубом экране?

_________________
Через тернии к звездам


Top
   
PostPosted: Tue Feb 28, 2012 11:42 pm 
Offline
Designer
User avatar

Joined: Thu Jan 25, 2007 3:33 pm
Posts: 5047
Ну и ещё один момент. Сейчас стала ещё более заметна двойная перерисовка заголовка окна. А именно - вначале рисуется какая-то чёрная линия сверху, потом ниже серый фон, потом наверх накладывается картинка скина. Mario, ты можешь посмотреть в чём там дело?

_________________
Через тернии к звездам


Top
   
PostPosted: Tue Feb 28, 2012 11:52 pm 
Leency wrote:
Реально ли сделать опциональное отключение этой фичи на голубом экране?

Нет, это очень сложно. К тому же это раздует код ядра лишними процедурами. И к тому же это сложно - ах, да я это уже написал один раз. Да и называть фичей нехилую переделку процедуры отрисовки - это какбэ умалять достоинство данного запила.
Leency wrote:
Сейчас стала ещё более заметна двойная перерисовка заголовка окна. А именно - вначале рисуется какая-то чёрная линия сверху, потом ниже серый фон, потом наверх накладывается картинка скина. Mario, ты можешь посмотреть в чём там дело?

Записывай видео, комментируй и выкладывай на тытрубу в соответствующую тему. Опыт уже есть. Может это поможет увеличить количество попугаев в MGB.


Top
   
PostPosted: Wed Feb 29, 2012 1:40 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Мои тесты. Слева shadowfb, справа обычное ядро.
Разница на уровне погрешности измерения, то есть весь упор идёт в скорость записи.
Интересно проявляются отличия микроархитектуры.
Spoiler: Show
Attachment:
MGB.png
MGB.png [ 6.14 KiB | Viewed 3422 times ]


Update.
Вот нифига. И слева и справа shadowfb. Правильные результаты приведены ниже.


Last edited by Serge on Wed Feb 29, 2012 4:09 am, edited 1 time in total.

Top
   
PostPosted: Wed Feb 29, 2012 2:18 am 
Надо будет проверить на остальных компах. На Roverbook U800 видео встроенное в процессор AMD Geode LX800. Видео память соответственно выделяется из ОЗУ. Может из-за этого такое проседание. Впрочем на qemu приблизительно такое же проседание.

Serge, а ты точно не перепутал и не протестировал дважды одно и то же ядро?


Top
   
PostPosted: Wed Feb 29, 2012 3:02 am 
eBox-3300MX (Vortex86MX)

Стандартное ядро:
Spoiler: Show
Attachment:
1.png
1.png [ 4.87 KiB | Viewed 3412 times ]

Ядро с не моргающим указателем мыши:
Spoiler: Show
Attachment:
2.png
2.png [ 4.83 KiB | Viewed 3412 times ]

Шестеренки выдают 32 и 24 попугаев соответственно.


Top
   
PostPosted: Wed Feb 29, 2012 3:14 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Mario
Точно, самые интересные результаты я ещё не выкладывал. Запускаешь тест и сразу перекрываешь тестовое окно другим. Позволяет оценить скорость записи. В результате shadowfb в таком режиме работает немного быстрее обычного ядра. И для сравнения после нескольких тестов на обычном ядре Filled Rectangle: обычный тест 740, без отрисовки 48526. Разница 65,5 раз. Это ближе всего к реальным соотношениям производительности. Одиночный пиксель не показатель - тупо упирается в максимальное число прерываний в секунду. Примерно 1000 тактов на вызов даёт 3 миллиона. Чем больше тактовая частота тем лучше будет результат.

6Мb L3 кеша на SandeBridge рулят однозначно.


Last edited by Serge on Wed Feb 29, 2012 3:22 am, edited 1 time in total.

Top
   
PostPosted: Wed Feb 29, 2012 3:21 am 
Serge т.е. ты тестировал не всю систему целиком. Я то в своих тестах ничего не перекрываю, и сравниваю попугаи при идентичных условиях отображения. А когда окно перекрыто другим, то в случае стандартного ядра оно вообще ничего ведь не пишет в LFB, там тупо отсечка по проверке через [_WinMapAddress]


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 117 posts ]  Go to page 1 2 3 4 58 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