Allwinner A13 SoC уделал DSP C6745. Смеяться или плакать?

[mantech 1]

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

Современная культура программирования - превращать всё в неповоротливые фрейм-ворки...

Это да, но мое мнение - это еще и ради того, чтобы покупали все более и более производительные компы.

[Niyaz 0]

Я использовал эту библиотеку: https://github.com/aodzip/cedar и https://github.com/aodzip/libcedarc и ffmpeg для кодирования h264, получил максимум [email protected] на v3s, там cpu 100% загрузка ( через perf смотрел 40% cpu использовал v4l2-copy_from_user)

[aaarrr 1]

1 hour ago, mantech said:

Это да, но мое мнение - это еще и ради того, чтобы покупали все более и более производительные компы.

...и запускали на них классные IDE!

 

1 hour ago, Niyaz said:

Я использовал эту библиотеку: https://github.com/aodzip/cedar и https://github.com/aodzip/libcedarc и ffmpeg для кодирования h264, получил максимум [email protected] на v3s, там cpu 100% загрузка ( через perf смотрел 40% cpu использовал v4l2-copy_from_user)

Можно получить 0% загрузки CPU, если исключить ручное копирование данных.

[mantech 1]

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

...и запускали на них классные IDE!

IDE не требует больших ресурсов ЦП (если не на ява-питоне писано, разумеется).

[aaarrr 1]

2 minutes ago, mantech said:

IDE не требует больших ресурсов ЦП (если не на ява-питоне писано, разумеется).

IDE - это часть той самой культуры. Тут уж или Makefile уметь, или о падении нравов не брюзжать

[Niyaz 0]

13 minutes ago, aaarrr said:

...и запускали на них классные IDE!

 

Можно получить 0% загрузки CPU, если исключить ручное копирование данных.

а что это? я в коде копался libavdevice/v4l2.c там вроде V4L2_MEMORY_MMAP, тоже самое видел в bsp версий проекта для v3s (camdroid вроде,  где работет 1080p30fps). Мне где и что копать можете подсказать? это в коде вообще править? 

[aaarrr 1]

4 minutes ago, Niyaz said:

а что это?

Используйте dmabuf. Нужно немного заправить libcedarc, чтобы получить файловые дескрипторы:

Spoiler

diff --git a/include/sc_interface.h b/include/sc_interface.h
index d240bcf..648efd5 100755
--- a/include/sc_interface.h
+++ b/include/sc_interface.h
@@ -62,6 +62,8 @@ struct ScMemOpsS
     void *(*palloc_secure)(int /*size*/, void*, void*);
 
     unsigned int (*get_ve_addr_offset)(void);
+
+    int (*get_dmabuf_fd)(void *);
 };
 
 static inline int CdcMemOpen(struct ScMemOpsS *memops)
diff --git a/memory/ionMemory/ionAlloc.c b/memory/ionMemory/ionAlloc.c
index f949a13..42c698d 100755
--- a/memory/ionMemory/ionAlloc.c
+++ b/memory/ionMemory/ionAlloc.c
@@ -957,6 +957,37 @@ unsigned int ion_alloc_get_ve_addr_offset()
     }
 }
 
+int ion_get_dmabuf_fd(void *pbuf)
+{
+    unsigned long addr_vir = (unsigned long)pbuf;
+    buffer_node *tmp;
+    int fd = -1;
+
+    if (0 == pbuf) {
+        loge("NULL pointer\n");
+        return -1;
+    }
+
+    pthread_mutex_lock(&g_mutex_alloc);
+
+    if (g_alloc_context == NULL) {
+        loge("g_alloc_context missing\n");
+        pthread_mutex_unlock(&g_mutex_alloc);
+        return -1;
+    }
+
+    aw_mem_list_for_each_entry(tmp, &g_alloc_context->list, i_list)
+    {
+        if (tmp->vir == addr_vir)
+        {
+            fd = tmp->fd_data.aw_fd;
+            break;
+        }
+    }
+
+    pthread_mutex_unlock(&g_mutex_alloc);
+    return fd;
+}
 
 struct ScMemOpsS _ionMemOpsS =
 {
@@ -977,7 +1008,8 @@ struct ScMemOpsS _ionMemOpsS =
     setup:                ion_alloc_setup,
     shutdown:            ion_alloc_shutdown,
     palloc_secure:      ion_alloc_alloc_drm,
-    get_ve_addr_offset: ion_alloc_get_ve_addr_offset
+    get_ve_addr_offset: ion_alloc_get_ve_addr_offset,
+    get_dmabuf_fd:      ion_get_dmabuf_fd
 };
 
 struct ScMemOpsS* __GetIonMemOpsS()

 

которые затем скармливаются v4l2.

[mantech 1]

27 минут назад, aaarrr сказал:

IDE - это часть той самой культуры. Тут уж или Makefile уметь, или о падении нравов не брюзжать

Нет уж, спасибо, ком.строки и пр. - пережиток каменного века, к счастью давно минувшего)))

Для любителей оного, предлагаю не пользоваться софтом, типа ворда, ехселя и подобного, а набирать тексты в командной строке или текстовом редакторе конца 80х)))))))))) Ну и графика под запрет вообще, только 80х25 текстовый режим - "только хардкор"))))))

ЗЫ. А вообще, если без хи-хи, то я имел ввиду "писателей", которые вместо компилируемых языков используют всякие скрипты и интерпретаторы - вот это зло и жесть...

