Board.KolibriOS.org

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) тупо отсутствует для нужной карточки. В связи с тем что жадные производители в свое время скрывали всю документацию, а некоторые до сих пор скрывают.

Я предлагаю удалить VESA1.2 совсем. Необходимость эмуляции VGA 16 и VGA256 тоже большой вопрос.

VGA лучше оставить - вдруг придется запускать на очень старой платформе, которая не держит VESA 2 и выше. Может со временем Колибри будет работать как роутер или как файл-сервер с использованием строго оборудования. Разумеется доступ через телнет и веб-интрерфейс могут решить проблему, но первичную настройку иногда приходится делать.

Железке должно быть лет 17. Это "вдруг" стремится к нулю. Стоит ли держать такой код в ядре. Это ещё и к VESA1.2 относится. Там код работает в одной единственной конфигурации.

C Vesa 1.2 я как раз согласен, но вот VGA код не так уж и много занимает, а работает на многих железках.

SVN r. 2407 - код работы с Vesa 1.2 закомментирован в файлах, которые ранее его использовали. Файл Vesa 1.2 я не стал удалять - может кому пригодится еще. Русскоязычное ядро уменьшилось на 1840 байт.

Процесс идет. Осталось допилить код блиттера (ф. 73 - недокументированная! может автор сам допилит? ), код меняющий отображаемый курсор и возможно VGA (если не надоест ломать голову над конверсией существующего кода).

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

Стандартное ядро, синтетический тест MGB:

Новое ядро с неморгающим курсором:

Итого как видим три самых первых показателя сильно провалились.
Однако на реальном приложении эффект не столь заметен. Шестеренки показывают 46 попугаев на стандартном ядре, и 30 на новом. Провал не в 2 раза, а в 1,5.
Разумеется это не конечная стадия работы с кодом, но сомневаюсь что удастся много выжать. Слишком велик для процессора штраф кэша, при пересылке данных из области Shadow buffer к области LFB.
Ну и на вкусненькое - десерт:

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

Запустил на реальном железе и чуть не прослезился от счастья. Оно прекрасно... Марат, молодец!
В Qemu, конечно, скорость упала заметно... но это лишь эмулятор. Реально ли сделать опциональное отключение этой фичи на голубом экране?

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

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

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

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

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

Мои тесты. Слева shadowfb, справа обычное ядро.
Разница на уровне погрешности измерения, то есть весь упор идёт в скорость записи.
Интересно проявляются отличия микроархитектуры.


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

Надо будет проверить на остальных компах. На Roverbook U800 видео встроенное в процессор AMD Geode LX800. Видео память соответственно выделяется из ОЗУ. Может из-за этого такое проседание. Впрочем на qemu приблизительно такое же проседание.

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

eBox-3300MX (Vortex86MX)

Стандартное ядро:

Ядро с не моргающим указателем мыши:

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

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

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

Serge т.е. ты тестировал не всю систему целиком. Я то в своих тестах ничего не перекрываю, и сравниваю попугаи при идентичных условиях отображения. А когда окно перекрыто другим, то в случае стандартного ядра оно вообще ничего ведь не пишет в LFB, там тупо отсечка по проверке через [_WinMapAddress]