Здравствуйте,

Есть такое устройство: Nokia 770. Там имеется два ядра: ARM9E и C55x, оба работают на частоте 252MHz (OMAP1710, возможно "официально" разогнанный). Для доступа к DSP используется dspgateway.

Я сейчас занимаюсь оптимизацией MPlayer для Nokia 770/N800, пока только с использованием ARM ядра (поскольку раньше ни разу не имел дел с DSP). DSP в MPlayer на данный момент в используется только для декодирования mp3 аудио с использованием бинарного нокиевского предустановленного кодека.

Хотелось бы узнать, насколько это DSP ядро перспективно использовать для декодирования видео по сравнению с ARM. Больше всего интересует видео mpeg4 part2 (DIVX/XVID). Причем как с теоретической точки зрения (насколько C55x потенциально быстрее, чем ARM9E?), так и с практической - возможность и трудоемкость портирования какой-либо существующей open source библиотеки, например XVID или FFmpeg.

Было бы интересно узнать мнение профессионалов. Стоит ли вообще пытаться?

при прочих равных (тактовая, примерно тот-жен объем on-chip memory) - в задачах ЦОС сильно быстрее

думаю стоит.
притом с нуля на ассемблере писать оптимизированный под DSP-ядро процедуры нет необходимости писать - всё сделано TI за вас и для вас - полностью свободные и открытые библиотеки:
TMS320C55x DSP Library
TMS320C55x Image Library
кстати, там же в документации приведены benchmark для конкретных функций, реализованных в этих бибилиотеках.


off
что-то нокиевцы никак с ОМАРов не соскочат - в N800 снова ОМАР ((( нет бы туда DaVinci какой поставить (как, кстати, давно и успешно делают производители портативных hdd-медиаплейеров). Тогда бы ис производительностью ЦОС-приложений при соответствующей оптимизации веселее стало бы.

Дык в том дело, что давинчи не делаются с нужным набором периферии. А омапы делаются. А вот IVA2/IVA2+, который использован в давинчах, используется и в омапах, например в OMAP3430. Так что омапы давинчам вовсе не уступают.

Наконец-то нашлось время на попытки разобраться с DSP и появились новые вопросы

Сейчас компилирую код с использованием free toolchain от TI (code generation tools 2.56) по ссылке с http://maemo.org/community/wiki/dspprogramming/

Всплыла проблема с "заворачиванием" указателя на границу страницы. Т.е., если мы имеем, например, код вроде "sum += *buffer++;", то когда указатель пытается пересечь границу страницы, меняются только младшие 16 бит адреса. Например, указатель перескакивает с 0x10FFFF на 0x100000 вместо 0x110000. Все это делает работу с большими буферами данных несколько трудоемкой.

В интернете нашел информацию о том, что эта фигня должна быть исправлена в c55x silicon revision 3.x. В частности, об этом говорится в spru599d.pdf

Также вот этот pdf файл как будто бы утверждает, что и в OMAP1710 (Nokia 770), и в OMAP2420 (Nokia N800 и N810) используется c55x silicon revision 3.0: http://www.ocpip.org/japanese/news/present...ese_JapanTI.pdf

Так в чем же собственно дело? То ли в данных OMAP'ах не rev.3 и японцы врут. То ли процессор работает в каком-то режиме совместимости с предыдущими ревизиями и 23-битную адресацию надо как-то явно включить.

Можно ли где-то найти более подробную информацию про rev.3? Используется ли данная ревизия в чипах, доступных для "простых смертных" и имел ли кто-либо опыт работы с ними?

Похоже, с этой page boundary crossing проблемой мучаюсь не я один: http://www.dsprelated.com/groups/c55x/show/631.php

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

PS. Еще нашел и скачал с ftp чуть более свежую версию code generation tools (2.75), с ней проблема та же самая: ftp://ftp.ti.com/pub/cs/v275/

Sorry, что тема потихоньку сползла от алгоритмов декодирования видео на особенности конкретной железки, но если вдруг кому будет интересно, вот ссылка на информацию про C55x rev3 и полноценную 23-битную flat адресацию: http://www.dsprelated.com/groups/c55x/show/1657.php

Буду продолжать разбираться дальше. Один из следующих вопросов на повестке дня - поддержка motion compensation в image library. Насколько я вижу, там присутствует единственная функция "IMG_pix_inter_16x16". А хотелось бы получить полноценный halfpixel и quarterpixel motion compensation, причем не только для 16x16, но и для 8x8.