Edited April 22 by mantech

[jcxz 4]

32 минуты назад, mantech сказал:

IDE не требует больших ресурсов ЦП (если не на ява-питоне писано, разумеется).

Точно? Интересно - почему тогда у меня IAR (довольно старый уже 7.80.4) запускается секунд 15?? И это - на i7 да с хорошего, серверного SSD.  

[repstosw 0]

1 hour ago, mantech said:

Нет уж, спасибо, ком.строки и пр. - пережиток каменного века, к счастью давно минувшего)))

Я как раз использую командную строку.  IDE не использую: они глючные и имеют тенденцию становиться неповоротливыми.

Тот же упомянутый придурошный IAR - проще было скрипт линковщика самому написать, чем ковыряться в его негибких настройках.

Весь код пишу в Bred3.0.3U или Notepad++ по настроению.

Под винду тоже собираю с командной строки.

И под Линукс тоже...

Последний раз пользовался IDE IAR, по работе, так как заказчик требует чтоб проект был в IAR

 

3 hours ago, Niyaz said:

Я использовал эту библиотеку: https://github.com/aodzip/cedar и https://github.com/aodzip/libcedarc и ffmpeg для кодирования h264, получил максимум [email protected] на v3s, там cpu 100% загрузка ( через perf смотрел 40% cpu использовал v4l2-copy_from_user)

По кодированию на гитхабе много чего есть.  А вот по декодированию?  Пару примеров нашёл, но они под Линукс

Интересует пример декодирования сырого потока H264 (без контейнеров всяких, MPC HC под ПК умеет это) c базовыми параметрами декодирования (baseline, YUV420, no cabac, ит.д.)

Edited April 22 by repstosw

[mantech 1]

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

Интересно - почему тогда у меня IAR (довольно старый уже 7.80.4) запускается секунд 15??

Да мне без разницы сколько он запускается, хотя у меня на cel B 815, т.е. в разы хуже вашего, иар 6.50 запускается секунд 10, на обычном харде 320гиг, а больше важно, сколько он компилирует...

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

Тот же упомянутый придурошный IAR - проще было скрипт линковщика самому написать, чем ковыряться в его негибких настройках.

Проблем нет вообще, все работвает, как положено и плотность кода куда лучше, чем ГЦЦ.

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

По кодированию на гитхабе много чего есть.  А вот по декодированию?  Пару примеров нашёл, но они под Линукс

Дак там этого процентов 99, наверно, вот без линукса найти - это не просто...

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

Интересует пример декодирования сырого потока H264 (без контейнеров всяких, MPC HC под ПК умеет это)

А почему без контейнеров? Где этот сырой поток применить, или ради того, что разбираться проще?

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

IDE не использую: они глючные и имеют тенденцию становиться неповоротливыми.

А просто не надо гнаться за последними версиями, их походу тоже уже переписали под всякие скрипты, в угоду кроссплатформенности... К примеру, тот же иар гораздо более шустрый, чем эклипс, но к сожалению для гцц, кроме него и ком. строки больше ничего нет((

Edited April 22 by mantech

[repstosw 0]

4 hours ago, mantech said:

А почему без контейнеров? Где этот сырой поток применить, или ради того, что разбираться проще?

Потому что контейнеры - это ещё один слой абстракций данных.

Сырой поток H264 умеет показывать программа MPC HC : https://mpc-hc.org/

 

Файлы с расширением .h264

Просто сырой поток - фреймы и минимум служебной информации. Легко парсится, в отличие от всяких MP4, AVI и прочих

Edited April 22 by repstosw

[repstosw 0]

On 4/21/2022 at 7:51 PM, repstosw said:

P.S. Теперь надо попробовать всё это перетащить на V3s.

Декодер не заработал с тем софтом, что для A13.

Даже с этим:

 SRAM_CTL0_CFG0&=0x80000000;
 SRAM_CTL0_CFG0|=0x7FFFFFFF; //enable SRAM for VE

Мало того,  оно забирает SRAM C у V3s, которая по адресам 0x4000....  Пришлось лепить загрузчики и приложение во внешней памяти.

Очень обидно и досадно, что не работает.

[mantech 1]

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

Декодер не заработал с тем софтом, что для A13.

На сколь помню, в А13 дисплейный модуль был DE, а в v3s - DE2.0, инит тоже немного отличается, вполне и у VE тоже несколько другая версия...

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

Пришлось лепить загрузчики и приложение во внешней памяти.

А до этого все в статике делали?))

[repstosw 0]

3 hours ago, mantech said:

На сколь помню, в А13 дисплейный модуль был DE, а в v3s - DE2.0, инит тоже немного отличается, вполне и у VE тоже несколько другая версия...

Вполне возможно. Тем более, в даташите на V3s ни слова о разрешении SRAM для VE, описания регистров нет. Сделал как в исходниках у Ozelot.

Вот нахрена они так делают?

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

Очевидно, меняется сам алгоритм работы кодека.

У A13 версия "Кедра" 0x1625

У V3s 0x1681

В линуксовых исходниках есть пара отличий для 0x1681, я их внёс, но всёравно не работает.  Движок не записывает результат в память - она остаётся нетронута.

 

3 hours ago, mantech said:

А до этого все в статике делали?))

Пока места хватает - делаю в статике.

И снова A13  в выигрыше.

У V3s разрешено только 16 кБ.