[mantech 42]

1 час назад, GenaSPB сказал:

Это шаг в байтах между началами строк в памяти

Интересно, тогда где логика, например, разрешение 1366х768, т.е. длина строки 1366х4=5464 байт на 16 не делится, т.е. такую матрицу я использовать не могу??  Или мне надо поставить 5472, а фактически будет расчет в регистре size ?

Изменено 16 февраля пользователем mantech

[GenaSPB 11]

4 hours ago, mantech said:

т.е. длина строки 1366х4=5464 байт на 16 не делится

Ну добейте лишними байтами если требуется. Хотя я не понял где требуется. Если речь про неработающий декодер - сделайте как надо. Памяти не хватает?
У меня например все строки на 64 байта выровнены. Картинка 100*100 пикселей лежит в буфере 448 * 100 байт в случчае ARGB8888

Изменено 16 февраля пользователем GenaSPB

[GenaSPB 11]

4 hours ago, mantech said:

Или мне надо поставить 5472

Поставьте то что требуется. Иначе будет "косая" картинка.
Какой pitch ставится в VI SURFACE? Это отобрадаемый буфер?
Если не отображаемый а просто для обработок - тожда просто во всех обращенияз к нему одинаковое

А size описывает прямоугольник, coor позицию лвого верхнего угла. На буфере с каким-то pitch/stride

Изменено 16 февраля пользователем GenaSPB

[mantech 42]

10 часов назад, GenaSPB сказал:

Если речь про неработающий декодер - сделайте как надо. Памяти не хватает?

Причем тут декодер?))) Я про вот этот модуль поворота. Памяти хватает, но лишней нет.

А вопрос тут про то, что картинки есть разные, сегодня клиенту нужно 100х100, которая выровнена, а завтра 115х235, что будете делать, скажете, извините, сделайте другой дизайн, у меня "железка" этот не понимает))))))))))

Так не пойдет, это не наш метод!))

 

9 часов назад, GenaSPB сказал:

Поставьте то что требуется. Иначе будет "косая" картинка.
Какой pitch ставится в VI SURFACE? Это отобрадаемый буфер?

Тут не понял, причем тут отображаемый буфер. Он как раз всему соответствует из расчета 1366х768.

Мне больше вот чего интересно, допустим есть картинка 1366х768, jpeg декодер требует под выходной буфер больше памяти, т.к. идет выравнивание 0х1000 Но это не проблема,т.к. область результата его работы уже выровнена и с запасом по объему. Но затем идет преобразование в RGB, которое уже должно в результате дать вот именно 1366х768, но g2d  тоже работает с выровненным буфером, а значит в результате потребует в памяти не 1366х768х4 байт(4196352), а как минимум 1376х768х4, (4227072)что уже на 30720 байт больше. Если получателем будет динамически выделенная область под 1366х768х4, то результат полезет поверх этого и нарушит целостность структуры аллокатора. Вопрос, как выделять при этот память, чтоб не разбрасываться по 30 и более килобайт?

Иначе говоря, как бороться с этими "хвостами" после работы какой-либо железки, ибо в случае софтовых декодеров и поворотчиков их нет, а т.к. х.з. как работают эти железячные, исключать подобного нельзя. Ну конечно, можно наплевать, ибо 30кб по сравнению с картинкой в 4мб ерунда, но все-таки подобные "сюрпризы" как-то не радуют...

Может быть конечно, этот g2d работает так, что память за пределами указанных w и h не затирается, но опять же, кто это сказал?))

Изменено 17 февраля пользователем mantech

[repstosw 18]

Поднял I2S на T113-s3. 

Теперь нет шумов, тресков во время работы устройства.  Проверил даже в наушниках. 

Применено дифференциальное включение и отвязка аналогового домена от китайской платы.  Доволен, тем что вышло. Китайцы знатно налажали в разводке платы MangoPi.

На видео макет устройства: аудио-ЦАП UDA1334BTS, усилок LM4871T (дифференциальное включение по входу и выходу).

 

