Comments 9
Спасибо за хорошую статью!
44 секунды вышло только потому что код находился в QSPI памяти а она очень медленная.
А ещё лучше QSPI и SDRAM памятью не пользоваться — она всего 100-150мб/сек когда внутренняя доходит до 4200мб/сек.
Пример влияния этих видов памяти:
Я например запускал в таком конфиге MobileNetV2 224х224 на 1000 классов, выходило 30-40секунд.
А когда запустил полностью из DTCM подгружая по необходимости всего один раз нужные куски W и B то скорость возросла почти в десятки раз, речь уже зашла о FPS и сетка заработала в реалтайме (входа, выхода и промежуточные расчёты — 16бит квантизации, а W и B сжаты адуиокодеком до 8 бит с расжатие до 16 бит в DTCM памяти — чтоб быстрее загружалось, загрузка по DMA пока считается текущая свёртка).
Я тоже портировал OpenCV но кусками, вышло в десятки раз быстрее чем оригинальный OpenCV даже на ПК. т.к. я затачивал только под монохром и конкретные задачи (бит хакинг, спец битовые инструкции поиска нуля и все дела, прямо молодость вспомнил как оптимизировал битовые операции для EGA режима 20 лет назад!).
Например вот поиск точек по равнобедренному треугольнику (10мс на кадр 480х240)
аналог ConnectedComponentsWithStats
www.youtube.com/watch?v=210UZUjZwBs
тут опубликовано:
github.com/Mirn/F745_realtime_triangle_recognition
Или вот детектор вторжения просто сравнение с фоном при помощи фильтров (так же около 20 мс на кадр)
аналог вычитания, монохромотизации и 2д фильтров, на эрозию, размытие, и статистику.
www.youtube.com/watch?v=kkZLZnUYn9E
Во всех случаях использовал SIMD инструкции — они реально ускоряют в разы, особенно SMLAD и сумма четырёх разниц по абсолюту.
Вывод: CortexM7 а в особенности нормальные варианты от СТМ32 по быстродействию на такт не хуже Малинки третей если не использовать NEON. Я измерял и вышло что примерно одинаковое быстродействие на такт, плюс минус, поиск треугольников содержит хитрый обход дерева заливки и внезапные переходы — RaspPi3 совсем немного отстала (на пару %), но детектор вторжения — там простые операции над массивом — тут чуть чуть (на доли %) RaspPi3 опередила MCU.
44 секунды вышло только потому что код находился в QSPI памяти а она очень медленная.
А ещё лучше QSPI и SDRAM памятью не пользоваться — она всего 100-150мб/сек когда внутренняя доходит до 4200мб/сек.
Пример влияния этих видов памяти:
Я например запускал в таком конфиге MobileNetV2 224х224 на 1000 классов, выходило 30-40секунд.
А когда запустил полностью из DTCM подгружая по необходимости всего один раз нужные куски W и B то скорость возросла почти в десятки раз, речь уже зашла о FPS и сетка заработала в реалтайме (входа, выхода и промежуточные расчёты — 16бит квантизации, а W и B сжаты адуиокодеком до 8 бит с расжатие до 16 бит в DTCM памяти — чтоб быстрее загружалось, загрузка по DMA пока считается текущая свёртка).
Я тоже портировал OpenCV но кусками, вышло в десятки раз быстрее чем оригинальный OpenCV даже на ПК. т.к. я затачивал только под монохром и конкретные задачи (бит хакинг, спец битовые инструкции поиска нуля и все дела, прямо молодость вспомнил как оптимизировал битовые операции для EGA режима 20 лет назад!).
Например вот поиск точек по равнобедренному треугольнику (10мс на кадр 480х240)
аналог ConnectedComponentsWithStats
www.youtube.com/watch?v=210UZUjZwBs
тут опубликовано:
github.com/Mirn/F745_realtime_triangle_recognition
Или вот детектор вторжения просто сравнение с фоном при помощи фильтров (так же около 20 мс на кадр)
аналог вычитания, монохромотизации и 2д фильтров, на эрозию, размытие, и статистику.
www.youtube.com/watch?v=kkZLZnUYn9E
Во всех случаях использовал SIMD инструкции — они реально ускоряют в разы, особенно SMLAD и сумма четырёх разниц по абсолюту.
Вывод: CortexM7 а в особенности нормальные варианты от СТМ32 по быстродействию на такт не хуже Малинки третей если не использовать NEON. Я измерял и вышло что примерно одинаковое быстродействие на такт, плюс минус, поиск треугольников содержит хитрый обход дерева заливки и внезапные переходы — RaspPi3 совсем немного отстала (на пару %), но детектор вторжения — там простые операции над массивом — тут чуть чуть (на доли %) RaspPi3 опередила MCU.
Спасибо автору и вам за не менее интересный комментарий!
Спасибо. Очень интересные результаты. Было бы классно, если бы Вы написали об этом статью, а то в последнее время, как то мало технических статей.
По поводу, медленной памяти, абсолютно согласны. Это очевидное место для ускорения. Мы параллельно работаем над запуском Qt на данной плате, и на данный момент часть кода (обработку прерываний, потоки, системную библиотеку, ..) перенесли во внутреннюю флешь, стало заметно быстрее. Но нам хочется, чтобы именно из коробки запускались данные библиотеки, соотвественно пока уместить их внутрь не получается.
Можете ответить на пару вопросов, по вашим результатам.
Отдельный вопрос, а почему openCV считается стандартом для распознавания, может есть лучшие проекты, и нам лучше с ними поиграться? Мы то сами системщики больше!
По поводу, медленной памяти, абсолютно согласны. Это очевидное место для ускорения. Мы параллельно работаем над запуском Qt на данной плате, и на данный момент часть кода (обработку прерываний, потоки, системную библиотеку, ..) перенесли во внутреннюю флешь, стало заметно быстрее. Но нам хочется, чтобы именно из коробки запускались данные библиотеки, соотвественно пока уместить их внутрь не получается.
Можете ответить на пару вопросов, по вашим результатам.
- Правильно я понимаю, что видео память располагается тоже во внутней sram и использует 16 битный формат. 32 битный у нас просто не влезает во внутреннюю память (320кб) (480х240x4 = 460800)
- Проект на который ссылка это бареметальный проект для stm-ки, а для малинки как измеряли? просто на линуксе скомпилили приложение и запустили? Или тоже бареметальное что то?
Отдельный вопрос, а почему openCV считается стандартом для распознавания, может есть лучшие проекты, и нам лучше с ними поиграться? Мы то сами системщики больше!
Правильно я понимаю, что видео память располагается тоже во внутней sram?
нет, я использовал HALовский пример и дма сохраняла видеопоток в SDRAM (где то 640х480) и из SDRAM уже во внутренюю память я вырезал только нужное окно с пред обработкой уже в виде битового образа (1 бит на пиксель). Даже софтверного быстродействия хватало чтоб разово считать из SDRAM блок памяти. При желании в STM есть 2д видеоускоритель и его можно было бы задействовать например для клипинга и преобразования битов.
Проект на который ссылка это бареметальный проект для stm-ки, а для малинки как измеряли? просто на линуксе скомпилили приложение и запустили?Да просто на люниксе и OpenCV скомпилировал тот же исходник и запустил: от люникса требовался только файловый ввод вывод и замер скорости, а от OpenCV только сырой видео поток с камеры. Аналогично на ПК. Я обычно стараюсь писать сразу хороший код который отлично работает что под ПК что под МК что под FPGA. Спец инструкци же стараюсь применять так чтоб «не вляпаться в ассемблер», т.е. например всё специфически необходимое есть например у GCC в группе функций _buildinXXXX. Моя жизненная позиция — изучить инструмент до конца. И только когда я вообще ничего не нашёл и консультации не помогли только тогда опускаться ниже огородив это западло кучей тестов, доскональной документацией и дебрями условных компиляций чтоб недайбог эта чёрная магия не выстрелила тебе же через лет 10.
а почему openCV считается стандартом для распознавания, может есть лучшие проекты, и нам лучше с ними поиграться?
Извиняюсь но это не в моей компетенции что либо рекомендовать т.к. я не ИТшник вообще, я вообще инженер-схемотехник, у меня оба образования схемотехнические, и ИжГТУ (радиоапаратостроение) и MiT (разработка цифровых микросхем и ASIC). Просто так вышло что интересные проекты и страны требуют научных исследований в области глубокой математики чтоб ускорить видео обработку и нейронок. Я почему то умудряюсь парой строк кода сделать лучше других применив математику по месту понимая смысл. За что и платят.
По поводу, медленной памяти, абсолютно согласны. Это очевидное место для ускорения. Мы параллельно работаем над запуском Qt на данной плате, и на данный момент часть кода (обработку прерываний, потоки, системную библиотеку, ..) перенесли во внутреннюю флешь, стало заметно быстрее. Но нам хочется, чтобы именно из коробки запускались данные библиотеки, соотвественно пока уместить их внутрь не получается.
Ммм… а оно того стоит QT на МК запускать? Я вот подсчитывал бюджет разработки (не только BOM list а себестоимость труда) для разработки на QT для МК граф интерфейсов с нормальным экраном и контролами — вышло почти столько же сколько стоит малинка с экраном но сроки и риски на порядок выше.
Может стоит адаптировать QT на другие стмки, которые хотябы предназначены для этого?
например stm32mp157
STM32MP157 microprocessors are based on the flexible architecture of a Dual Arm® Cortex®-A7 core running at 650 MHz and Cortex®-M4 at 209 MHz combined with a dedicated 3D graphics processing unit (GPU) and MIPI-DSI display interface and a CAN FD interface.
Specifically designed to accelerate 3D graphics in applications such as graphical user interfaces (GUI), menu displays or animations, the STM32MP157 3D OpenGL ES 2.0 graphics engine works together with an optimized software stack design for industry-standard APIs with support for Android™ and Linux® embedded development platforms.
извиняюсь, но мне кажется что вы пытаетесь микроскопом гвоздь забить.
stm32 на базе CortexM7 хороши своей запредельной скоростью арифметики для потоковой обработки видео и звука там где пинг нужен минимальный, например на ДСП процессоре для авто (я писал ранее в своих статьях), или реалтайм обработку видео с задержкой меньше кадра (специально же добавили внутрь CortexM7 заточенные именно для RAW-RGB цветовой интерполяции и поиска оптического потока инструкции).
А менюшами рулить — ну он офигенно справляется если на baremetal написать в лоб
(более того я делал классный плавный интерфейс на 2к озу и 8мгц, если интересно могу скинуть видео), а вот либы обросшие мхом тянуть — это какой то садизм как мне кажется.
Их надо очень сильно урезать и модифицировать на корню — тогда будет толк. А пытаться вытянуть только сборкой, это очень странно. Они слишком гигантские для бедного МК и это факт.
Как другой вариант: сделать динамическую подкачку кода QT в ITCM т.е. как исполнение из EMS памяти под ДОС через оверлеи. Но это ещё тот ниокр.
извиняюсь, но мне кажется что вы пытаетесь микроскопом гвоздь забить.
Возможно. Но речь шла не о проекте, а о памяти. Если OpenCV немного не влазит внутрь быстрой памяти, то Qt точно требует внешней. И хорошо заметно ускорение выполнения кода из внутренней памяти.
Qt это конечно не только менюшки, менюшки можно и по другому рисовать. Это очень мощная платформа программирования. И хочется показать принципиальную возможность использовать подобные библиотеки (Qt, OpenCV, ...) не зависимо от платформы. конечно можно взять и большую платформу чем STM32MP157 поставить Linux, и наслаждаться жизнью, но это будет как минимум дороже и больше потреблять.
Как другой вариант: сделать динамическую подкачку кода QT в ITCM т.е. как исполнение из EMS памяти под ДОС через оверлеи.
Спасибо!
Как другой вариант: сделать динамическую подкачку кода QT в ITCM т.е. как исполнение из EMS памяти под ДОС через оверлеи. Но это ещё тот ниокр
ESP32 поддерживает это на аппаратном уровне. IRAM_ATTR префикс надо ставить, что бы код был постоянно в кэше инструкций (Если я правильно понял архитектуру)
Differences between DTCM and ITCM
ITCM — это все фишки ARM926EJ-S? CortexM4 серия это не поддерживает?
Работающий проект должен вызвать зуд, с желанием проверить в пошаговом режиме — чего там так сильно тормозит…
Sign up to leave a comment.
OpenCV на STM32F7-Discovery