Cairo

Discussing libraries simplifying applications development
  • Serge, слова "Не все процессоры умеют быстро вычислять адреса операндов для последовательныx push push push push push" особенно забавно смотрятся на фоне портянки из условных переходов в вызываемых функциях, записи в видеопамять и отдельных "шедевров" вида "mov ebx,eax / (несколько команд, в которых нет ни eax, ни ebx, ни меток) / mov eax,ebx". Это было бы смешно, если не было бы так грустно. Если серьёзно - нужно очень постараться, чтобы найти процессор, на котором это имеет смысл: сколько-нибудь современные умеют, музейные экспонаты вообще не умеют параллелить поток команд.
    " И её текущая реализация не соответствует описанию. Например stride (ebp) для 32 и 24 bpp посылается нафиг, что совершенно неприемлемо." - неверно, ebp нормально учитывается для любой глубины изображения.
    Mario, неясно, почему ты обращаешься "To All". Ты предлагаешь прямо в основном репозитории убрать эту функцию?
    Я поясню, чем именно мне не нравится происходящее: во-первых, откровенно отстойным кодом, результат которого можно наблюдать на примере 130-килобайтового - это после сжатия! - atikms.dll, где количество мусора настолько велико, что банальное изменение опций компиляции уже выкидывает 10 кило; во-вторых, позицией "а, оно глючит, давайте на него забьём и напишем своё на gcc, о глюках даже сообщать не будем - кому это интересно, главное же - чтобы хоть как-то работало".
    Сделаем мир лучше!
  • Mario
    Лично я вообще никого не трогаю. Задал вопрос - получил ответ.

    CleverMouse
    Насколько я понял, сейчас blitter.inc - это просто заплатка для ядра, эмулирующая хардверный блиттер. Драйвер все равно ее перекроет.
    Если это так (?), то фиг с ним, с сишным кодом - если заработает, то потом всегда можно подправить где криво.
    В любом случае, склеить блиттер с 65-й функцией действительно невозможно.
  • CleverMouse

    АMD научилось вычислять esp в последовательностях push/pop начиная с Феномов. Все предыдущие не самые древние процессоры упирались в зависимость по esp.
    Да, gcc генерирует убогий код, но и отрисовку каждого пикселя через call -> lodsd-> ret шедевром не назовёшь.

    Собственно примерно 160 строк gcc против 120 строк ручного кода от начала функции до собственно отрисовки не так и плохо с учётом разницы в параметрах вызовов и возможности использовать отсечение blit_clip и block_clip в других функциях.

    P.S. За пять лет с Колибри я выбрал все лимиты времени на ручное кодирование с последующим отловом неизбежных ошибок трассировкой ядра в Боше. Приходится выбирать между gcc или никак.
  • Serge
    Посмотрел демку, интересная штука. Шрифты я так понимаю встроены в Cairo?


    Насчёт 73 функции вообще не вижу в чём проблема, код на ассемблере. Да дублирует в некоторой степени функционал 65 функции, но если она действительно лучше почему нет? Та же 65 когда-то заменила функцию 7, а что таких дублирующих мест в ядре хватает это и так ясно. Посмотрите хотя на количество дублируещего кода работы с PCI. Нужно составить список того что подлежит правке в настоящее время, переписать полностью соответсвующий код ядра, а затем и программы поправить под изменнёный API.

    P.S. Документация на 73?
  • Asper

    Да, это встроенные шрифты Cairo. Пока экспериментировал с примерами обнаружил баг при попытке сделать окантовку шрифта (слово "world"). Не знаю, особенность это встроенного шрифта или привнесённая ошибка. Надо упорядочить математическую библиотеку, там сейчас настоящая каша.

    Я не выкладывал api на ф.73 потому, что это предварительная версия и очень возможны правки. Хочется проверить разные варианты прежде чем фиксировать api, чтобы не создавать потом ещё ф.74 и т.д.
    В настоящее время вызов выглядит так:
    еах = 73
    ebx =0 регистр зарезервирован. Зависит от того будут расширения 73.1, 73.2... или нет.
    ecx = адрес структуры с параметрами вызова.
    struct blit_call{
    int dstx;
    int dsty;
    int w;
    int h;

    int srcx;
    int srcy;
    int srcw;
    int srch;

    unsigned char *bitmap;
    int stride;};

    dstx, dsty - координаты точки назначения относительно левого верхнего угла окна. Могут принимать отрицательные значения.
    srcx, srcy - координаты левого верхнего угла копируемой области. Могут принимать отрицательные значения.
    w, h - ширина и высота копируемой области.
    srcw, srch - ширина и высота текстуры.
    bitmap - текстура в формате XRGB32.
    stride - ширина строки текстуры в байтах. Не следует полагать, что stride всегда равен srcw * bits_per_pixel / 8;
    Я думаю над поддержкой других форматов, возможно кодов ROP.
    Вызов не изменяет передаваеме параметры.

    Есть хорошие новости. Доделал загрузчик PE в user-mode. Этот же скомпилированный и упакованный пример занимает 2.5 кБ, несжатые длл-ки 1MБ. Всё работает. Хочу сделать dll версии ffmpeg и mesa.
  • Serge wrote: Хочу сделать dll версии ffmpeg и mesa.
    Вот это хорошая новость. Если все будет работать в trunk, то можно будет написать саму программу уже на ассемблере.
  • Я не против новой функции как таковой, обоснование "Всегда получать базовый адрес источника, а не модифицированный для вывода части источника со смещением x,y. В этом случае драйвер сможет однозначно опознать текстуру источника и не загонять eё лишний раз в gart или видеопамять. GPU предъявляет жёсткие требования к выравниванию данных - 32\64 байта. Будет ещё больше. Выравнивание на 4 не пойдёт." вполне достаточно, я высказывалась против конкретной реализации и против необоснованных упоминаний несуществующих багов.
    art_zh, красивые слова "потом всегда можно подправить где криво", увы, не выдерживают столкновения с суровой действительностью, где нет ничего более постоянного, чем временные трудности и костыли.
    Asper, проблема в том, что код как раз не на ассемблере, что видно невооружённым взглядом на video/blitter.inc и что выше подтверждает автор Serge. Теоретически тот же atikms.dll можно прогнать через дизассемблер и получить код, который будет успешно ассемблироваться, но atikms.dll от этого не перестанет быть сишным драйвером со всеми вытекающими проблемами.
    Сделаем мир лучше!
  • Mario wrote:
    Serge wrote: Хочу сделать dll версии ffmpeg и mesa.
    Вот это хорошая новость. Если все будет работать в trunk, то можно будет написать саму программу уже на ассемблере.
    I also like that idea very much (I hope it applies to the MP3 code too)
    "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein
  • Я ошибся, ф.65 действительно использует stride, но работать через неё всё равно не получается.

    CleverMouse

    Вот какой смысл сейчас убиваться над ручной оптимизацией, если я не знаю как будет выглядеть вызов через две недели ?

    Что касается отстойного atikms.dll, то воистину одним суп жидкий, другим жемчуг мелкий. Я до сих пор удивлён тем фактом, что драйвер предназначенный работать в режиме ядра Линукс, смог заработать в Колибри с минимальными переделками исходного кода. Пусть не на все 100%, но первоначальную задачу - смену видеорежимов он выполняет. И я очень рад за разработчиков gcc. Им наконец удалось сделать работающую lto. Жаль, моя сборка mingw эту опцию ещё не поддерживает.
  • Serge wrote:Asper

    Да, это встроенные шрифты Cairo. Пока экспериментировал с примерами обнаружил баг при попытке сделать окантовку шрифта (слово "world"). Не знаю, особенность это встроенного шрифта или привнесённая ошибка. Надо упорядочить математическую библиотеку, там сейчас настоящая каша.
    Хорошо. Это частично решает проблему с векторными шрифтами.
    Serge wrote:Есть хорошие новости. Доделал загрузчик PE в user-mode. Этот же скомпилированный и упакованный пример занимает 2.5 кБ, несжатые длл-ки 1MБ. Всё работает. Хочу сделать dll версии ffmpeg и mesa.
    А это просто отлично! :) Я смогу продолжить работу над QIII. Правда не знаю будет ли это иметь смысл без 3D ускорения.
    Mario wrote:Вот это хорошая новость. Если все будет работать в trunk, то можно будет написать саму программу уже на ассемблере.
    Ага, только всё это дело можно размещать только на CD, на дискете уже не помещается.

    CleverMouse
    blitter.inc содержит только строки ассемблерного кода, да согласен дизассемблированный C, но Serge вроде бы и не отказывается от ручной оптимизации, после того как закончит разработку функции.
  • "Я до сих пор удивлён тем фактом, что драйвер предназначенный работать в режиме ядра Линукс, смог заработать в Колибри с минимальными переделками исходного кода." - ещё бы, если туда включить части самого ядра Линукс, что порождает забавные вещи типа "перенумеруем все pci-устройства, определим каждое, прочтём и вычислим детальную информацию о каждом, под которую отдельно выделим память, после чего выделим информацию о нужном нам устройстве и забудем остальное нафиг", а также ещё один аллокатор, игнорируя уже существующий в ядре.
    "Вот какой смысл сейчас убиваться над ручной оптимизацией, если я не знаю как будет выглядеть вызов через две недели ?" - раз обработчик уже появился в транке, значит, весьма сомнительно, что через две недели что-то существенно изменится. Некоторые детали - да, возможно, все - вряд ли.
    Asper, "не отказывается от" отнюдь не равно "обещает". Я считаю, основываясь на истории и текущих действиях Serge, что подобная оптимизация крайне маловероятна, потому что Serge занят совсем другими проблемами и, похоже, просто не считает такие мелочи, как сишный код в ядре, проблемами - в отличие от меня; возможно, я ошибаюсь.
    Сделаем мир лучше!
  • CleverMouse

    В далёком светлом будущем весь код поиска должен перейти в диспетчер устройств. А пока так, коряво но работает.
    Spoiler:В списке приоритетов на первом месте стояло получить работающий драйвер. На втором - сделать это с минимальной модификацией исходного кода. Последнее совсем не блажь. Драйвер находится в активной разработке. В то время, когда я выкладывал первые версии kms, drm часть переписывалась каждый месяц процентов на 30-40%, практически с каждым новым коммитом менялось api. Остальное ядро тоже не отставало. В этой ситуации серьёзно переделывать драйвер под Колибри означало что через два-три месяца всю работу придётся делать заново.
    Ядерный malloc блокирует систему, и его куча только для небольших объектов и желательно с деструкторами. atidll очень активно использует malloc в коде drm, да и везде, так что своя куча ему необходима.
    Я не считаю сишный код в ядре проблемой. Кстати ядерный malloc это тоже С только /LTCG.
  • Поскольку тема блиттера (ф.73) в основном обсуждалась в этой теме, то здесь и отпишусь.
    Я планирую внести изменения в параметры вызова, добавить вывод на десктоп и прозрачность по альфа-каналу (0xFF рисуем, 0х00 не рисуем). И когда Марат сделает shadowfb можно будет сделать коды ROP. Если есть вопросы, замечания и предложения пишите.
    Вывод на десктоп - отрисовка поверх или вместо фоновой картинки, кому как нравится. Эта фича позволит icon работать в один поток и обещает еще массу интересных возможностей.
  • Собственно меня вчера, когда я лег спать, стала душить жаба насчет выделение памяти под shadow buffer. Можно ведь и без него реализовать, хотя код несколько сложнее получится. Собственно хотелось понять как shadow buffer спасет Родину в этом случае, как ты описываешь. Он ведь один на все. Особенно интересно насчет фонового изображения с иконками.
  • Who is online

    Users browsing this forum: No registered users and 3 guests