[repstosw 18]

14 hours ago, mantech said:

Жалко нет аналога на НЕОНе, каждый раз мозги выпаривать с этими корками...

Но это не означает, что его нельзя написать самому, переложив на SIMD.

 

В TMS320C6745 самостоятельно делал поворот видеобуфера на 90 градусов (потому что дисплей был с портретной ориентацией развёртки, нужна была отрисовка соосная с ходом луча для VSYNC) :

void Rot_Buffer(void)
{
 for(int y=0;y<(SCREEN_HEIGHT<<1);y+=8)
 {
  u64 * __restrict vc=(u64*)(VIDEO_CACHE+y);
  u64 * __restrict vb0=(u64*)&VRAMBuffer[((SCREEN_WIDTH-4)<<1)+(SCREEN_WIDTH*y)];
  u64 * __restrict vb1=vb0+(SCREEN_WIDTH>>2);
  u64 * __restrict vb2=vb1+(SCREEN_WIDTH>>2);
  u64 * __restrict vb3=vb2+(SCREEN_WIDTH>>2); 

  for(int x=0;x<(SCREEN_WIDTH>>2);x++)
  {
   _amem8(&vc[(3*(SCREEN_HEIGHT>>2))+(SCREEN_HEIGHT*x)])=((u64)((u16) _amem8(&vb0[-x])     ))|((u64)((u16) _amem8(&vb1[-x])     )<<16)|((u64)((u16) _amem8(&vb2[-x])     )<<32)|((u64)((u16) _amem8(&vb3[-x])     )<<48);
   _amem8(&vc[(2*(SCREEN_HEIGHT>>2))+(SCREEN_HEIGHT*x)])=((u64)((u16)(_amem8(&vb0[-x])>>16)))|((u64)((u16)(_amem8(&vb1[-x])>>16))<<16)|((u64)((u16)(_amem8(&vb2[-x])>>16))<<32)|((u64)((u16)(_amem8(&vb3[-x])>>16))<<48);
   _amem8(&vc[(1*(SCREEN_HEIGHT>>2))+(SCREEN_HEIGHT*x)])=((u64)((u16)(_amem8(&vb0[-x])>>32)))|((u64)((u16)(_amem8(&vb1[-x])>>32))<<16)|((u64)((u16)(_amem8(&vb2[-x])>>32))<<32)|((u64)((u16)(_amem8(&vb3[-x])>>32))<<48);
   _amem8(&vc[(0*(SCREEN_HEIGHT>>2))+(SCREEN_HEIGHT*x)])=((u64)((u16)(_amem8(&vb0[-x])>>48)))|((u64)((u16)(_amem8(&vb1[-x])>>48))<<16)|((u64)((u16)(_amem8(&vb2[-x])>>48))<<32)|((u64)((u16)(_amem8(&vb3[-x])>>48))<<48);
  }
 }
}

 

Так вот, оно очень хорошо запараллелилось.

 

10 hours ago, mantech said:

Пробовал, все полосит и вообще мусор не экране, иногда в хардфаулт вылетает, видимо лезет за пределы экранного буфера.

Проблема в некорректном указании координат вывода финального изображения.  Там будет не (0,0).  А с учётом поворота.

 

14 hours ago, mantech said:

может он вообще только квадратные объекты поворачивает?

Прямоугольные тоже поворачивает.   Рисую на экран 320x240 пару фреймов 160x240 повёрнутые  на 270 градусов.

 

Координаты вывода такие:

#define BUFFER_WIDTH  320
#define BUFFER_HEIGHT 240

#define WINDOW0_WIDTH  240
#define WINDOW0_HEIGHT 160

#define WINDOW1_WIDTH  WINDOW0_WIDTH
#define WINDOW1_HEIGHT WINDOW0_HEIGHT

#define WINDOW0_X (((3*BUFFER_WIDTH)/4)-(WINDOW0_HEIGHT/2))
#define WINDOW0_Y ((BUFFER_HEIGHT-WINDOW0_WIDTH)/2)

#define WINDOW1_X ((BUFFER_WIDTH/4)-(WINDOW1_HEIGHT/2))
#define WINDOW1_Y ((BUFFER_HEIGHT-WINDOW1_WIDTH)/2)

//...

G2D_Rot.dst_x=WINDOW0_X; //координаты вывода левого фрейма
G2D_Rot.dst_y=WINDOW0_Y;

G2D_Rot.dst_x=WINDOW1_X; //координаты вывода правого фрейма
G2D_Rot.dst_y=WINDOW1_Y;

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

[mantech 48]

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

h & w - разное?

Ну конечно 1080 и 1920

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

Там будет не (0,0).  А с учётом поворота.

Да, когда писал, что вывелся квадрат 1080 1080, в windowY указывал 741, видимо из расчета 1920-1080+1. Но как заставить выводить высотой не 1080, а 1920 пока х.з.((

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

Рисую на экран 320x240 пару фреймов 160x240 повёрнутые  на 270 градусов.

Но 2й фрейм не повернут))

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

Но это не означает, что его нельзя написать самому, переложив на SIMD.

Да, но пока только начинаю вникать в его команды, там не все так просто...

[GenaSPB 11]

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

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

[mantech 48]

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

 G2D_Rot.src_image.addr[0]=(u32)(TMPIMG_BASE); //Y
 
 G2D_Rot.dst_image.addr[0]=(u32)(SAVEFG_BASE); //Y

 

В вашем примере тут тоже какие-то расчеты были, или можно просто начала адресов буфера поставить?

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

Вопрос по координате выходного окна.

Если это ко мне вопрос, то честно говоря сам не знаю))

