[mantech 42]

В 04.07.2022 в 13:45, Arlleex сказал:

Но вот много ли кто готов туда погружаться - вопрос риторический.

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

[GenaSPB 11]

У меня система (упрввляющая/обрабатывающая звук программа SDR радиостанции) крутится в вариантах для двухядерных STM32MP157, ZYNQ 7020 и сейчас макет на Allwinner t113-s3.

Все кеши работают, так же работают спинлоки в общей памяти для разделения доступа к ресурсам когда надо... И без мейлбоксов. Что я делаю не так?

Изменено 4 июля, 2022 пользователем GenaSPB

[repstosw 18]

Запустил декодер JPEG (Cedar, CedarX, CedRUS , Кедр, ...) на T113-s3.  Модель точно такая же как в A13, даже базовый адрес регистров такой же.

Тактируется от PLL_VE на полных 432 МГц (по умолчанию), выше не ставил.  Но частота "Кедра" в T113-s3 выше, чем у A13 (вроде около 200 Мгц).

VDPAU SUNXI: 0x1667

 

Замер скорости сделаю чуть позже, надо бы ещё сравнить с софтовым JPEG-декодером (TJpgDec - Tiny JPEG Decompressor - от Чана).

  

 

 

 

 

Ещё бы надо подумать как вот это перенести на G2D - это детайлизатор-выпрямитель и конвертер YUV в RGB :

 

 

void output_ppm(struct jpeg_t *jpeg, uint8_t *luma_buffer, uint8_t *chroma_buffer,u32 x0,u32 y0)
{
	int x, y, i = 0;
	for (y = 0; y < jpeg->height; y++)
	{
		for (x = 0; x < jpeg->width; x++)
		{
			// reordering and colorspace conversion should be done by Display Engine Frontend (DEFE)
			int cy = y / jpeg->comp[0].samp_v;
float Y  = *((uint8_t *)(luma_buffer   + (x / 32) * 1024 +  (x % 32)              + (( y % 32) * 32) + (( y / 32) * (((jpeg->width + 31) / 32) * 1024))))        ;
float Cb = *((uint8_t *)(chroma_buffer + (x / 32) * 1024 + ((x % 32) / 2 * 2    ) + ((cy % 32) * 32) + ((cy / 32) * (((jpeg->width + 31) / 32) * 1024)))) - 128.0;
float Cr = *((uint8_t *)(chroma_buffer + (x / 32) * 1024 + ((x % 32) / 2 * 2 + 1) + ((cy % 32) * 32) + ((cy / 32) * (((jpeg->width + 31) / 32) * 1024)))) - 128.0;

			float R = Y + 1.402 * Cr;
			float G = Y - 0.344136 * Cb - 0.714136 * Cr;
			float B = Y + 1.772 * Cb;

			if (R > 255.0) R = 255.0;
			else if (R < 0.0) R = 0.0;

			if (G > 255.0) G = 255.0;
			else if (G < 0.0) G = 0.0;

			if (B > 255.0) B = 255.0;
			else if (B < 0.0) B = 0.0;

            *(u32*)(VIDEO_MEMORY0+(((LCD_PIXEL_WIDTH*(y+y0))+(x+x0))*BYTE_PER_PIXEL))=0xFF000000|(((u32)B)<<16)|(((u32)G)<<8)|((u32)R); //ABGR8888
		}
	}
}

 

Изменено 4 июля, 2022 пользователем repstosw

[Arlleex 160]

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

Все кеши работают, так же работают спинлоки в общей памяти для разделения доступа к ресурсам когда надо... Что я делаю не так?

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

[repstosw 18]

On 7/5/2022 at 12:25 AM, repstosw said:

Ещё бы надо подумать как вот это перенести на G2D - это детайлизатор-выпрямитель и конвертер YUV в RGB :

 

Интуиция не подвела. Вспомнил что я где-то видел в описании форматов G2D как раз те случаи, которые подойдут для детайлизатора JPEG:

 

	G2D_FMT_PYUV422UVC_MB16	= (0x21),
	G2D_FMT_PYUV420UVC_MB16	= (0x22),
	G2D_FMT_PYUV411UVC_MB16	= (0x23),
	G2D_FMT_PYUV422UVC_MB32	= (0x24),
	G2D_FMT_PYUV420UVC_MB32	= (0x25),
	G2D_FMT_PYUV411UVC_MB32	= (0x26),
	G2D_FMT_PYUV422UVC_MB64	= (0x27),
	G2D_FMT_PYUV420UVC_MB64	= (0x28),
	G2D_FMT_PYUV411UVC_MB64	= (0x29),
	G2D_FMT_PYUV422UVC_MB128 = (0x2A),
	G2D_FMT_PYUV420UVC_MB128 = (0x2B),
	G2D_FMT_PYUV411UVC_MB128 = (0x2C),

 

 

