Перейти до основного вмісту

Процесорні модулі

Система на кристалі Modalix містить декілька процесорів, кожен з яких призначений для виконання різних етапів конвеєра обробки даних. Планувальник фреймворку Neat вибирає один (або ланцюжок) процесор для кожного етапу, виходячи з функцій, які виконує цей етап. На цій сторінці описано кожен з процесорів і те, де він використовується в типовому конвеєрі.

A65 — основний модуль застосунку.​

Стандартні ядра ARM A65, на яких працює Linux. Основний процес фреймворку, весь код застосунків і більшість неапаратних прискорених елементів GStreamer виконуються тут.

Використовується для:

  • Цикл подій Graph / Run.
  • Файл / RTSP / мережевий ввід-вивід.
  • Діагностичні тести та код для застосування на стороні, з якої здійснюється відкривання.
  • Легкий клей для використання між прискореними етапами.

EV74 / CVU — обчислювальний блок для обробки зображень.​

Це DSP-процесор, оптимізований для векторних обчислень. У фреймворку він місцями називається EV74, а місцями – CVU (обчисний блок обробки зображень). Використовується для обчислювальних ядер, які мають SIMD-структуру, але недостатньо великі, щоб вимагати використання MLA (множення-додавання). Застосовується для попередньої обробки (зміна розміру, перетворення кольору, нормалізація), обчислювальних ядер для обробки меж (розбиття на частини/об’єднання частин, квантування/декватування), об’єднаної попередньої обробки (універсальна попередня обробка) та постобробки BoxDecode.

Робота EV74 виконується за допомогою окремих потоків CVU для кожної стадії. Бінарні файли ядер є частиною архіву моделі (lib/).

MLA — прискорювач машинного навчання.​

Modalix MLA. Зібрані ваги моделі та граф зберігаються тут. Передача даних здійснюється через потік MLA, який отримує на вхід дані, розділені на фрагменти, з EV74 (або безпосередньо з етапу квантування) і генерує вихідні дані, також розділені на фрагменти, для подальшої дефрагментації.

Робота з MLA має два варіанти:

  • Висновок на основі моделі MLA — основний граф моделі.
  • Підготовка MLA / об’єднані операції — попередні/післяопераційні ядра, скомпільовані в MLA, якщо це дозволено контрактом (стовпець «MLA tess» у тип даних, контракт).

MLASHM — спільна пам’ять MLA.​

Спеціалізований регіон пам’яті, який модуль MLA може зчитувати з найменшою затримкою. Буфери, призначені для вхідних даних модуля MLA, за можливості виділяються з сегментів MLASHM. Планувальник забезпечує, щоб попереднє оброблення даних на стороні EV74 здійснювалося безпосередньо в MLASHM, щоб модуль MLA міг використовувати їх без передавання.

APU — блок обробки аудіосигналу.​

Використовується в аудіоканалі та на деяких етапах попередньої обробки, де застосування SIMD до скалярних даних дає переваги. Аудіокомпоненти (наприклад, для зміни частоти дискретизації, кодеки) в рамках цієї системи розраховані на роботу з APU.

TVM — резервний варіант, скомпільований за допомогою TVM.​

Для операцій, які компілятор MLA не може згенерувати, фреймворк може використовувати ядра ЦП, скомпільовані за допомогою TVM. Це відображається в плані маршрутизації як етап, орієнтований на TVM. Це повільніше, ніж виконання за допомогою MLA, але гарантує обробку, коли контракт MPK описує операцію, яку бекенд MLA не підтримує.

M4 — основний координатор​

Невеликий процесор Cortex-M4 використовується для низькорівневої координації — протокол RPMsg між A65 та прискорювачами, сторожовий таймер, апаратна послідовність. Код застосунку ніколи не виконується безпосередньо на M4; фреймворк взаємодіє з ним через рівень операційної системи.

Як планувальник робить вибір.​

Під час створення графа, модуль планування маршруту проходить кожний етап і ставить таке запитання:

  1. Який процесор може використовувати це ядро? — Обчислення MLA виконуються на MLA; попередня обробка — на EV74; операції введення/виведення — на A65.
  2. Який найдешевший спосіб дістатися туди? — мінімізуйте кількість пересадок (планувальник додає пересадку ConversionKind::Transfer лише тоді, коли це неминуче).
  3. Чи можуть сусідні етапи використовувати спільні сегменти? — модель пам’яті визначає, що можливо; планувальник використовує цю модель.

Результатом є RouteGraph, де кожен етап містить цільовий процесор і політику сегментації. Ви можете переглянути це за допомогою Graph::describe().

Для подальшого ознайомлення​

  • «Процесорні модулі» — §21 і §22 розділу, присвяченого детальному аналізу проєкту.
  • «Каталог ядер CVU та графів» — див. Ядра CVU..
  • «Модель пам’яті» — див. модель пам’яті.
  • Graph::describe() — вивести план маршруту.