Board.KolibriOS.org

Official KolibriOS board
It is currently Mon Sep 16, 2019 3:33 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 249 posts ]  Go to page 1 2 3 4 517 Next

Ваше мнение об оптимизации GUI ядра
Оставить как было 24%  24%  [ 16 ]
Убрать только CGA и VGA, оставить VESA1.2 8%  8%  [ 5 ]
Оставить только VESA2-режимы (без изменения) 9%  9%  [ 6 ]
Разделить 24 и 32bpp графику в условно-компилируемые блоки 26%  26%  [ 17 ]
Оставить в ядре единственный 32bpp-режим 33%  33%  [ 22 ]
Total votes: 66
Author Message
PostPosted: Fri Nov 19, 2010 3:41 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1342
Разговоров о выносе графической подсистемы из ядра за последние годы было много, да только 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.

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

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

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

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


Top
   
PostPosted: Fri Nov 19, 2010 4:58 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1342
Mario wrote:
1) Мне не нравится терять универсальность. Неизвестно заранее предположить где будет запущена операционка, если она на флешке.

EGA и флешка - вещи из непересекающихся пространств. VGA - да, можно оставить как условно-компилируемую rescue-версию для сбойных VESA-систем и эмуляторов. Но "оригинальные" VGA-машины тоже остались где-то там, в 80-х.
Mario wrote:
2) Чтобы не быть голословным относительно заявленного повышения в разы (во что я не сильно верю), нужны опыты и реально работающий код.
Голословным не буду, демка отлаживается. Но оценка "в разы" - вполне реальная, просто посмотри на код hline и сам увидишь.
Mario wrote:
3) Даже если переходить к оптимизации в виде -ну нужен код и его нет, то должны быть варианты. Выбросить код очень легко, зато потом кусать локти от его отсутствия очень неприятно. Тот-же Kolibri-A нигде кроме заявленной платформы не работает, со всеми вытекающими из этого последствиями.
Зачет. Скажу только, что оптимизация VESA идет независимо от остального А-кода и может быть легко вставлена в транк

_________________
Узкий специалист подобен флюсу: полнота его - односторонняя.
Козьма Прутков


Top
   
PostPosted: Fri Nov 19, 2010 5:04 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Проголосовал за п.4 и считаю что надо постепенно перейти к п.5. Не уверен, что оптимизация кода даст заметный выигрыш в быстродействии для дискретной графики.Там скорость прямой записи в видеопамять всего 130-150 Мб/с. Как на интеграшках не знаю, надо проверять.


Top
   
PostPosted: Fri Nov 19, 2010 6:26 pm 
Offline
User avatar

Joined: Mon Apr 16, 2007 6:38 pm
Posts: 1222
проголосовал за "Ошибка отправки формы. Попробуйте еще раз.", несколько раз.

_________________
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!


Top
   
PostPosted: Fri Nov 19, 2010 6:43 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Если кто-нибудь возьмётся за оптимизацию графики готов внести свой посильный вклад - сделать MMX/SSE2 версии.


Top
   
PostPosted: Fri Nov 19, 2010 6:55 pm 
Offline
User avatar

Joined: Thu Mar 01, 2007 4:16 pm
Posts: 426
> проголосовал за "Ошибка отправки формы. Попробуйте еще раз.", несколько раз.
Я тоже такой вариант выбрал.

..bw


Top
   
PostPosted: Fri Nov 19, 2010 8:17 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1342
bw wrote:
> проголосовал за "Ошибка отправки формы. Попробуйте еще раз.", несколько раз.
Я тоже такой вариант выбрал.

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


Top
   
PostPosted: Fri Nov 19, 2010 8:23 pm 
Я убрал галку - разрешить изменять ответ. Вероятно это является причиной проблем. Хотя у меня что в WinXP в Opera 10.53, что в ALT Linux KDE3.5 в Opera 10.10 проблем не наблюдается.


Top
   
PostPosted: Fri Nov 19, 2010 8:48 pm 
Offline
User avatar

Joined: Mon Apr 16, 2007 6:38 pm
Posts: 1222
Mario, не помогло. У меня тема оформления форума "Vanilla", а у тебя?
я думаю, дело таки не в версии Opera (у меня 11.0), или системы (Debian Sid)

_________________
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!


Top
   
PostPosted: Fri Nov 19, 2010 9:51 pm 
У меня стандартная тема оформления.


Top
   
PostPosted: Fri Nov 19, 2010 9:52 pm 
Offline
User avatar

Joined: Thu Mar 01, 2007 4:16 pm
Posts: 426
> У меня тема оформления форума "Vanilla"
Аналогично.

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

..bw


Top
   
PostPosted: Fri Nov 19, 2010 10:07 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Почесал репу, есть относительно несложный способ ускорить ввод/вывод аппаратной акселерацией при помощи shadowfb. Сейчас ядро отображает первичный видеобуфер на LFB_BASE. Драйвер создаёт в системной памяти текстуру размером в экран и ремапит её вместо видеопамяти. Ставится обработчик прерывания и на обратном ходе луча текстура блиттером копируется в видеопамять. Получаем ускорение на запись в 60 раз и три порядка на чтение (если нет проблем с кешированием). Видеоплеер будет очень рад. В этом случае оптимизация кода отрисовки даст очень хороший прирост.


Top
   
PostPosted: Fri Nov 19, 2010 11:07 pm 
Остается проверить на практике. Я так понимаю это только на Radeon?


Top
   
PostPosted: Fri Nov 19, 2010 11:21 pm 
Offline
Public Relations
User avatar

Joined: Mon Jun 07, 2010 12:01 pm
Posts: 1879
Так вроде и сейчас всё работает быстро (даже на тормозных компах типа Edubook), или я что-то не улавливаю?
Какой тест можно запустить из Колибри, чтобы увидеть, что скорость медленная?


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 249 posts ]  Go to page 1 2 3 4 517 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:  
cron
Powered by phpBB® Forum Software © phpBB Limited