mantech 48 4 июля, 2022 Опубликовано 4 июля, 2022 · Жалоба В 04.07.2022 в 13:45, Arlleex сказал: Но вот много ли кто готов туда погружаться - вопрос риторический. Делал на 2х ядрах, но сразу поставил для себя задачу - это будут изолированные процессы, которые общаются между собой через отдельный мейлбокс в памяти... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
GenaSPB 11 4 июля, 2022 Опубликовано 4 июля, 2022 (изменено) · Жалоба У меня система (упрввляющая/обрабатывающая звук программа SDR радиостанции) крутится в вариантах для двухядерных STM32MP157, ZYNQ 7020 и сейчас макет на Allwinner t113-s3. Все кеши работают, так же работают спинлоки в общей памяти для разделения доступа к ресурсам когда надо... И без мейлбоксов. Что я делаю не так? Изменено 4 июля, 2022 пользователем GenaSPB Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
repstosw 18 4 июля, 2022 Опубликовано 4 июля, 2022 (изменено) · Жалоба Запустил декодер 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 173 4 июля, 2022 Опубликовано 4 июля, 2022 · Жалоба 1 час назад, GenaSPB сказал: Все кеши работают, так же работают спинлоки в общей памяти для разделения доступа к ресурсам когда надо... Что я делаю не так? Все так, главное, чтобы понимание было, говорю же. Я имею ввиду, что есть и варианты поинтереснее. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
repstosw 18 4 июля, 2022 Опубликовано 4 июля, 2022 · Жалоба 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 5 июля, 2022 Опубликовано 5 июля, 2022 (изменено) · Жалоба 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 48 5 июля, 2022 Опубликовано 5 июля, 2022 · Жалоба В 04.07.2022 в 17:25, repstosw сказал: Замер скорости сделаю чуть позже, надо бы ещё сравнить с софтовым JPEG-декодером Пока не замеряли? А то интересно, сам сейчас тоже декодер чановский использую, посмотреть, на сколь аппаратный быстрее))) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
repstosw 18 5 июля, 2022 Опубликовано 5 июля, 2022 (изменено) · Жалоба 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 1 5 июля, 2022 Опубликовано 5 июля, 2022 · Жалоба 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 48 5 июля, 2022 Опубликовано 5 июля, 2022 · Жалоба В 05.07.2022 в 18:15, repstosw сказал: Выигрыш в чистом декодировании CedarX: 53,008/4,341 = 12 раз Супер! Очень хороший результат. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 48 5 июля, 2022 Опубликовано 5 июля, 2022 · Жалоба В 04.07.2022 в 10:01, GenaSPB сказал: Host я запустил давно на ehci. Посмотрел, в ваших исходниках работа с хабами отключена, если не секрет, почему? Сейчас решил подключить хаб, энумерация проходит, attach / detach выполяется, но на энумерации подключенной к хабу флешки виснет(( Хотя флешка, подключенная непосредственно к порту проходит все стадии и готова к работе... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
GenaSPB 11 5 июля, 2022 Опубликовано 5 июля, 2022 · Жалоба Как раз с хабом включено всегда. Лог. У меня нет нотификаций с хаба - флешку вклчать до запуска. Кстати, нашлась usbphy0 (+0x400 от DRD) - возможно и EHCI на 0-м порту и USB DRD заработает после запуска без XFEL, из QSOI). Изменения в github Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
GenaSPB 11 5 июля, 2022 Опубликовано 5 июля, 2022 (изменено) · Жалоба 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 48 6 июля, 2022 Опубликовано 6 июля, 2022 · Жалоба В 06.07.2022 в 00:31, GenaSPB сказал: не заработало В смысле? Как раз EHCI на 0м (в v3s он единственный) порту и работает, про него и писал. Но с хабом странно, как он у вас работает, если в исходниках функции аттач\детач все были закомментированы?))))))))) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
repstosw 18 6 июля, 2022 Опубликовано 6 июля, 2022 (изменено) · Жалоба 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 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться