Comments 10
Меня недавно попросили помочь с разработкой модуля компьютерного зрения для коптера и спросили про DSP (т.к. на нем реализовывали поиск ключевых точек на изображении и добивались 30FPS).
Я никогда не имел с ним дело, но как я понял после поверхностного изучения, чтобы заставить его работать с OpenCV нужна промежуточноя библиотека, реализация которой зависит от самого процесора. Плюс DSP работает только с целыми числами, отсюда не все алгоритмы можно портировать на него (ваша таблица это подтвердает). То есть есть большая зависимость от конкретного железа.
Поэтому я сделал на плате Jetson, где, кстати полноценный gpu и официальная поддержка OpenCV.
Дествительно ли c DSP много подобных сложностей или я преувеличил?
Я никогда не имел с ним дело, но как я понял после поверхностного изучения, чтобы заставить его работать с OpenCV нужна промежуточноя библиотека, реализация которой зависит от самого процесора. Плюс DSP работает только с целыми числами, отсюда не все алгоритмы можно портировать на него (ваша таблица это подтвердает). То есть есть большая зависимость от конкретного железа.
Поэтому я сделал на плате Jetson, где, кстати полноценный gpu и официальная поддержка OpenCV.
Дествительно ли c DSP много подобных сложностей или я преувеличил?
Спасибо за вопрос, victor1234.
Да, сложностей много, и зависимость от железа большая. Нужна даже не промежуточная библиотека, а переписанная библиотека c использованием специфичных функций DSP.
DSP, который мы использовали в статье, поддерживает операции с плавающей точкой, но эта поддержка есть не у всех DSP-процессоров.
Наша таблица не подтверждает, что не все алгоритмы OpenCV можно портировать, она лишь говорит о том, что разработчики С6Accel портировали не все. :)
Да, сложностей много, и зависимость от железа большая. Нужна даже не промежуточная библиотека, а переписанная библиотека c использованием специфичных функций DSP.
DSP, который мы использовали в статье, поддерживает операции с плавающей точкой, но эта поддержка есть не у всех DSP-процессоров.
Наша таблица не подтверждает, что не все алгоритмы OpenCV можно портировать, она лишь говорит о том, что разработчики С6Accel портировали не все. :)
Говорю, как человек, который имел дело с DSP. Почти все алгоритмы можно портировать на DSP. Некоторые кладутся на инструкции лучше, некоторые хуже.
Некоторые алгоритмы вообще за вменяемое время невозможно заставить работать из-за их особенностей. В таких случаях часть логики делают в виде электронной схемы на железе.
А арифметику с плавающей точкой на DSP заменяют арифметикой с фиксированной точкой — en.wikipedia.org/wiki/Fixed-point_arithmetic
С разбегу в арифметику с фиксированной точкой конечно же не въедешь. И за месяц экспертом по портированию алгоритмов на DSP тоже не стать.
Некоторые алгоритмы вообще за вменяемое время невозможно заставить работать из-за их особенностей. В таких случаях часть логики делают в виде электронной схемы на железе.
А арифметику с плавающей точкой на DSP заменяют арифметикой с фиксированной точкой — en.wikipedia.org/wiki/Fixed-point_arithmetic
С разбегу в арифметику с фиксированной точкой конечно же не въедешь. И за месяц экспертом по портированию алгоритмов на DSP тоже не стать.
Скажите, если стоит задача компьютерного зрения, где важен вес, размер, да и стоимость. На сколько рационально и реально пытаться портировать OpenCV на DSP?
Какие приблизительно процессоры подойдут, на сколько код будет портируем между ними и на какое время расчитывать, учитывая, что с OpenCV я работаю достаточно долго и внутреннее устройство ее представляю, а с DSP не работал никогда?
Сориентируйте, если возможно.
Какие приблизительно процессоры подойдут, на сколько код будет портируем между ними и на какое время расчитывать, учитывая, что с OpenCV я работаю достаточно долго и внутреннее устройство ее представляю, а с DSP не работал никогда?
Сориентируйте, если возможно.
Зависит от задач конечно. DSP-шки применяют обычно для того, чтобы выполнить алгоритм достаточно быстро и за малое энергопотребление. В тех же телефонах аппаратные кодеки — это и есть эти самые DSP-шки с прошивкой из оптимизированного бинарного кода.
Обычно оптимизация звукового какого-то кодека занимает от 2 до 6-х человеко-месяцев. При этом подрузамевается, что человек или группа людей уже имеет опыт такой деятельности. Но это мы выжимали из DSP все соки. Абсолютно все соки.
Основная часть оптимизаций идет за счет VLIW архитектуры. Компиляторы конечно умные, но не настолько, чтобы распараллелить алгоритм на несколько одновременных частей. Для большего понимания, на отладочной платы из статьи стоит DSP C674x. Открываем доку на эту DSP: www.ti.com/lit/ug/sprufe8b/sprufe8b.pdf
В разделе «1.2. DSP Features and Options» видим основные характеристики:
— 64 general-purpose 32-bit registers
— Eight functional units:
— — Two multipliers
— — Six ALUs
— Executes up to eight instructions per cycle
Т.е. за такт можно исполнить 2 умножения и по одной какой-то инструкции из каждого ALU. Всего — 8 инструкций за такт. Но не все комбинации процессорных команд возможны. В той же доке такие ограничения описаны например в «3.8 Resource Constraints».
И так у каждого DSP проца: своя дока, свои инструкции, свое количество регистров, свои ограничения на набор инструкций в одном пакете. Я к тому, что один раз заоптимизированный алгоритм, при переходе на другой DSP проц, приходится оптимизировать почти заново.
По итогу, жесткие оптимизации + куча человеко-времени и алгоритм начинает работать за приемлемое количество тактов процессора и становится пригоден для использования в realtime.
Обычно оптимизация звукового какого-то кодека занимает от 2 до 6-х человеко-месяцев. При этом подрузамевается, что человек или группа людей уже имеет опыт такой деятельности. Но это мы выжимали из DSP все соки. Абсолютно все соки.
Основная часть оптимизаций идет за счет VLIW архитектуры. Компиляторы конечно умные, но не настолько, чтобы распараллелить алгоритм на несколько одновременных частей. Для большего понимания, на отладочной платы из статьи стоит DSP C674x. Открываем доку на эту DSP: www.ti.com/lit/ug/sprufe8b/sprufe8b.pdf
В разделе «1.2. DSP Features and Options» видим основные характеристики:
— 64 general-purpose 32-bit registers
— Eight functional units:
— — Two multipliers
— — Six ALUs
— Executes up to eight instructions per cycle
Т.е. за такт можно исполнить 2 умножения и по одной какой-то инструкции из каждого ALU. Всего — 8 инструкций за такт. Но не все комбинации процессорных команд возможны. В той же доке такие ограничения описаны например в «3.8 Resource Constraints».
И так у каждого DSP проца: своя дока, свои инструкции, свое количество регистров, свои ограничения на набор инструкций в одном пакете. Я к тому, что один раз заоптимизированный алгоритм, при переходе на другой DSP проц, приходится оптимизировать почти заново.
По итогу, жесткие оптимизации + куча человеко-времени и алгоритм начинает работать за приемлемое количество тактов процессора и становится пригоден для использования в realtime.
Мне удалось немного поработать с чем-то похожим (TI DM36x), конкретней со связкой ARM(linux) + DSP. Ощущения остались двоякие, с одной стороны эта был первый опыт с подобными SoC, с другой нагромождение API и витиеватая система сборки с java кодом потребовала немало усилий чтобы перейти к задаче от борьбы с тулчейном и «API». К тому же очень болезненна прошла смена версии ядра на отличную от SDK.
Приходилось ли Вам выходить за рамки этих готовых интерфейсов и зачем? Как отлаживали DSP код кроме dbgprintf (всякие CE_DEBUG=..)?
Приходилось ли Вам выходить за рамки этих готовых интерфейсов и зачем? Как отлаживали DSP код кроме dbgprintf (всякие CE_DEBUG=..)?
nickpetrovsky, спасибо, что поделились впечатлениями о работе с ARM(linux) + DSP.
Для автора статьи это был первый опыт с SoC такого рода. Выходить за рамки готового пока не приходилось, но предвидится задача преобразования теста функций OpenCV на ARM и DSP в программу для конкретных вычислений. Насчет отладки можно лишь сказать про существование Code Composer Studio(CCS).
Для автора статьи это был первый опыт с SoC такого рода. Выходить за рамки готового пока не приходилось, но предвидится задача преобразования теста функций OpenCV на ARM и DSP в программу для конкретных вычислений. Насчет отладки можно лишь сказать про существование Code Composer Studio(CCS).
Ещё отметим, что на TI DM36x доступен не DSP, а HDVICP и MPEG/JPEG co-processor.
Sign up to leave a comment.
Использование DSP-сопроцессора DM8168 с помощью фреймворка C6Accel