В релиз хочу поставить MAX98357.   Это и ЦАП и усилок и регулятор усиления.

Из даташита на усилитель:

Quote

Low RF Susceptibility Rejects TDMA Noise from GSM Radios

Тоесть, работа микросхемы должна быть устойчива к наводкам ВЧ, что немаловажно для моих проектов.

 

 

[repstosw 18]

On 2/17/2024 at 4:11 PM, mantech said:

Иначе говоря, как бороться с этими "хвостами" после работы какой-либо железки, ибо в случае софтовых декодеров и поворотчиков их нет, а т.к. х.з. как работают эти железячные, исключать подобного нельзя. Ну конечно, можно наплевать, ибо 30кб по сравнению с картинкой в 4мб ерунда, но все-таки подобные "сюрпризы" как-то не радуют...

Может быть конечно, этот g2d работает так, что память за пределами указанных w и h не затирается, но опять же, кто это сказал?))

Понимаю ваши недовольства.  Сам был в аналогичной ситуации.

По-хорошему - надо проверить что и куда пишут аппаратные декодеры. У меня на FHD H264 энкодер иногда записывал во вспомогательные буфера больше, чем надо. Вопрос решил дополнительными падами в памяти (привет, перерасход 🙂 ), иначе некорректно отрабатывала функция освобождения (free) памяти, так как структуры аллокатора разрушались,

Плюс убеждал заказчика испольовать фреймы с размерами кратными 16.

 

P.S.  Надеюсь, функцию memalign используете, для выделения выровненного куска памяти?  Иначе, придётся запоминать значение указателя до выравнивания, чтобы потом его корректно освобождать.

Изменено 18 февраля пользователем repstosw

[mantech 42]

8 минут назад, repstosw сказал:

По-хорошему - надо проверить что и куда пишут аппаратные декодеры.

Да меня больше не декодеры смущают, там-то как раз места с запасом выделено, а g2d, ибо он напрямую в память уже пишет...

8 минут назад, repstosw сказал:

Надеюсь, функцию memalign используете

Я свой аллокатор использую, там можно сразу задать сколько выровнять.

ЗЫ. походу придется проверять на некратных разрешениях, "портит"-ли он память, выходящую за границы w*h...

Изменено 18 февраля пользователем mantech

[repstosw 18]

1 hour ago, mantech said:

Да меня больше не декодеры смущают, там-то как раз места с запасом выделено, а g2d, ибо он напрямую в память уже пишет...

А декодеры не пишут напрямую в память?   VE тоже работает с памятью.

Кто мешает выделить буфера для G2D с падами ДО- и ПОСЛЕ- активной области?

Тем самым - проверить эти пады после работы G2D. А TCON настроить на активную область.  Память с падами проинициализировать псевдо-рэндомом, фазировка фиксированным сидом. После работы G2D  прочекать пады.

Изменено 18 февраля пользователем repstosw

[mantech 42]

3 часа назад, repstosw сказал:

Кто мешает выделить буфера для G2D с падами ДО- и ПОСЛЕ- активной области?

Дак вот первый вопрос, сколько надо "добавить"? Ну "до", это понятно, тут выравнивание, а после? Сколько он туда накидает мусора? 4кБ, 40? 

3 часа назад, repstosw сказал:

После работы G2D  прочекать пады.

Ну вот об этом я и писал:

 

4 часа назад, mantech сказал:

ЗЫ. походу придется проверять на некратных разрешениях, "портит"-ли он память, выходящую за границы w*h...

 

3 часа назад, repstosw сказал:

А декодеры не пишут напрямую в память? 

Там выходной буфер фиксированный с запасом который точно больше тех "хвостов", которые понаделает декодер.

[mantech 42]

В 18.02.2024 в 14:58, mantech сказал:

тут выравнивание, а после?

Вообщем, этот мерзкий g2d "подкинул" еще сюрприз, пока высота всех картинок была кратна 2 все было норм, но попалась которая не кратна и все, по широкой стороне пошла "борода", точки как бы в шахматном порядке, по 1 и 2й строке, хотя нужно по одной. Проверил, ширина может быть любой, а высота кратна 2. Вот такая бяка. Пока сделал проверку, кратная - поворачиваю g2d, не кратная - программно. К счастью не кратных совсем немного...

