Qualcomm a publié le 6 août une demande de commentaires proposant Synx pour le noyau Linux, un cadre de synchronisation qui étend les fences au-delà des parties du système que Linux exécute réellement. Sur un system on chip moderne, le noyau n'est qu'un environnement d'exécution parmi plusieurs, partageant le silicium avec des DSP, des concentrateurs de capteurs, des processeurs d'image et du firmware qui ne font jamais tourner Linux. Synx veut leur donner une façon commune et neutre de s'attendre mutuellement. Il ne remplace pas dma-fence, il se place à côté. Le code tourne déjà en aval sur plusieurs générations d'appareils mobiles et XR de Qualcomm.
The short answer
Synx est un cadre de synchronisation que Qualcomm veut voir intégré au noyau Linux principal. Il coordonne des fences entre les clients hébergés par Linux et des environnements d'exécution qui ne font pas tourner Linux, comme le firmware et les processeurs distants du même system on chip. Il est explicitement conçu pour compléter dma-fence et sync_file plutôt que les remplacer, et il est présenté comme indépendant du SoC. Le code équipe déjà des appareils Qualcomm via les arbres fournisseurs.
Voici l'hypothèse inscrite dans la plupart des primitives de synchronisation du noyau : les deux choses qui s'attendent mutuellement sont toutes deux connues de Linux. Sur un téléphone ou un casque conçu en 2026, cette hypothèse a cessé d'être vraie il y a un moment.
Le trou dans la raquette
Un system on chip moderne est une collection de processeurs qui partagent une puce. Il y a le processeur applicatif qui fait tourner Linux, puis un DSP avec son propre firmware, un concentrateur de capteurs, un processeur de signal d'image, un sous-système de sûreté, parfois un compositeur dédié à l'affichage, chacun avec son environnement d'exécution et sa propre notion du temps.
Des tampons circulent entre eux en permanence. Une image caméra est produite par l'ISP, traitée sur un DSP, composée par autre chose et remise à l'affichage. Seules certaines de ces étapes passent par un pilote Linux, les autres passent par du firmware que le noyau a démarré mais qu'il n'ordonnance pas.
Linux dispose d'excellents outils pour la partie qu'il possède. dma-fence est un objet noyau signifiant « ce tampon sera prêt », sync_file en expose un à l'espace utilisateur comme descripteur de fichier interrogeable, et ensemble ils ont résolu la synchronisation explicite du graphique assez bien pour que la conception tienne une décennie. Ce pour quoi ni l'un ni l'autre n'a été conçu, c'est une fence dont l'autre extrémité vit dans le firmware.
La réponse actuelle passe par de la communication inter-processeurs propriétaire : un mécanisme sur mesure par famille de SoC, implémenté, porté et maintenu séparément, sans rien de partagé. Quiconque a fait vivre un board support package d'une version de noyau à l'autre sait ce que cela coûte.
Ce que propose Synx
La RFC de Qualcomm, publiée le 6 août et menée par Pravin Kumar Ravi, décrit Synx comme un cadre de synchronisation global couvrant différentes parties d'un SoC. L'objectif annoncé est de coordonner des fences entre les clients hébergés par Linux et les environnements d'exécution non Linux, processeurs distants et firmware compris, à travers une interface unique et neutre.
Deux décisions de conception méritent une lecture attentive.
La première est qu'il ne remplace pas dma-fence. La RFC dit explicitement que la synchronisation GPU et affichage existante reste où elle est, et que Synx complète dma-fence et sync_file là où c'est pertinent. C'est la bonne posture pour quelque chose qui demande à être porté par le noyau, et c'est la différence entre un ajout et une réécriture.
La seconde est la revendication d'indépendance vis-à-vis du SoC. Le cadre est présenté comme adoptable par d'autres fournisseurs, non comme un sous-système Qualcomm au nom générique. Savoir si cela tient relève de la revue et non d'un cycle de presse, et c'est la question la plus importante de toute la proposition.
Pas du code neuf, ce qui coupe des deux côtés
Il ne s'agit pas d'une conception esquissée pour la première fois. Un dépôt synx-kernel est publié sur CodeLinaro parmi les projets open source fournisseurs de Qualcomm, et du code de pilote synx figure depuis des années dans les noyaux Android des plateformes Qualcomm, historiquement sous les répertoires de plateforme multimédia. Ce qui est proposé en amont est du code de production avec un historique de livraison.
En sa faveur, c'est une validation réelle. La plupart des RFC pour un nouveau cadre arrivent sous forme d'idée assortie d'un prototype. Celle-ci arrive après avoir tourné entre les mains d'un très grand nombre d'appareils sur plusieurs générations de produits, et Qualcomm indique que l'approche a apporté des bénéfices significatifs en consommation et en performance sur cette période.
Contre elle, du code ayant grandi dans un arbre fournisseur transporte des hypothèses fournisseur, et elles logent d'ordinaire dans les interfaces plutôt que dans l'implémentation. Les concepts qu'un cadre expose tendent à refléter le matériel pour lequel il a été écrit. La revue en amont existe précisément pour les repérer et demander s'ils se généralisent, et une décennie de code fournisseur proposé au noyau principal suggère que la réponse est en général « certains oui ».
Le chiffre qui manque
L'annonce de bénéfice de Qualcomm est qualitative. Des améliorations significatives en consommation et en performance, sur les dernières générations de puces mobiles et XR, sans aucun chiffre joint à la proposition telle que rapportée.
Nous trouvons l'affirmation mécaniquement plausible. Si une fence peut être signalée directement entre deux processeurs de la puce, vous retirez un réveil et un aller-retour par le noyau d'un chemin parcouru potentiellement plusieurs fois par image, et sur un appareil sur batterie supprimer les réveils constitue l'essentiel du travail. C'est un effet réel, et exactement le genre d'effet qui n'apparaît pas dans une mesure de débit.
Plausible n'est pas mesuré. Pour une première RFC c'est acceptable, puisque la question d'ouverture porte sur la justesse de l'abstraction plutôt que sur sa vitesse. Mais un mainteneur à qui l'on demande de porter un nouveau cadre transverse voudra des chiffres avant d'intégrer, et les fournir tôt coûte moins cher que se les faire réclamer en quatrième révision.
Ce qu'il faut surveiller
Si un second fournisseur se manifeste. L'argument le plus fort pour un cadre indépendant du SoC dans le noyau principal est un autre fondeur déclarant qu'il l'utiliserait, et la position la plus faible est d'en être l'unique utilisateur. MediaTek, NXP et Rockchip ont exactement le même problème d'architecture.
Si la discussion converge plutôt vers une extension de dma-fence. C'est la contre-proposition naturelle, et elle n'est pas manifestement fausse. Les relecteurs qui connaissent ce code auront un avis rapidement.
Si le modèle de sûreté résiste au contact. Une fence signalable par du firmware que le noyau n'ordonnance pas est une fence dont le noyau confie à quelqu'un d'autre le soin de rapporter honnêtement l'achèvement, et la RFC devra dire ce qui se passe quand cette confiance est mal placée ou quand le côté distant se bloque simplement.
Si vous maintenez un board support package pour un SoC ARM, cela mérite d'être suivi. Rien n'aboutira rapidement, et les cadres transverses aboutissent rarement à la première révision, mais la direction prise compte davantage que le calendrier.
Sources et pour aller plus loin
- Qualcomm proposes Synx for the Linux kernel with significant power and performance benefits, Phoronix, 6 août 2026
- synx-kernel, projet open source fournisseur Qualcomm sur CodeLinaro
- Buffer sharing and synchronization, documentation dma-buf et dma-fence
- Sync file API guide, documentation du noyau
- Bridging the synchronization gap on Linux, Collabora
Questions fréquentes
Quel problème Synx résout-il que dma-fence ne résout pas ?
La portée. Une dma-fence est un objet noyau : elle vit en mémoire Linux, elle est signalée par du code noyau ou par un pilote pour le compte du matériel, et chaque participant à l'échange est quelque chose que le noyau connaît. Cela fonctionne bien pour le cas visé à l'origine, un GPU qui rend un tampon et un contrôleur d'affichage qui l'attend, tous deux pilotés par des pilotes Linux. Cela fonctionne moins bien quand un côté de l'échange est du firmware sur un DSP démarré par un sous-système de processeur distant, sans pilote Linux pour arbitrer chaque étape. Aujourd'hui ces cas se résolvent par de l'IPC propriétaire, une implémentation par famille de SoC, aucune partagée. Synx propose un cadre unique pour cette classe de transfert, exprimé une fois plutôt que réinventé par fournisseur, et interopérant avec dma-fence et sync_file là où les deux mondes se rencontrent.
S'agit-il de code nouveau, ou de code que Qualcomm livre déjà ?
Il est déjà livré. Un dépôt synx-kernel existe publiquement sur CodeLinaro parmi les projets open source fournisseurs de Qualcomm, et du code de pilote synx est présent depuis des années dans les noyaux Android des plateformes Qualcomm, historiquement dans les répertoires multimédia. Il ne s'agit donc pas d'une conception proposée pour la première fois, mais de code de production issu des arbres fournisseurs, offert en amont. La distinction compte dans les deux sens. En sa faveur, la conception a été éprouvée sur plusieurs générations de matériel commercialisé, ce qui est plus de validation que n'en apporte la plupart des RFC. Contre elle, du code ayant grandi dans l'arbre d'un seul fournisseur porte les hypothèses de ce fournisseur dans ses interfaces, et la revue consacrera l'essentiel de son énergie à cette question précise.
Quels bénéfices sont annoncés, et à quel point sont-ils solides ?
Qualcomm indique que l'approche a apporté des bénéfices significatifs en consommation et en performance sur les dernières générations de ses puces mobiles et XR. L'affirmation est plausible sur le plan mécanique, parce que l'alternative à une fence partagée est en général un aller-retour par le noyau pour réveiller quelque chose, et que sur un appareil sur batterie ces allers-retours sont exactement ce que l'on cherche à supprimer. Elle est aussi, en l'état, non chiffrée. La proposition telle que rapportée ne contient ni mesure de performance, ni mesure de consommation, ni comparaison avant et après. Pour une RFC ce n'est pas rédhibitoire, puisque le premier tour de revue porte sur la justesse de l'abstraction plutôt que sur sa vitesse. Mais les chiffres seront réclamés, et un mainteneur qui doit peser un nouveau cadre transverse voudra raisonnablement les voir avant d'intégrer quoi que ce soit.
Qui serait concerné si cela était intégré ?
Directement, les personnes qui travaillent sur l'intégration SoC : chaînes caméra, compositeurs XR, fusion de capteurs, déport audio, tout contexte où un tampon est produit par un processeur de la puce et consommé par un autre. Indirectement, quiconque maintient un board support package pour un SoC ARM, puisque l'alternative actuelle est une tuyauterie de synchronisation par fournisseur qu'il faut porter et maintenir séparément. Le point intéressant est la présentation comme cadre indépendant du SoC. Si MediaTek, NXP, Rockchip ou un autre acteur à l'architecture comparable l'adopte, le gain est une abstraction unique entre fournisseurs plutôt qu'un cadre fournisseur de plus dans l'arbre. Si personne d'autre ne l'adopte, le dossier pour le porter dans le noyau devient beaucoup plus faible, et les relecteurs le diront.
Que devient une RFC de ce type ensuite ?
En général une longue conversation. Une RFC publiée sur les listes du noyau est une demande d'orientation plutôt qu'une candidature à l'intégration, et une proposition qui traverse les frontières de sous-systèmes exige l'accord de plus d'un mainteneur. Les points de discussion probables sont prévisibles : faut-il un nouveau cadre ou une extension de l'infrastructure dma-fence et sync_file existante, l'interface exposée à l'espace utilisateur est-elle assez stable pour devenir un engagement d'ABI, comment fonctionne le modèle de sûreté quand une fence peut être signalée par du firmware que le noyau ne contrôle pas, et un second fournisseur est-il intéressé. Attendez plusieurs révisions sur des mois plutôt que des semaines. Les cadres noyau qui touchent plusieurs sous-systèmes aboutissent rarement du premier coup, et ceux qui y parviennent sont en général arrivés avec un comainteneur d'une autre entreprise.