Board.KolibriOS.org

Официальный форум KolibriOS
Текущее время: Пн дек 11, 2017 3:17 am

Часовой пояс: UTC+03:00




Начать новую тему  Ответить на тему  [ 37 сообщений ]  На страницу Пред. 1 2 3 След.
Автор Сообщение
 Заголовок сообщения: Re: Cairo
СообщениеДобавлено: Пт мар 04, 2011 4:29 pm 
Serge
Вообще-то zSea вполне себе использует 8,16,24,32 значения.
Цитата:
diamond сделал ф.65 чтобы KFar работал быстрее. Эволюция.

Изначально да, потом по моей просьбе он ее допилил. Для вывода растровых картинок этого вполне хватает.

To All
Что вам мешает выбросить функцию при компиляции?
Транковское ядро предназначено для использования на обычных компьютерах и затраты в несколько килобайт на новую функцию вполне приемлемы. Чего вы на Serge наседаете?


Вернуться к началу
   
 Заголовок сообщения: Re: Cairo
СообщениеДобавлено: Пт мар 04, 2011 5:10 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Чт сен 03, 2009 1:52 pm
Сообщения: 1601
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, о глюках даже сообщать не будем - кому это интересно, главное же - чтобы хоть как-то работало".

_________________
Сделаем мир лучше!


Вернуться к началу
 Заголовок сообщения: Re: Cairo
СообщениеДобавлено: Пт мар 04, 2011 8:11 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1291
Mario
Лично я вообще никого не трогаю. Задал вопрос - получил ответ.

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


Вернуться к началу
 Заголовок сообщения: Re: Cairo
СообщениеДобавлено: Сб мар 05, 2011 12:15 am 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3929
CleverMouse

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

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

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


Вернуться к началу
 Заголовок сообщения: Re: Cairo
СообщениеДобавлено: Сб мар 05, 2011 8:22 am 
Не в сети
Аватара пользователя

Зарегистрирован: Пт июн 27, 2008 3:22 pm
Сообщения: 974
Serge
Посмотрел демку, интересная штука. Шрифты я так понимаю встроены в Cairo?


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

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


Вернуться к началу
 Заголовок сообщения: Re: Cairo
СообщениеДобавлено: Сб мар 05, 2011 9:53 am 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3929
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.


Вернуться к началу
 Заголовок сообщения: Re: Cairo
СообщениеДобавлено: Сб мар 05, 2011 10:27 am 
Serge писал(а):
Хочу сделать dll версии ffmpeg и mesa.

Вот это хорошая новость. Если все будет работать в trunk, то можно будет написать саму программу уже на ассемблере.


Вернуться к началу
   
 Заголовок сообщения: Re: Cairo
СообщениеДобавлено: Сб мар 05, 2011 3:25 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Чт сен 03, 2009 1:52 pm
Сообщения: 1601
Я не против новой функции как таковой, обоснование "Всегда получать базовый адрес источника, а не модифицированный для вывода части источника со смещением x,y. В этом случае драйвер сможет однозначно опознать текстуру источника и не загонять eё лишний раз в gart или видеопамять. GPU предъявляет жёсткие требования к выравниванию данных - 32\64 байта. Будет ещё больше. Выравнивание на 4 не пойдёт." вполне достаточно, я высказывалась против конкретной реализации и против необоснованных упоминаний несуществующих багов.
art_zh, красивые слова "потом всегда можно подправить где криво", увы, не выдерживают столкновения с суровой действительностью, где нет ничего более постоянного, чем временные трудности и костыли.
Asper, проблема в том, что код как раз не на ассемблере, что видно невооружённым взглядом на video/blitter.inc и что выше подтверждает автор Serge. Теоретически тот же atikms.dll можно прогнать через дизассемблер и получить код, который будет успешно ассемблироваться, но atikms.dll от этого не перестанет быть сишным драйвером со всеми вытекающими проблемами.

_________________
Сделаем мир лучше!


Вернуться к началу
 Заголовок сообщения: Re: Cairo
СообщениеДобавлено: Сб мар 05, 2011 4:59 pm 
Не в сети
Mentor/Kernel Developer
Аватара пользователя

Зарегистрирован: Пт июн 30, 2006 9:01 am
Сообщения: 1232
Mario писал(а):
Serge писал(а):
Хочу сделать 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


Вернуться к началу
 Заголовок сообщения: Re: Cairo
СообщениеДобавлено: Сб мар 05, 2011 11:38 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3929
Я ошибся, ф.65 действительно использует stride, но работать через неё всё равно не получается.

CleverMouse

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

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


Вернуться к началу
 Заголовок сообщения: Re: Cairo
СообщениеДобавлено: Вс мар 06, 2011 3:38 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Пт июн 27, 2008 3:22 pm
Сообщения: 974
Serge писал(а):
Asper

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


Хорошо. Это частично решает проблему с векторными шрифтами.

