6 августа 2026 года инженер Qualcomm Првин Кумар Рави предложил сообществу Linux обсудить Synx — глобальный механизм синхронизации для компонентов SoC, работающих под Linux, на удалённых процессорах и в прошивках. Qualcomm уже применяет Synx в нескольких поколениях мобильных и XR-чипов и заявляет о «significant power and performance benefits», хотя публичных цифр и решения о включении кода в mainline пока нет.
Qualcomm хочет связать разные части SoC единым механизмом синхронизации
Современный мобильный процессор давно состоит из множества специализированных блоков. CPU выполняет общий код, GPU рисует графику, видеоблок обрабатывает поток, DSP занимается отдельными вычислениями, а часть задач уходит в прошивки и удалённые процессоры. Эти узлы часто работают с одними и теми же данными и должны точно понимать, когда предыдущий этап завершён.
Именно здесь появляются так называемые fences — маркеры завершения операции. Один блок сообщает, что закончил работу с буфером, после чего другой получает право продолжить цепочку. В Linux такой механизм давно используется, например, через dma_fence для GPU, видео и отображения кадров.
Qualcomm предлагает расширить эту модель на уровень всего SoC. В RFC, отправленном в список рассылки ядра Linux, Synx описан как глобальный слой, который способен координировать зависимости между Linux-клиентами, удалёнными процессорами и firmware.
Для пользователя это звучит почти незаметно: речь идёт о внутреннем механизме ядра. Но именно такие детали определяют, сколько времени аппаратные блоки проводят в ожидании друг друга и насколько эффективно система может укладываться в ограничения по задержке и энергопотреблению.
Synx появился в ядрах Qualcomm задолго до нынешнего RFC
Самая интересная часть новости связана с историей технологии. Synx появился в исходниках Qualcomm ещё в 2019 году. В старом Android-ядре компании сохранился коммит с описанием Global Synchronization Framework, предназначенного для управления зависимостями между гетерогенными вычислительными ядрами.
Тот код уже умел создавать, ожидать, сигнализировать и освобождать объекты Synx. Для них использовались глобальные идентификаторы, а сами объекты могли передаваться между пользовательским и ядерным пространством, между драйверами и firmware, импортироваться, экспортироваться и объединяться.
Исторический коммит Qualcomm в Android kernel показывает, что идея прошла длительный период эксплуатации в vendor-ядрах. В последующих версиях Synx уже опирался на dma_fence, что сближает его с существующей инфраструктурой mainline Linux.
Получается редкая для ядра ситуация: обсуждение начинается вокруг механизма, который много лет жил в закрытом для большинства пользователей контуре конкретного производителя и только теперь претендует на более универсальную роль.
DMA fences уже решают часть задачи внутри Linux
Чтобы понять место Synx, полезно посмотреть на существующую модель. Документация Linux определяет dma_fence как внутренний примитив синхронизации DMA-операций — например, рендеринга на GPU, кодирования видео или вывода буфера на экран.
Когда операция заканчивается, драйвер сигнализирует fence. Ожидающий компонент получает событие и продолжает работу. Через sync_file такой fence можно передать в пользовательское пространство как файловый дескриптор.
Эта схема хорошо подходит для взаимодействия драйверов и процессов, которые уже находятся внутри привычной модели Linux. Synx в предложении Qualcomm охватывает более широкий сценарий: один объект синхронизации должен пройти через границы подсистем и процессоров, включая среды выполнения, которые вообще находятся вне Linux.
| Параметр | dma_fence и sync_file | Synx в RFC Qualcomm |
| Основная область | DMA, GPU, видео, дисплей, обмен fence между драйверами и userspace | Синхронизация на уровне всего SoC |
| Среды выполнения | Ядро Linux и userspace | Linux, удалённые процессоры и firmware |
| Статус | Часть mainline Linux | RFC и обсуждение дизайна |
| Совместимость | Базовый механизм ядра | Предполагает интеграцию с dma_fence и sync_file |
| Привязка к производителю | Общий API Linux | Qualcomm заявляет vendor-agnostic дизайн |
Сам Qualcomm прямо описывает Synx как дополнительный глобальный механизм, который сохраняет существующие примитивы Linux в тех местах, где они уже подходят.
Qualcomm связывает Synx с энергопотреблением и производительностью
В RFC есть сильное заявление: Qualcomm сообщает о заметном выигрыше по энергии и скорости в нескольких последних поколениях мобильных и XR-чипсетов. Именно эта фраза и превращает внутренний инфраструктурный патч в заметную новость.
Цифр пока нет. В опубликованном описании отсутствуют проценты снижения энергопотребления, данные по задержкам, тестовые сценарии и сравнение с текущей mainline-моделью. Поэтому сегодня можно подтвердить сам факт заявленного эффекта, но нельзя оценить его масштаб.
Для мобильных устройств и XR-платформ тема особенно чувствительна к таким изменениям. Камера, GPU, дисплей, видеокодек и блоки компьютерного зрения могут участвовать в одной цепочке обработки кадра. Каждый лишний переход между механизмами ожидания увеличивает сложность координации и влияет на то, как долго отдельные блоки остаются активными.
Qualcomm пока не раскрывает, какая часть заявленного выигрыша связана непосредственно с архитектурой Synx, а какая зависит от конкретной реализации в её SoC. Этот вопрос станет одним из ключевых, если обсуждение перейдёт от общей архитектуры к коду для mainline.
Vendor-agnostic дизайн станет центральной проверкой для Synx
Qualcomm подчёркивает, что Synx задуман как SoC-agnostic framework и потенциально доступен другим производителям. Для ядра Linux это принципиальный момент: общий механизм должен описывать задачу шире одной аппаратной платформы.
Историческая версия Synx была явно связана с Qualcomm. В Kconfig старого Android-ядра она называлась MSM_GLOBAL_SYNX и зависела от ARCH_QCOM. Новая инициатива пытается поднять тот же подход на уровень общей инфраструктуры ядра.
Отсюда возникает несколько технических вопросов, на которые RFC пока не даёт окончательных ответов. Где должна проходить граница между Synx и существующими subsystem-specific API? Как представить удалённый процессор или firmware так, чтобы модель одинаково работала на разных SoC? Какие части старого vendor-драйвера пригодны для общего API, а какие придётся переработать?
Ответы важны и для сопровождающих ядра. Новый глобальный слой синхронизации затрагивает архитектуру взаимодействия драйверов, поэтому обсуждение может оказаться заметно сложнее обычного добавления поддержки конкретного устройства.
У Synx пока нет версии ядра и опубликованных бенчмарков
По состоянию на 7 августа Synx находится на стадии RFC — запроса на обсуждение дизайна. Версия Linux Kernel, в которую код может попасть, не объявлена. Публичной серии патчей с окончательным API и подтверждённого плана принятия в mainline тоже пока нет.
При этом Synx уже имеет длительную историю внутри Qualcomm и реальный код, который использовался в Android-ядрах. Свежая инициатива переносит разговор из vendor-разработки в открытую архитектурную дискуссию Linux Kernel.
Qualcomm планирует использовать Synx в качестве универсального механизма для различных компонентов системы на кристалле. Эта технология уже была применена в мобильных устройствах и платформах для дополненной реальности компании. Однако пока не представлены измеримые результаты, подтверждающие заявленные преимущества в области энергоэффективности и производительности. Дальнейшее развитие проекта будет зависеть от реакции разработчиков ядра и способности Qualcomm продемонстрировать универсальность подхода за пределами своих собственных продуктов.
