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

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

  • еле нашел по последней ссылке

    Code: Select all

        switch (ucColorDepth)
        {
            case 8:
                usVESAModeNum = pModePrivate->Mode_ID_8bpp;
                break;
    
            case 16:
                usVESAModeNum = pModePrivate->Mode_ID_16bpp;
                break;
    
            case 32:
                usVESAModeNum = pModePrivate->Mode_ID_32bpp;
                break;
        }
    так что у Ёгева претензий тоже не будет.
  • Всё верно, eBox тоже поддерживает 32 бита. Я тоже уже лет 10 не видел ни одного компьютера / монитора, который бы их не поддерживал.
    Я проголосовал за "Оставить в ядре единственный 32bpp-режим"
  • На всякий случай еще раз спрошу (может быть сути моего вопроса не уловили) - Что мешает вынести зависимую от глубины цвета (битности) часть кода в библиотеку/драйвер? Религия? Зачем ломать то что работает?
  • Mario
    На всякий случай повторюсь

    1) я сделал быстрый векторный аналог шрифта 0 (5х7) и тестирую еще 2 новых шрифта (7х9 и 9х12), все шрифты могут быть и моноширинными и пропорциональными. Эти шрифты будут (все вместе) весить меньше, чем нынешние два, и активироваться сразу после вхождения в страничный режим, еще до монтирования рамдиска (экранные логи, ага).

    2) парсер шрифтов насмерть завязан на 32bpp, переделывать его на 24bpp не хочу (и боюсь, что даже если захочу - не сумею).

    3) в принципе шрифты 0 и 1 можно будет использовать со старыми GUI-функциями, но для полного раскрытия их потенциала лучше добавить новые GUI-сервисы чтобы отрисовка не тормозилась старыми форматами.

    4) вывод текста будет еще быстрее, если рисовать в блиттере (не выходя из Ring3) с последующей отрисовкой всей картинки. Софтверный блиттер кривоват, но его очень легко можно "прям щас" соптимизировать на 32bpp, и на первом этапе пока даже GPU здесь не нужен, ускорение с заливкой через SSE будет мама не горюй. А для SSE нужно 16-байтное выравнивание.

    5) если кто возьмется повторить шаги 1) -4) на 24bpp - я буду просто счастлив. Но ведь никто не возьмется.

    6) ну и как будет выглядеть раздельно-компилированное ядро, в котором 32-битная графика летает, а 24 - ползёт? И кто будет разрабатывать софт под 2 разных (аппаратно-несовместимых) GUI?

    7) переход на 32битную графику облегчает ядро почти на 3кб и выносит из GUI-функций кучу тормозных проверок.
    В синем экране остаётся по большому счету только выбор разрешения экрана, который можно включить в батник компиляции ядра (вместе с выбором языка) и грузиться за 2 секунды.
    Last edited by art_zh on Fri Oct 12, 2012 6:17 pm, edited 2 times in total.
  • Делаю два вывода:
    1) Ломать не строить. Тем более альтернативы не предлагается никакой.
    2) Нам лень и вообще некогда решать проблему, но мы все равно
    Spoiler:
    Весь мир насилья мы разрушим
    До основанья, а затем
    Мы наш, мы новый мир построим, —
    Кто был ничем, тот станет всем.
    сломаем работающую систему (которая еще может пригодится некоторым людям) и не будем делать всякие бранчи.
    Логика непробиваемая конечно.
  • Теперь - о том, зачем оно мне надо и чего меня приперло транк потрошить.

    1) все понимают, что надо что-то менять в ядре по-крупному, и кое-кто пытается это что-то менять.
    Плохо то, что у каждого свои очень разные подходы. Ну и задачи тоже разные.
    Анархосиндикалистов переубеждать бесполезно, а убеждать - почти никогда не получается.
    Каждый сам знает как лучше. В результате старое ядро уже ни для чьих новых разработок не годится, легче новые велосипеды сочинять.
    И если ядро ничем не скреплять, то очень скоро мы единый Проект порвём как бобик грелку.

    2) а чем же его можно скрепить, чтобы еще хотя бы на год-два у всех разработчиков (и у прикладников в первую очередь!) появился общий интерес?
    - очевидно, чем-то таким, что будет очень полезно в каждой из новых веток, и что сейчас сильно у всех тормозит.
    Будет новая быстрая графика, более удобный и мощный GUI - всем станет интереснее работать, найдутся оригинальные решения старых заморочек.

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

    Вот как-то так, такая мотивация.

    3ы конечно если 2/3 против, то и хрен с ним, пусть как раньше.
  • art_zh wrote:3ы конечно если 2/3 против, то и хрен с ним, пусть как раньше.
    Тут пока что из высказавшихся как раз наоборот (не считая протухшее голосование) получается.
    У каждого конечно свои корыстные цели, но когда они тупо урезают даже на 5% поддерживаемое железо - мне лично очень не нравится. Вот придет человек новый и ему нужна будет поддержка именно этого, а у нас ее не будет. Мы ему посоветуемся пользоваться старьем или выбросить свою рухлядь. Очень правильные советы с точки зрения советующих, но абсолютно не приемлемые со стороны просящего.

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

    Как говорится ничего личного, только бизнес хобби. :|
  • art_zh wrote:И кто будет разрабатывать софт под 2 разных (аппаратно-несовместимых) GUI?
    Вот тут мне показалось, что есть некоторая натяжка. Прикладникам вообще должно быть пофиг на аппаратную несовместимость, если нужные функции наличествуют. Понятно, что где-то без деталей не обойтись, и 24-битное изображение придется считать по 3 байта, а не по 4. Но в чем, объясните мне, разница в выводе текста системной функцией? Не с твоей стороны как ядерщика, а с моей -- как прикладника? Ну, номер шрифта другой. Ну, размеры другие. И всё.

    Вначале нужно решить, как будет реализована поддержка новых шрифтов и предложить конкретный API. Вероятно, даже в двух вариантах -- с введением новых функций, и без них (если такое возможно). Еще перечислить поименно функции, которые будут затронуты оптимизацией. И разговор об условной компиляции сразу станет предметным.

    Если вдруг выяснится, что добавление шрифтов дает новый API, может оказаться логичным текущее ядро вынести в legacy -- выпустить его наконец-то как ветку 0.7.8, а самим сосредоточиться на транковой 0.8 -- уже с новым API. А любителям старины, соответственно, предлагать 0.7.8, и через какое-то время даже получить статистику о ее фактической популярности относительно 0.8.

    Если же в будущем хомячки внезапно начнут роптать об отсутствии 24-битной графики, -- что же, это новая реальность, которую придется осознавать заново, уже имея полноценные шрифты. К тому времени и практика по ним наработана будет, и полезность доказана, и всё остальное. Тогда-то и станет ясно, то ли портировать новые фишки из 0.8 в legacy-ветку, то ли наоборот, логичней и проще напрячься и вернуть поддержку 24-битной графики в 0.8. Ну, или будет некому, как обычно.

    А без развития и выпуска новых версий -- никуда, только в сторону. Пример с Miranda NG показателен.
  • Ребяты, поддержу Freeman'а. Сам обещаю вернуться к проекту после сдачи сессии (она у меня заключительная, не сдам - отчислят к чертям, такие дела).
  • Freeman wrote:Вот тут мне показалось, что есть некоторая натяжка. Прикладникам вообще должно быть пофиг на аппаратную несовместимость, если нужные функции наличествуют.
    ты вообще давно на фасме в Колибри кодил?
    может, подскажешь, как выбрать в 4-й функции шрифт №5 ?

    в остальном - согласен.

    Mario
    заботясь о 5% барахла сегодня, не упустить бы остальные 95% завтра.
    и заметь - эти 5% все равно по-любому придется кормить вчерашними версиями.
  • art_zh wrote:может, подскажешь, как выбрать в 4-й функции шрифт №5 ?
    А где там аппаратная несовместимость? Особенность API, не более. Один чёрт -- переделывать.
    Spoiler:Ай-яй-яй, битов в регистре не хватило, айда на 64 бита переходить! :lol:
  • Цитата: "может, подскажешь, как выбрать в 4-й функции шрифт №5 ?"

    Но для 4-х шрифтов место есть (+ можно добавить возможность динамически менять эти четыре шрифта для каждого слота (ну дополнительные 4*4*256 байт для данных в ядре)).

    P.S. Я на стороне Mario (аргументация позже, если вкратце - то я против радикальных полумер).
  • динамически менять эти четыре шрифта для каждого слота
    Заморочки какие. А если надо одновременно пять кеглей ?
  • Serge wrote:А если надо одновременно пять кеглей ?
    А для остальных 100500 кеглей должна быть отдельная системная функция. Потом 4-ю можно сделать устаревшей и постепенно отказаться от неё.
    Нельзя приготовить яичницу, не разбив яйца. Нельзя сделать такой важный шаг, как оптимизация ядерной графики, не принеся что-либо в жертву. Что это будет - совместимость, скорость, удобство - это решать тому, кому под силу переделать ядро и кто это будет делать.
    Spoiler:Меня устроит как вынос кода в драйвер, так и в условно-компилируемые блоки.
  • Who is online

    Users browsing this forum: No registered users and 0 guests