[GenaSPB 11]

7 minutes ago, mantech said:

мерзкий g2d "подкинул" еще сюрприз

О каких блоках g2d речь идет, на каких операциях такие эффекты?

Изменено 21 февраля пользователем GenaSPB

[mantech 42]

37 минут назад, GenaSPB сказал:

О каких блоках g2d речь идет

Поворот картинки на 270 град. Формат 4байта на пиксель

Впервые заметил на этой картинке

Если вместо высоты 157 ее конвертануть в 158 или 156 все норм, если 157 по длинной стороне после поворота идет бородапо всем линиям красной, синей и т.п. Эффект "шахматное поле"

 

ЗЫ. И кстати да, выравнивание адресов не нужно, при кратной высоте все норм при любых адресах, если высота не кратна 2м, то хоть сколько завыравнивайся - бесполезно...

Изменено 21 февраля пользователем mantech

[GenaSPB 11]

1 hour ago, mantech said:

при кратной высоте

Пррверю на днях в варианте с нечетным размером тестрчой картинки... 

Сейчас х=150 y=100. Будет 149 на 99

[repstosw 18]

5 hours ago, mantech said:

Если вместо высоты 157 ее конвертануть в 158 или 156 все норм, если 157 по длинной стороне после поворота идет бородапо всем линиям красной, синей и т.п. Эффект "шахматное поле"

Ну так поворачивайте область с высотой 158, при этом 158-ю линию сделать с прозрачностью 0.  Увидите только 157.

 

Не пойму вашей сути боданий с G2D.  Нужен шустрый 2D-блиттер: значит смиритесь с рестрикциями, налагаемыми на автомат G2D.  Способов красивых обходов  масса: от вспомогательного буфера и вырезанию нужной области, до альфы прозрачности...

Изменено 22 февраля пользователем repstosw

[repstosw 18]

6 hours ago, mantech said:

Если вместо высоты 157 ее конвертануть в 158 или 156 все норм, если 157 по длинной стороне после поворота идет борода по всем линиям красной, синей и т.п. Эффект "шахматное поле"

ЗЫ. И кстати да, выравнивание адресов не нужно, при кратной высоте все норм при любых адресах, если высота не кратна 2м, то хоть сколько завыравнивайся - бесполезно...

Не поленился, скачал картинку и проверил.

Никакой бороды нет, не надо ничего выравнивать, и не надо менять высоту и не нужно выделять лишнюю память. 

 

Поворот на 270 градусов 350x157:

 

Координаты (0,0):

 

Координаты (200,100):

 

Прямоугольник:

 

Проверял на таких режимах:

#define LCD_PIXEL_WIDTH  800
#define LCD_PIXEL_HEIGHT 480

#define BYTE_PER_PIXEL     4

#define DE2_FORMAT_ABGR_8888	0x01

G2D_BLT.src_image.format=G2D_FMT_ABGR_AVUY8888;
G2D_BLT.dst_image.format=G2D_FMT_ABGR_AVUY8888;

G2D_BLT.flag=G2D_BLT_ROTATE270;

Форматы DE и G2D(источник и приёмник) - полностью совпадают.  В противном случае, возможно, при поворотах может быть всё, что угодно.

 

7 hours ago, mantech said:

Вообщем, этот мерзкий g2d "подкинул" еще сюрприз, пока высота всех картинок была кратна 2 все было норм, но попалась которая не кратна и все, по широкой стороне пошла "борода", точки как бы в шахматном порядке, по 1 и 2й строке, хотя нужно по одной. Проверил, ширина может быть любой, а высота кратна 2. Вот такая бяка. Пока сделал проверку, кратная - поворачиваю g2d, не кратная - программно. К счастью не кратных совсем немного...

Очевидно, что-то криво настроено: TCON, DE, G2D, или всё вместе.

Изменено 22 февраля пользователем repstosw