Board.KolibriOS.org

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

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

Почему?

Сдается мне, дело не только в криворукости VT, но и в стремлении любой ценой сохранить совместимость с совершенно разными графическими платформами, включая реликтовый EGA, который уже четверть века назад, в эпоху пятидюймовых дискет и MS-DOS 3.3, считался устаревшим!

Я еще летом ради эксперимента выкинул из AMD-шной версии EGA и VGA режимы, ничего страшного не случилось. VESA1.2 также убралась без особых затруднений. Ядро при этом заметно (килобайт на 5) полегчало.

Наибольшие сложности - с оптимизацией VESA2. Посмотрите на код hline и vline - там всё намертво завязано на [putpixel]; в итоге при рисовании обычной рамки окна производятся тысячи ненужных операций умножения и десятки тысяч дублирующих проверок. Но если разделить коды для 24- и 32-bpp и выбрать что-то одно - тогда совсем другое дело:

1) реально достижимое ускорение отрисовки примитивов (линий, текста) - в разы; крупных объектов (рамки, фигуры) - в десятки раз.
2) код ядра можно сократить на 5-10%.
3) несколько жирных файлов с вензелем "(C) V.T." можно будет с чистой совестью убрать.

Скажу честно - проголосовал за п.1
1) Мне не нравится терять универсальность. Неизвестно заранее предположить где будет запущена операционка, если она на флешке.
2) Чтобы не быть голословным относительно заявленного повышения в разы (во что я не сильно верю), нужны опыты и реально работающий код.
3) Даже если переходить к оптимизации в виде -ну нужен код и его нет, то должны быть варианты. Выбросить код очень легко, зато потом кусать локти от его отсутствия очень неприятно. Тот-же Kolibri-A нигде кроме заявленной платформы не работает, со всеми вытекающими из этого последствиями.

В общем я не против идеи оптимизации в принципе, но против поспешных секвесторских решений. Тем более что 5 Кб погоды не делают, даже для образа дискеты.

Если сделать грамотное разделение, то да это будет полезно.

З.Ы. Вензели VT нисколько не напрягают - он выложил их под GPL и потому никаких претензий быть не может.

Mario wrote:1) Мне не нравится терять универсальность. Неизвестно заранее предположить где будет запущена операционка, если она на флешке.

EGA и флешка - вещи из непересекающихся пространств. VGA - да, можно оставить как условно-компилируемую rescue-версию для сбойных VESA-систем и эмуляторов. Но "оригинальные" VGA-машины тоже остались где-то там, в 80-х.

Mario wrote:2) Чтобы не быть голословным относительно заявленного повышения в разы (во что я не сильно верю), нужны опыты и реально работающий код.

Голословным не буду, демка отлаживается. Но оценка "в разы" - вполне реальная, просто посмотри на код hline и сам увидишь.

Mario wrote:3) Даже если переходить к оптимизации в виде -ну нужен код и его нет, то должны быть варианты. Выбросить код очень легко, зато потом кусать локти от его отсутствия очень неприятно. Тот-же Kolibri-A нигде кроме заявленной платформы не работает, со всеми вытекающими из этого последствиями.

Зачет. Скажу только, что оптимизация VESA идет независимо от остального А-кода и может быть легко вставлена в транк

Проголосовал за п.4 и считаю что надо постепенно перейти к п.5. Не уверен, что оптимизация кода даст заметный выигрыш в быстродействии для дискретной графики.Там скорость прямой записи в видеопамять всего 130-150 Мб/с. Как на интеграшках не знаю, надо проверять.

проголосовал за "Ошибка отправки формы. Попробуйте еще раз.", несколько раз.

Если кто-нибудь возьмётся за оптимизацию графики готов внести свой посильный вклад - сделать MMX/SSE2 версии.

> проголосовал за "Ошибка отправки формы. Попробуйте еще раз.", несколько раз.
Я тоже такой вариант выбрал.

..bw

bw wrote:> проголосовал за "Ошибка отправки формы. Попробуйте еще раз.", несколько раз.
Я тоже такой вариант выбрал.

Странно, в firefox вроде работает, в винде проверил и в убунте.
(мой вариант - 5-й - конечно не считается)

Я убрал галку - разрешить изменять ответ. Вероятно это является причиной проблем. Хотя у меня что в WinXP в Opera 10.53, что в ALT Linux KDE3.5 в Opera 10.10 проблем не наблюдается.

Mario, не помогло. У меня тема оформления форума "Vanilla", а у тебя?
я думаю, дело таки не в версии Opera (у меня 11.0), или системы (Debian Sid)

У меня стандартная тема оформления.

> У меня тема оформления форума "Vanilla"
Аналогично.

> я думаю, дело таки не в версии Opera (у меня 11.0), или системы (Debian Sid)
Я так же считаю.

..bw

Почесал репу, есть относительно несложный способ ускорить ввод/вывод аппаратной акселерацией при помощи shadowfb. Сейчас ядро отображает первичный видеобуфер на LFB_BASE. Драйвер создаёт в системной памяти текстуру размером в экран и ремапит её вместо видеопамяти. Ставится обработчик прерывания и на обратном ходе луча текстура блиттером копируется в видеопамять. Получаем ускорение на запись в 60 раз и три порядка на чтение (если нет проблем с кешированием). Видеоплеер будет очень рад. В этом случае оптимизация кода отрисовки даст очень хороший прирост.

Остается проверить на практике. Я так понимаю это только на Radeon?

Так вроде и сейчас всё работает быстро (даже на тормозных компах типа Edubook), или я что-то не улавливаю?
Какой тест можно запустить из Колибри, чтобы увидеть, что скорость медленная?