[GenaSPB 11]

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

On 2/14/2024 at 11:20 AM, repstosw said:

On 2/14/2024 at 10:18 AM, GenaSPB said:

Вопрос по координате выходного окна. 
Правильно ди я понимаю, что при повороте надо указать пиксель, соответствующий начальной координате (левая-верхняя точка входного)?

Очевидно, что да.

С выделенем памяти что у вас за проблемы не понял, какая лишняя память? Какой запас? Копирование затрагивает ровно то окно, которое заказано. выделение у меня сделано с округлением до 64 байтов в каждой строке (из соображений быстродействия - выделение буферов идет так же с таким выравниванием).
Исходная картинкка 100 * 50 пикселей, экран - 800 * 480.

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

[mantech 42]

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

выделение у меня сделано с округлением до 64 байтов в каждой строке

У меня 2 режима, распаковка и копирование напрямую в экранную область, скажем так на лету, без использования памяти (исп. буфер под сырой jpeg, затем вторая часть под Y\C компоненты декодера), и второй буфер как получатель для g2d преобразователя Y\C - RGB. После этого он используется как источник g2d ротатора и получатель - экранная плоскость. Тут все выровнено и работает как положено. 2 режим - распаковка в память, выделяю область под битмап размером с картинку, декодирую ее и записываю в память (PNG декодируется программно, чтобы не ждать каждый раз), так вот выделять приходится с выравниванием, что приводит к потере до 4кБ на картинку, при куче мелких это накладно, конечно есть выход - мелкие поворачивать программно...

64 байта не проверял, но чет мне кажется маловато будет. У того же jpeg декодера нужно 4кБ, хотя х.з. какие требования тут к каждой задаче...

Пока ковырялся с поворотом заметил, что поворот идет блоками 16 строк по 64 пикселя, скорее всего и выравнивание по такому объему должно быть.

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

[repstosw 18]

3 hours ago, GenaSPB said:

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

А вот и нифига...   В моём случае ваш тезис неправильный.

Правильными будут те координаты, которые я давал для своего примера.

Очевидно, всё дело в исходниках, которые используются.

On 2/15/2024 at 5:27 AM, mantech said:

Вопрос, на сколько нужно выравнивать адреса источника и получателя? Чет нигде не нашел описания

И не найдёте.

Выравниваю на кратность 4.

[GenaSPB 11]

11 minutes ago, repstosw said:

Очевидно, всё дело в исходниках, которые используются.

Да я про свой вариант на гитхаб.

На уровене регистров блоков G2D

https://github.com/ua1arn/hftrx/blob/7e6e114e4f1dcb278d4801b185b890d88c542ea3/src/display/framebuf.c#L1663

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

[GenaSPB 11]

Нашелся в T113-s3 на 0x05200000 второй RT-Mixer с единственным VI. Дублирует первый что стоит на 0x05100000.
Пока получить изображение не получилось, но синхронизация по кадрам работает.

[mantech 42]

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

 второй RT-Mixer с единственным VI.

Может это для TVD?

6 часов назад, repstosw сказал:

Выравниваю на кратность 4.

4 это в чем, в байтах, dword, килобайтах?

[GenaSPB 11]

1 hour ago, mantech said:

Может это для TVD?

У него (DE) выходной коммутатор есть, его работа заметна. На TCON может быть скоммутирован один из двух DE RT-Mixer. Как и на второй TCON, которонго в этом процессоре нет. В t507 оно оправдано - там второй есть.

С чего TV_Encoder берёт данные не понял.. И как он соотностится с TCON_TV

Quote

Two alpha blending channels for main display, one channel for aux display

Вот что у нас в T113-s3 считается aux display?

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

[sasamy 3]

On 2/16/2024 at 10:34 AM, GenaSPB said:

Как и на второй TCON, которонго в этом процессоре нет. В t507 оно оправдано - там второй есть.

С чего TV_Encoder берёт данные не понял.. И как он соотностится с TCON_TV

TCON_TV это и есть второй тконь

https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/display/allwinner,sun8i-r40-tcon-top.yaml#L19

на t113 схема проще но общий смысл тот же

[GenaSPB 11]

Спасибо. Если на второй mixer как входные pipe не подключать ничего, идет запрограммированный цвет фона из mix (он же bld в терминах линуксовчкого кода). Если подключить единствкнный VI, то всё чёрное.

Проговммирование как для mixer0 (где всё раьотает).

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

[repstosw 18]

Второй TCON я уже давно раскурил в этой теме.  Работает в паре с TVE для вывода кадра на экран ТВ (NTSC/PAL  CVBS)

[GenaSPB 11]

Я тестирую de с первым tcon. Vi в режиме ui

Зы: кстати, встроенный в rt mix модуль rot не спаспёт repstosw?

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

[repstosw 18]

11 minutes ago, GenaSPB said:

кстати, встроенный в rt mix модуль rot не спаспёт repstosw?

Если он может читать из видео-ОЗУ и выводить в стекляшку уже повёрнутый на 90 градусов кадр - тогда это будет  очень полезно для мелких дисплеев с портретной ориентацией, которые используются в горизонтальном положении.

[GenaSPB 11]

32 minutes ago, repstosw said:

Если он может читать из видео-ОЗУ и выводить в стекляшку уже повёрнутый на 90 градусов кадр

У меня сильное ощущение что может.

Чтение документа про DE3. Блок ROT изображен не как потоковый а работающий обратно на шину... И не везде есть. И никаких подробностей больше.

В документе про DE2 есть регистры... но он память-память работает.

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

[mantech 42]

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

В документе про DE2 есть регистры... но он память-память работает.

Не в курсе, что означает "0x030  Input Y\RGB\ARGB memory pitch register" что в нем указывается, ширина шины памяти или...?

[GenaSPB 11]

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

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