[mantech 34]

Приветствую.

Как-то поднимал здесь тему, как использовать аппаратное ускорение графики в данном камне, т.к. доки на 2 и 3Д ускорители закрыты. На сколь помню, мне sasamy предложил использовать РхР для ускорения вместо ДМА. Вот руки дошли попробовать это дело. Из всех режимов подходящий оказался только ресайз, но в результате обнаружил ограничение связанное с кратностью источника и получателя, оно должно быть либо 8 либо 16, в посл. случае быстрее в полтора раза. Хрен бы с ней, но все это дело виснет случайным образом...

Сделал тестовую программу, которая формирует закрашенный заданным цветом прямоугольник.

#include "ipu_common.h"
#define   __REG        *(volatile u32*)

int32_t ips_rotate_test(uint16_t x,uint16_t y,uint16_t xc,uint16_t yc,uint32_t c)
{
    uint32_t ipu_index = 1,i;     // use ipu 1
    ipu_res_info_t res_info;
    uint32_t res_chnl_in, res_chnl_out; 
    uint32_t rot_in_mem = DEV_PXP_BASE; //адрес некэшируемого буфера источника
    uint32_t rot_out_mem = BG_LFB_BASE; //адрес экранной области
    uint32_t taskType = PP_TASK; 
    res_chnl_in = MEM_TO_IC_PP_RES_CH11;
    res_chnl_out = IC_PP_RES_TO_MEM_CH22; 
    for (i = 0; i < 64; i++) __REG(DEV_PXP_BASE+(i<<2))=c; //заполняем 8х8 пикс. константой цвета
  //set resize idma
    memset(&res_info, 0x00, sizeof(ipu_res_info_t));
    res_info.width_in = 8;
    res_info.height_in = 8;
    res_info.width_out = xc-x;
    res_info.height_out = yc-y;
    res_info.strideline_in = 4; //1 пиксель
    res_info.strideline_out = 1366 * 4; //строка пикселей из расчета ширины экрана
    res_info.pixel_format_in = INTERLEAVED_ARGB8888;
    res_info.pixel_format_out = INTERLEAVED_ARGB8888;
    res_info.addr0_in = rot_in_mem;
    res_info.addr0_out = rot_out_mem+((x+(y*ScrX_MAX))<<2);//смещение на начальную точку
    
    ipu_resize_idmac_config(ipu_index, res_chnl_in, res_chnl_out, res_info);
    //set ic task
    ipu_ic_enable(ipu_index, 0, 0);
    ipu_ic_resize_config(ipu_index, taskType, res_info);
    //enable ic task
    ipu_ic_task_enable(ipu_index, PP_TASK, IC_PP, 1);
    ipu_ic_enable(ipu_index, 1, 1);
    //enable resize idma channel
    ipu_channel_buf_ready(ipu_index, res_chnl_out, 0);
    ipu_channel_buf_ready(ipu_index, res_chnl_in, 0);
    while ((ipu_idmac_channel_busy(ipu_index, res_chnl_out)==1)||(ipu_idmac_channel_busy(ipu_index, res_chnl_in)==1)) ;
    return TRUE;
} 



Запускаю так:  
  while (1)
    {
     ips_rotate_test(0,0,80,80,0xff0000ff);

     //hal_delay_us(500); 
    }

За основу взял их Platform SDK.

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

Вообщем, если после вызова ips_rotate_test вставить задержку, то более-менее работает... Буду рад услышать что-то вразумительное по этому вопросу...

Изменено 13 июля, 2020 пользователем mantech

[mantech 34]

13.07.2020 в 14:53, mantech сказал:

Буду рад услышать что-то вразумительное по этому вопросу...

Вообщем, чувствую никто нестандартным сексом с этой штукой не занимался и не занимайтесь, ибо это просто ТРЭШ!

1) Причиной зависания оказался маленький размер входной картинки (задавал 8х8, а работать стал только с 48х48 пикселей), что меня обрадовало, но не надолго.

