Разговоров о выносе графической подсистемы из ядра за последние годы было много, да только 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." можно будет с чистой совестью убрать.
Оптимизация ядерной графики
-
Last edited by art_zh on Fri Nov 19, 2010 8:14 pm, edited 1 time in total.
Скажу честно - проголосовал за п.1
1) Мне не нравится терять универсальность. Неизвестно заранее предположить где будет запущена операционка, если она на флешке.
2) Чтобы не быть голословным относительно заявленного повышения в разы (во что я не сильно верю), нужны опыты и реально работающий код.
3) Даже если переходить к оптимизации в виде -ну нужен код и его нет, то должны быть варианты. Выбросить код очень легко, зато потом кусать локти от его отсутствия очень неприятно. Тот-же Kolibri-A нигде кроме заявленной платформы не работает, со всеми вытекающими из этого последствиями.
В общем я не против идеи оптимизации в принципе, но против поспешных секвесторских решений. Тем более что 5 Кб погоды не делают, даже для образа дискеты.
Если сделать грамотное разделение, то да это будет полезно.
З.Ы. Вензели VT нисколько не напрягают - он выложил их под GPL и потому никаких претензий быть не может.
1) Мне не нравится терять универсальность. Неизвестно заранее предположить где будет запущена операционка, если она на флешке.
2) Чтобы не быть голословным относительно заявленного повышения в разы (во что я не сильно верю), нужны опыты и реально работающий код.
3) Даже если переходить к оптимизации в виде -ну нужен код и его нет, то должны быть варианты. Выбросить код очень легко, зато потом кусать локти от его отсутствия очень неприятно. Тот-же Kolibri-A нигде кроме заявленной платформы не работает, со всеми вытекающими из этого последствиями.
В общем я не против идеи оптимизации в принципе, но против поспешных секвесторских решений. Тем более что 5 Кб погоды не делают, даже для образа дискеты.
Если сделать грамотное разделение, то да это будет полезно.
З.Ы. Вензели VT нисколько не напрягают - он выложил их под GPL и потому никаких претензий быть не может.
EGA и флешка - вещи из непересекающихся пространств. VGA - да, можно оставить как условно-компилируемую rescue-версию для сбойных VESA-систем и эмуляторов. Но "оригинальные" VGA-машины тоже остались где-то там, в 80-х.Mario wrote:1) Мне не нравится терять универсальность. Неизвестно заранее предположить где будет запущена операционка, если она на флешке.
Голословным не буду, демка отлаживается. Но оценка "в разы" - вполне реальная, просто посмотри на код hline и сам увидишь.Mario wrote:2) Чтобы не быть голословным относительно заявленного повышения в разы (во что я не сильно верю), нужны опыты и реально работающий код.
Зачет. Скажу только, что оптимизация VESA идет независимо от остального А-кода и может быть легко вставлена в транкMario wrote:3) Даже если переходить к оптимизации в виде -ну нужен код и его нет, то должны быть варианты. Выбросить код очень легко, зато потом кусать локти от его отсутствия очень неприятно. Тот-же Kolibri-A нигде кроме заявленной платформы не работает, со всеми вытекающими из этого последствиями.
Евангелие от Иоанна: стих 1[/size]
Code: Select all
; В начале было Слово:
B32: mov ax, os_stack ; Selector for os
Проголосовал за п.4 и считаю что надо постепенно перейти к п.5. Не уверен, что оптимизация кода даст заметный выигрыш в быстродействии для дискретной графики.Там скорость прямой записи в видеопамять всего 130-150 Мб/с. Как на интеграшках не знаю, надо проверять.
проголосовал за "Ошибка отправки формы. Попробуйте еще раз.", несколько раз.
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Если кто-нибудь возьмётся за оптимизацию графики готов внести свой посильный вклад - сделать MMX/SSE2 версии.
> проголосовал за "Ошибка отправки формы. Попробуйте еще раз.", несколько раз.
Я тоже такой вариант выбрал.
..bw
Я тоже такой вариант выбрал.
..bw
Странно, в firefox вроде работает, в винде проверил и в убунте.bw wrote:> проголосовал за "Ошибка отправки формы. Попробуйте еще раз.", несколько раз.
Я тоже такой вариант выбрал.
(мой вариант - 5-й - конечно не считается)
Я убрал галку - разрешить изменять ответ. Вероятно это является причиной проблем. Хотя у меня что в WinXP в Opera 10.53, что в ALT Linux KDE3.5 в Opera 10.10 проблем не наблюдается.
Mario, не помогло. У меня тема оформления форума "Vanilla", а у тебя?
я думаю, дело таки не в версии Opera (у меня 11.0), или системы (Debian Sid)
я думаю, дело таки не в версии Opera (у меня 11.0), или системы (Debian Sid)
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
У меня стандартная тема оформления.
> У меня тема оформления форума "Vanilla"
Аналогично.
> я думаю, дело таки не в версии Opera (у меня 11.0), или системы (Debian Sid)
Я так же считаю.
..bw
Аналогично.
> я думаю, дело таки не в версии Opera (у меня 11.0), или системы (Debian Sid)
Я так же считаю.
..bw
Почесал репу, есть относительно несложный способ ускорить ввод/вывод аппаратной акселерацией при помощи shadowfb. Сейчас ядро отображает первичный видеобуфер на LFB_BASE. Драйвер создаёт в системной памяти текстуру размером в экран и ремапит её вместо видеопамяти. Ставится обработчик прерывания и на обратном ходе луча текстура блиттером копируется в видеопамять. Получаем ускорение на запись в 60 раз и три порядка на чтение (если нет проблем с кешированием). Видеоплеер будет очень рад. В этом случае оптимизация кода отрисовки даст очень хороший прирост.
Остается проверить на практике. Я так понимаю это только на Radeon?
Так вроде и сейчас всё работает быстро (даже на тормозных компах типа Edubook), или я что-то не улавливаю?
Какой тест можно запустить из Колибри, чтобы увидеть, что скорость медленная?
Какой тест можно запустить из Колибри, чтобы увидеть, что скорость медленная?
Who is online
Users browsing this forum: No registered users and 1 guest