Интерес представляют как раз те, которые  32x32

Теоретически, задача по детайлизации и конверсии изображения решена.

[repstosw 18]

On 7/5/2022 at 1:07 AM, repstosw said:

Теоретически, задача по детайлизации и конверсии изображения решена.

  

А практически оказалось не так просто. В очередной раз линуксописатели надули: такие форматы не устанавливаются в текущей версии драйверов, функция заходит в ветку с return -1.

 

В итоге, взял детайлизатор на ассемблере: https://github.com/milosladni/sunxi-tvin2jpeg_h264/blob/master/tiled_yuv.S

И после как распрямил фрейм, прошёлся по нему G2D, который сконвертил YUV в RGB.

 

Сделал замеры скорости детайлизатора-конвертера:  тот что выше софтовый - в 17 раз медленее, чем ассемблерный + G2D.

 

Но из-за декодирования JPEG общий прирост скорости увеличился, но не на сильно много.

 

Для сравнения - слева как было, справа - как стало:

 

 

Вот кто мне скажет,  в каком исходнике линукса посмотреть код аппаратного детайлизатора - через G2D (вресия 2) или  через DEBE ?  Откуда код сдёрнуть можно?

 

 

Изменено 5 июля, 2022 пользователем repstosw

[mantech 42]

В 04.07.2022 в 17:25, repstosw сказал:

Замер скорости сделаю чуть позже, надо бы ещё сравнить с софтовым JPEG-декодером

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

[repstosw 18]

On 7/5/2022 at 9:28 PM, mantech said:

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

  

Подключил TJpgDec в проект и сравнил его с CedarX. При этом для ускорения работы TJpgDec использовал инструкцию сатурации байта: #define BYTECLIP(x) __USAT(x,8).

 

Исходные данные: картинка JPEG, 800x480, качество сжатия 90%, формат сжатия YUV420. Видеорежим - RGB888 (3 байта на пиксел).

  

Результаты:

 

1). TJpgDec: чисто декодирование, с отключенной функцией mcu_output (отключены: детайлизатор, конвертер YUV>RGB, вывод на дисплей) - 53,008 мс

 

2). TJpgDec: декодирование + детайлизатор + конвертер YUV>RGB + вывод на дисплей(memcpy NEON) - 65,927 мс

 

3). CedarX: чисто декодировние, с отключенными детайлизатором(на ассемблере), с отключенным конвертером YUV>RGB и без вывода на дисплей (всё через G2D) - 4,341 мс

 

4). CedarX: декодирование + детайлизатор(ассемблерный вариант) + конвертер YUV>RGB + вывод на дисплей (через G2D) - 6,468 мс

  

Расчёт выигрышей:

 

Выигрыш в чистом декодировании  CedarX: 53,008/4,341 = 12 раз

 

Выигрыш в детайлизации+ конверсии YUV>RGB + вывод на дисплей: 12,919/2,127 = 5,7 раз

 

Полный выигрыш (декодирование + детайлизация + конверсия YUV>RGB + вывод на дисплей): 65,927/6,468 = 10 раз

 

Вывод:

 

CedarX и G2D уделали TJpgDec

Изменено 5 июля, 2022 пользователем repstosw

[sasamy 3]

On 7/5/2022 at 10:05 AM, repstosw said:

через DEBE

DE точно поддерживает тайловые форматы на входе и может выполнить CSC (Color Space Conversion) NV12 -> RGB налету, посмотрел бегло  - вас наверно интересует эта ф-ция

https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/sun4i/sun4i_frontend.c#L400

потыкайте там ссылки и всё выяснится что надо записать в регистры для входного формата NV12 (этот формат на выходе декодера VPU) с учётом того что это  YUV с сабсэмплингом 4:2:0

[mantech 42]

В 05.07.2022 в 18:15, repstosw сказал:

Выигрыш в чистом декодировании  CedarX: 53,008/4,341 = 12 раз

Супер! Очень хороший результат.

[mantech 42]

В 04.07.2022 в 10:01, GenaSPB сказал:

Host я запустил  давно на ehci. 

Посмотрел, в ваших исходниках работа с хабами отключена, если не секрет, почему?  Сейчас решил подключить хаб, энумерация проходит, attach / detach  выполяется, но на энумерации подключенной к хабу флешки виснет(( Хотя флешка, подключенная непосредственно к порту проходит все стадии и готова к работе...

[GenaSPB 11]

Как раз с хабом включено всегда. Лог.

У меня нет  нотификаций с хаба - флешку вклчать до запуска.

 

Кстати, нашлась usbphy0 (+0x400 от DRD) - возможно и EHCI на 0-м порту и USB DRD заработает после запуска без XFEL, из QSOI).

Изменения в github

 

 

 

[GenaSPB 11]

On 7/5/2022 at 11:50 PM, GenaSPB said:

EHCI на 0-м порту

не заработало

On 7/5/2022 at 11:50 PM, GenaSPB said:

USB DRD заработает после запуска без XFEL, из QSOI

Помогло

Изменено 5 июля, 2022 пользователем GenaSPB

[mantech 42]

В 06.07.2022 в 00:31, GenaSPB сказал:

не заработало

В смысле? Как раз EHCI на 0м (в v3s он единственный) порту и работает, про него и писал. Но с хабом странно, как он у вас работает, если в исходниках функции аттач\детач все были закомментированы?)))))))))

