Оптимизация ядерной графики

Kernel-side graphics support

POLL Ваше мнение об оптимизации GUI ядра

Total votes: 68
Оставить как было
24%
16
Убрать только CGA и VGA, оставить VESA1.2
7%
5
Оставить только VESA2-режимы (без изменения)
10%
7
Разделить 24 и 32bpp графику в условно-компилируемые блоки
26%
18
Оставить в ядре единственный 32bpp-режим
32%
22

  • Скажу честно - проголосовал за п.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 идет независимо от остального А-кода и может быть легко вставлена в транк
    Евангелие от Иоанна: стих 1

    Code: Select all

    ; В начале было Слово:
    B32:        mov     ax, os_stack       ; Selector for os
    [/size]
  • Проголосовал за п.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), или я что-то не улавливаю?
    Какой тест можно запустить из Колибри, чтобы увидеть, что скорость медленная?
  • Who is online

    Users browsing this forum: No registered users and 2 guests