[GenaSPB 11]

13 minutes ago, mantech said:

Если это ко мне вопрос, то честно говоря сам не знаю))

Это к repstosw

[repstosw 18]

1 hour ago, mantech said:

Да, когда писал, что вывелся квадрат 1080 1080, в windowY указывал 741, видимо из расчета 1920-1080+1. Но как заставить выводить высотой не 1080, а 1920 пока х.з.((

С ходу так не определить... Для своих случаев я рисовал картинку на бумаге и арифметически рассчитывал.

В первом приближении - представить исходный прямоугольник с начальными координатами левого верхнего угла, затем его повернуть. И рассчитать новое положение этого угла - в координатах дисплея (дисплейного буфера)

1 hour ago, mantech said:

Но 2й фрейм не повернут))

Он повёрнут.  Просто камера одного из собеседников(слева) не была повёрнута на 90 градусов.

1 hour ago, GenaSPB said:

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

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

1 hour ago, GenaSPB said:

Еще, при повороте на 180 например, координата находится внутри выходного прямоугольника или на один пиксель правее-ниже?

Эксперименты покажут.

Для начала я бы всё-таки попытался вывести не 1920x1080,  а в 10 раз меньше 192x108 в центр экрана.  Тогда никаких вылетов за пределы видеопамяти не будет.

Затем нашёл бы формулу нахождения координат при нужном угле.

А потом -вернулся к 1920x1080

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

[mantech 48]

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

С ходу так не определить...

Так к слову, не знаете, где взять оригинальный исходник, о котором написано в RTOS_G2D_Development_Guide.pdf

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

 

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

[repstosw 18]

2 minutes ago, mantech said:

Так к слову, не знаете, где взять оригинальный исходник, о котором написано в RTOS_G2D_Development_Guide.pdf

Не знаю.

Мне достаточно было Linux-исходников.

 

Вот ещё что подумалось: если высота кадра всего 1080,  то повернутый прямоугольник 1920x1080 не влезет полность в экран, срежется снизу.   Скорее всего G2D не умеет отсечение.  Поэтому область задавать надо 1920x1920.

[mantech 48]

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

Поэтому область задавать надо 1920x1920.

Да уже всяко пробовал...

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

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

[repstosw 18]

2 hours ago, mantech said:

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

Не понял.  А в чём сложность расчитать самостоятельно координаты для вашего случая? Или проверить на мелком прямоугольнике?

[mantech 48]

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

А в чём сложность расчитать самостоятельно координаты для вашего случая?

Если б еще знать как их рассчитывать...

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

Или проверить на мелком прямоугольнике?

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

Ну и так-то уже проверял на мелком, на разрешениях до 1080х1080 работает, дальше режет..

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

[mantech 48]

16 часов назад, mantech сказал:

Вообщем попробую с исходником аллвиннера

 

1) Аллвиннеровский исходник заработал, как положено без всякой геометрии:

blit.flag_h=G2D_ROT_270;
blit.src_image_h.laddr[0]=(u32)(TMPIMG_BASE); //Y
blit.src_image_h.format=G2D_FORMAT_ABGR8888;//G2D_FMT_ABGR_AVUY8888;
blit.src_image_h.mode=G2D_GLOBAL_ALPHA;//G2D_FMT_ABGR_AVUY8888;
blit.src_image_h.clip_rect.x=0;
blit.src_image_h.clip_rect.y=0;
blit.src_image_h.clip_rect.w=1080;
blit.src_image_h.clip_rect.h=1920;
blit.src_image_h.width=1080;//Длина и ширина источника.
blit.src_image_h.height=1920;
blit.src_image_h.alpha=0xff;

blit.dst_image_h.laddr[0]=(u32)(SAVEFG_BASE); //Y
blit.dst_image_h.format=G2D_FORMAT_ABGR8888;//G2D_FMT_ABGR_AVUY8888;
blit.dst_image_h.mode=G2D_GLOBAL_ALPHA;//G2D_FMT_ABGR_AVUY8888;
blit.dst_image_h.clip_rect.x=0;
blit.dst_image_h.clip_rect.y=0;
blit.dst_image_h.clip_rect.w=1920;
blit.dst_image_h.clip_rect.h=1080;
blit.dst_image_h.width=1920;//Длина и ширина источника.
blit.dst_image_h.height=1080;
blit.dst_image_h.alpha=0xff;

g2d_blit_h(&blit);
 

 

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

[mantech 48]

11 часов назад, mantech сказал:

Но есть одна непонятная шляпа,

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

blit.src_image_h.laddr[0]=(u32)(TMPIMG_BASE); 

blit.dst_image_h.laddr[0]=(u32)(SAVEFG_BASE); 

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

[GenaSPB 11]

Протестировал повороты на голом железе.

Указывать надо всегда левый верхний угол буфера получателя. Как и источника. Размер в получателе вообще не влияет похоже.

Тестовая программа (в репо):

Рисует белые квадраты, затем с рвзными углами (и пара mirror) копирует туда неквадратный буфер с красной буфвой F нв синем фоне. со смещеием 1 пиксель, чтобы видеть, если вылезет за пределы ожидаемого.

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

[mantech 48]

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

Указывать надо всегда левый верхний угол буфера получателя.

Разумеется))  Про выравнивание не в курсе, там явно более 32 получается, скорее всего 0х1000, но жалко столько терять при выделении памяти((

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

Размер в получателе вообще не влияет похоже.

В моем примере на аллвиннеровском исходнике получатель имеет значение, при повороте нужно менять w на h, что логично при 90 и 270 град, китайцы почему-то в своей демке этого не указали))