Board.KolibriOS.org
http://board.kolibrios.org/

Оптимизация ядерной графики
http://board.kolibrios.org/viewtopic.php?f=36&t=1615
Page 10 of 17

Author:  art_zh [ Thu Oct 11, 2012 3:04 pm ]
Post subject:  Re: Оптимизация ядерной графики

FireWall wrote:
А вообще-то надо скорее на встраиваемый рынок оглядываться.
Я не в курсе: там тоже везде 32-бита ?

АМД, виа и интел - да, везде. NV- само собой.

насчет вортексов не уверен - подскажите кто работал с ебоксом. у них на сайте никаких доков нет.

Author:  art_zh [ Thu Oct 11, 2012 8:18 pm ]
Post subject:  Re: Оптимизация ядерной графики

еле нашел по последней ссылке
Code:
    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;
    }

так что у Ёгева претензий тоже не будет.

Author:  yogev_ezra [ Thu Oct 11, 2012 8:50 pm ]
Post subject:  Re: Оптимизация ядерной графики

Всё верно, eBox тоже поддерживает 32 бита. Я тоже уже лет 10 не видел ни одного компьютера / монитора, который бы их не поддерживал.
Я проголосовал за "Оставить в ядре единственный 32bpp-режим"

Author:  Mario [ Fri Oct 12, 2012 10:20 am ]
Post subject:  Re: Оптимизация ядерной графики

На всякий случай еще раз спрошу (может быть сути моего вопроса не уловили) - Что мешает вынести зависимую от глубины цвета (битности) часть кода в библиотеку/драйвер? Религия? Зачем ломать то что работает?

Author:  art_zh [ Fri Oct 12, 2012 3:22 pm ]
Post subject:  Re: Оптимизация ядерной графики

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 секунды.

Author:  Mario [ Fri Oct 12, 2012 5:59 pm ]
Post subject:  Re: Оптимизация ядерной графики

Делаю два вывода:
1) Ломать не строить. Тем более альтернативы не предлагается никакой.
2) Нам лень и вообще некогда решать проблему, но мы все равно
Spoiler: Show
Quote:
Весь мир насилья мы разрушим
До основанья, а затем
Мы наш, мы новый мир построим, —
Кто был ничем, тот станет всем.

сломаем работающую систему (которая еще может пригодится некоторым людям) и не будем делать всякие бранчи.
Логика непробиваемая конечно.

Author:  art_zh [ Fri Oct 12, 2012 6:18 pm ]
Post subject:  Re: Оптимизация ядерной графики

Теперь - о том, зачем оно мне надо и чего меня приперло транк потрошить.

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

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

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

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

3ы конечно если 2/3 против, то и хрен с ним, пусть как раньше.

Author:  Mario [ Fri Oct 12, 2012 7:25 pm ]
Post subject:  Re: Оптимизация ядерной графики

art_zh wrote:
3ы конечно если 2/3 против, то и хрен с ним, пусть как раньше.

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

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

Как говорится ничего личного, только бизнес хобби. :|

Author:  Freeman [ Fri Oct 12, 2012 7:58 pm ]
Post subject:  Re: Оптимизация ядерной графики

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 показателен.

Author:  SoUrcerer [ Fri Oct 12, 2012 8:26 pm ]
Post subject:  Re: Оптимизация ядерной графики

Ребяты, поддержу Freeman'а. Сам обещаю вернуться к проекту после сдачи сессии (она у меня заключительная, не сдам - отчислят к чертям, такие дела).

Author:  art_zh [ Sat Oct 13, 2012 1:10 am ]
Post subject:  Re: Оптимизация ядерной графики

Freeman wrote:
Вот тут мне показалось, что есть некоторая натяжка. Прикладникам вообще должно быть пофиг на аппаратную несовместимость, если нужные функции наличествуют.

ты вообще давно на фасме в Колибри кодил?
может, подскажешь, как выбрать в 4-й функции шрифт №5 ?

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

Mario
заботясь о 5% барахла сегодня, не упустить бы остальные 95% завтра.
и заметь - эти 5% все равно по-любому придется кормить вчерашними версиями.

Author:  Freeman [ Sat Oct 13, 2012 2:14 am ]
Post subject:  Re: Оптимизация ядерной графики

art_zh wrote:
может, подскажешь, как выбрать в 4-й функции шрифт №5 ?

А где там аппаратная несовместимость? Особенность API, не более. Один чёрт -- переделывать.
Spoiler: Show
Ай-яй-яй, битов в регистре не хватило, айда на 64 бита переходить! :lol:

Author:  FireWall [ Sat Oct 13, 2012 11:32 am ]
Post subject:  Re: Оптимизация ядерной графики

Цитата: "может, подскажешь, как выбрать в 4-й функции шрифт №5 ?"

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

P.S. Я на стороне Mario (аргументация позже, если вкратце - то я против радикальных полумер).

Author:  Serge [ Sat Oct 13, 2012 12:14 pm ]
Post subject:  Re: Оптимизация ядерной графики

Quote:
динамически менять эти четыре шрифта для каждого слота
Заморочки какие. А если надо одновременно пять кеглей ?

Author:  Albom [ Sat Oct 13, 2012 1:18 pm ]
Post subject:  Re: Оптимизация ядерной графики

Serge wrote:
А если надо одновременно пять кеглей ?

А для остальных 100500 кеглей должна быть отдельная системная функция. Потом 4-ю можно сделать устаревшей и постепенно отказаться от неё.
Нельзя приготовить яичницу, не разбив яйца. Нельзя сделать такой важный шаг, как оптимизация ядерной графики, не принеся что-либо в жертву. Что это будет - совместимость, скорость, удобство - это решать тому, кому под силу переделать ядро и кто это будет делать.
Spoiler: Show
Меня устроит как вынос кода в драйвер, так и в условно-компилируемые блоки.

Page 10 of 17 All times are UTC+03:00
Powered by phpBB® Forum Software © phpBB Limited
https://www.phpbb.com/