[repstosw 18]

On 7/6/2022 at 3:14 AM, sasamy said:

DE точно поддерживает тайловые форматы на входе и может выполнить CSC (Color Space Conversion) NV12 -> RGB налету, посмотрел бегло  - вас наверно интересует эта ф-ция

https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/sun4i/sun4i_frontend.c#L400

потыкайте там ссылки и всё выяснится что надо записать в регистры для входного формата NV12 (этот формат на выходе декодера VPU) с учётом того что это  YUV с сабсэмплингом 4:2:0

 

Честно говоря, по вышеприведённой ссылке ничего не понял, что там делается.  Дело в том, что NV12 к тайлам никакого отношения не имеет.

Удалось избавиться от детайлизации вообще!

 

Здесь из описания регистров "Кедра" https://linux-sunxi.org/VE_Register_guide  нашлись те, которые управляют выходным форматом декодера: MACC_VE_EXTRA_OUT_FMT_OFFSET и MACC_VE_OUTPUT_FORMAT.

 

Выставил режим NV12, с которым G2D дружит. По умолчанию стоял  32x32 tile format.

 

 

        MACC_VE_OUTPUT_FORMAT&=~7;
        MACC_VE_OUTPUT_FORMAT|=4;                 //NV12

        MACC_VE_EXTRA_OUT_FMT_OFFSET&=~(3UL<<30);
        MACC_VE_EXTRA_OUT_FMT_OFFSET|=(1UL<<30);  //use special format from MACC_VE_OUTPUT_FORMAT

 

Хоть там и пишут, что они работают начиная с версии VDPAU 0x1680, к счастью, на T113-s3 (VDPAU 0x1667) они дали эффект: содержимое буфера теперь распрямилось, и уже не тайловое.

Далее запускаем G2D: конвертим им YUV>RGB  и отрисовываем на диcплей:

 

void output_ppm(struct jpeg_t *jpeg, uint8_t *luma_buffer, uint8_t *chroma_buffer,u32 x0,u32 y0)
{
 G2D_BLT.flag=G2D_BLT_NONE;

 G2D_BLT.src_image.addr[0]=(u32)luma_buffer;
 G2D_BLT.src_image.addr[1]=((u32)chroma_buffer)+1;
 G2D_BLT.src_image.addr[2]=((u32)chroma_buffer)+0;

 G2D_BLT.src_image.w=jpeg->width;
 G2D_BLT.src_image.h=jpeg->height;

 G2D_BLT.src_image.format=G2D_FMT_PYUV420UVC;
 G2D_BLT.src_image.pixel_seq=G2D_SEQ_NORMAL;

 G2D_BLT.src_rect.x=0;
 G2D_BLT.src_rect.y=0;

 G2D_BLT.src_rect.w=jpeg->width;
 G2D_BLT.src_rect.h=jpeg->height;

 G2D_BLT.dst_image.addr[0]=VIDEO_MEMORY1;

 G2D_BLT.dst_image.w=LCD_PIXEL_WIDTH;
 G2D_BLT.dst_image.h=LCD_PIXEL_HEIGHT;

 G2D_BLT.dst_image.format=G2D_FMT_BGR888;
 G2D_BLT.dst_image.pixel_seq=G2D_SEQ_NORMAL;

 G2D_BLT.dst_x=x0;
 G2D_BLT.dst_y=y0;

 G2D_BLT.color=0x000000;
 G2D_BLT.alpha=0xFF;

 g2d_blit(&G2D_BLT);
}

 

On 7/6/2022 at 3:14 AM, sasamy said:

CSC (Color Space Conversion) NV12 -> RGB налету,

 

Как раз в коде G2D этот CSC используется.

 

Обнаружил ещё один недочёт в коде G2D (T113 Tina Linux) - неправильно работает шаг приращения в видеопамяти, когда входное изображение YUV420 и размеры источника = размерам приёмника. Исправил.

А вообще, этот Tina Linux очень сырой, полагаю, его ещё будут пилить и шлифовать.

 

 

Общее время декодирования уменьшилось с 6,468 мс до 5,332 мс - за счёт исключения детайлизатора и сброса с кеша.

Осталось выкинуть из цепочки G2D - заставить декодер рисовать прямо на дисплей, конвертируя кадр с помощью CSC.

Изменено 6 июля, 2022 пользователем repstosw