Serge писал(а):
Есть хорошие новости. Доделал загрузчик PE в user-mode. Этот же скомпилированный и упакованный пример занимает 2.5 кБ, несжатые длл-ки 1MБ. Всё работает. Хочу сделать dll версии ffmpeg и mesa.

А это просто отлично! :) Я смогу продолжить работу над QIII. Правда не знаю будет ли это иметь смысл без 3D ускорения.

Mario писал(а):
Вот это хорошая новость. Если все будет работать в trunk, то можно будет написать саму программу уже на ассемблере.


Ага, только всё это дело можно размещать только на CD, на дискете уже не помещается.

CleverMouse
blitter.inc содержит только строки ассемблерного кода, да согласен дизассемблированный C, но Serge вроде бы и не отказывается от ручной оптимизации, после того как закончит разработку функции.


Вернуться к началу
 Заголовок сообщения: Re: Cairo
СообщениеДобавлено: Ср мар 09, 2011 3:55 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Чт сен 03, 2009 1:52 pm
Сообщения: 1601
"Я до сих пор удивлён тем фактом, что драйвер предназначенный работать в режиме ядра Линукс, смог заработать в Колибри с минимальными переделками исходного кода." - ещё бы, если туда включить части самого ядра Линукс, что порождает забавные вещи типа "перенумеруем все pci-устройства, определим каждое, прочтём и вычислим детальную информацию о каждом, под которую отдельно выделим память, после чего выделим информацию о нужном нам устройстве и забудем остальное нафиг", а также ещё один аллокатор, игнорируя уже существующий в ядре.
"Вот какой смысл сейчас убиваться над ручной оптимизацией, если я не знаю как будет выглядеть вызов через две недели ?" - раз обработчик уже появился в транке, значит, весьма сомнительно, что через две недели что-то существенно изменится. Некоторые детали - да, возможно, все - вряд ли.
Asper, "не отказывается от" отнюдь не равно "обещает". Я считаю, основываясь на истории и текущих действиях Serge, что подобная оптимизация крайне маловероятна, потому что Serge занят совсем другими проблемами и, похоже, просто не считает такие мелочи, как сишный код в ядре, проблемами - в отличие от меня; возможно, я ошибаюсь.

_________________
Сделаем мир лучше!


Вернуться к началу
 Заголовок сообщения: Re: Cairo
СообщениеДобавлено: Ср мар 09, 2011 4:52 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3929
CleverMouse

В далёком светлом будущем весь код поиска должен перейти в диспетчер устройств. А пока так, коряво но работает.
Спойлер: Показать
В списке приоритетов на первом месте стояло получить работающий драйвер. На втором - сделать это с минимальной модификацией исходного кода. Последнее совсем не блажь. Драйвер находится в активной разработке. В то время, когда я выкладывал первые версии kms, drm часть переписывалась каждый месяц процентов на 30-40%, практически с каждым новым коммитом менялось api. Остальное ядро тоже не отставало. В этой ситуации серьёзно переделывать драйвер под Колибри означало что через два-три месяца всю работу придётся делать заново.
Ядерный malloc блокирует систему, и его куча только для небольших объектов и желательно с деструкторами. atidll очень активно использует malloc в коде drm, да и везде, так что своя куча ему необходима.
Я не считаю сишный код в ядре проблемой. Кстати ядерный malloc это тоже С только /LTCG.


Вернуться к началу
 Заголовок сообщения: Re: Cairo
СообщениеДобавлено: Вс фев 26, 2012 10:35 am 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3929
Поскольку тема блиттера (ф.73) в основном обсуждалась в этой теме, то здесь и отпишусь.
Я планирую внести изменения в параметры вызова, добавить вывод на десктоп и прозрачность по альфа-каналу (0xFF рисуем, 0х00 не рисуем). И когда Марат сделает shadowfb можно будет сделать коды ROP. Если есть вопросы, замечания и предложения пишите.
Вывод на десктоп - отрисовка поверх или вместо фоновой картинки, кому как нравится. Эта фича позволит icon работать в один поток и обещает еще массу интересных возможностей.


Вернуться к началу
 Заголовок сообщения: Re: Cairo
СообщениеДобавлено: Вс фев 26, 2012 4:55 pm 
Собственно меня вчера, когда я лег спать, стала душить жаба насчет выделение памяти под shadow buffer. Можно ведь и без него реализовать, хотя код несколько сложнее получится. Собственно хотелось понять как shadow buffer спасет Родину в этом случае, как ты описываешь. Он ведь один на все. Особенно интересно насчет фонового изображения с иконками.


Вернуться к началу
   
Показать сообщения за:  Поле сортировки  
Начать новую тему  Ответить на тему  [ 37 сообщений ]  На страницу Пред. 1 2 3 След.

Часовой пояс: UTC+03:00


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 2 гостя


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Создано на основе phpBB® Forum Software © phpBB Limited
Русская поддержка phpBB