2) Трэш №1 - кратность выходной картинки должна быть 8 или 16 пикселей, вот так! Как хотите, а другой не получится. Причем если задать 8 то скорость падает на 50%, видимо из-за уменьшенного бурста. Ну хрен бы с ним - решил, что "дозакрашиваю" с помощью SDMA...

3) Треш №2 - размер выходной картинки только до 1024х1024. Т.е. если у меня матрица 1366х768 значит мне надо 2 раза запускать это чудо, и как-то выравнивать по стороне 1366, которая не кратна 8 и 16... Ну ладно, с этим тоже что-нить придумаю.

4) И "изюминка на торте" - Треш№3 - это парни просто КАПЕЦ - адрес получателя должен быть кратен 8. Восьми, Карл!! Это вообще как, через 2 пикселя 32х битного цвета или 4 16и битного! Вот блин на это я никак не расчитывал, вот как что-то делать с такими "аппаратными" корками, ктоме как подкатиться на них и плюхнутся на пол!

Честно говоря так хочется посмотреть в глаза "гению" кто это придумал и задать до тупости простой вопрос - а как твое творение использовать в реальных задачах? Указать всем погам, пользователям, которые создают формы в редакторе - так, товарищи, все размеры картинок должны быть кратными 16 или 8 и должны рисовать только с координат 0,2,4,6 и т.д. А иначе ничего работать НЕ будет!  Это финиш, я считаю...

ЗЫ. Вообщем не придумал ничего лучшего для этой шляпы, кроме, как очищать весь экран целиком или закрашивать его определенным цветом, ибо хоть какая-то польза от всего этого - почти 4х кратное ускорение закраски по сравнению с SDMA...

Изменено 19 июля, 2020 пользователем mantech

[repstosw 18]

On 7/19/2020 at 4:38 PM, mantech said:

ЗЫ. Вообщем не придумал ничего лучшего для этой шляпы, кроме, как очищать весь экран целиком или закрашивать его определенным цветом, ибо хоть какая-то польза от всего этого - почти 4х кратное ускорение закраски по сравнению с SDMA...

 

Мне бы для игр пригодилось!

Копировать отрендерённый задний буфер на экран целиком весь: позиции X, Y = 0,  ширина 400 пикселей, высота 240.  В ограничения укладываюсь!

 

On 7/19/2020 at 4:38 PM, mantech said:

формы в редакторе - так, товарищи, все размеры картинок должны быть кратными 16 или 8 и должны рисовать только с координат 0,2,4,6 и т.д. А иначе ничего работать НЕ будет! 

 

Объектики для игры рисую через CPU: спрайты всякие, иконки, меню.... - в задний буфер.   Потом копирую его на экран DMA.

[mantech 34]

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

ширина 400 пикселей, высота 240.

Всегда думал, что такое разрешение можно даже программно копировать и закрашивать с сумасшедшей скоростью, это ж всего 96К пикселей.

Но мои клиенты хотят как минимум 1366х768, а это уже больше миллиона пикселей, т.е. в 10 раз больше вашего...

[repstosw 18]

5 minutes ago, mantech said:

Всегда думал, что такое разрешение можно даже программно копировать и закрашивать с сумасшедшей скоростью, это ж всего 96К пикселей.

 

можете умножить на 4, так как 4 плоскости :)  ну и DMA использую в основном для фен-шуя, на самом деле одного CPU хватает пока.

[mantech 34]

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

можете умножить на 4, так как 4 плоскости :)

Однако там требования, мне всегда 2х хватало, правда аппаратных))

[repstosw 18]

44 minutes ago, mantech said:

Однако там требования, мне всегда 2х хватало, правда аппаратных))

 

Там очень мощные требования: поворот, отражения, альфа, маскирование бит цветовых каналов, перестановка RGB, очёрно-беливание ,  и многое-многое другое.... :)