La FreeBSD Foundation a publié cette semaine un compte rendu de stage consacré au portage de la pile de calcul ROCm d'AMD depuis Linux vers FreeBSD, et Phoronix l'a relayé le 30 août 2026. Le jalon annoncé paraît modeste : le pilote se lie, se charge et s'exécute, et une simple addition de vecteurs est à portée. Quiconque a déjà déplacé une pile de niveau noyau d'un système à un autre lira cela correctement. Amener un environnement de calcul GPU au point où il peut additionner deux tableaux signifie que la variante LLVM, les environnements d'exécution, le module noyau et la couche de compatibilité en dessous se sont enfin accordés.
The short answer
La FreeBSD Foundation a publié cette semaine un compte rendu sur un stage de l'été 2026 mené par l'étudiant développeur Sourojeet Adhikari, consacré au portage de la pile de calcul ROCm d'AMD vers FreeBSD, que Phoronix a relayé le 30 août 2026. Le pilote se lie, se charge et s'exécute désormais, et le projet approche d'une simple addition de vecteurs, des problèmes restant en espace utilisateur. Y parvenir a demandé des correctifs sur la variante LLVM d'AMD, sur les environnements d'exécution GPU de ROCm, sur le module drm-kmod et sur la couche de compatibilité LinuxKPI, où une incohérence entre structure modifiable et constante dans class_register a provoqué une panique noyau et coûté plusieurs heures. La gestion mémoire hétérogène dans le sous système de mémoire virtuelle de FreeBSD est le prochain chantier. Rien n'est utilisable en production.
L'addition de vecteurs est le bonjour du calcul GPU. L'atteindre depuis un autre système d'exploitation n'est pas un résultat de débutant.
Pourquoi le portage reste dur, même avec une couche de compatibilité
FreeBSD dispose d'un pilote AMDGPU, porté depuis le DRM du noyau Linux, et de LinuxKPI, une couche qui présente les interfaces du noyau Linux au code écrit pour elles. Sur le papier, l'essentiel du problème semble réglé. Il ne l'est pas, et le compte rendu est précieux précisément parce qu'il dit pourquoi.
Une couche de compatibilité doit reproduire les attentes exactes de l'interface, pas seulement son nom et ses arguments. L'exemple donné est une session de débogage de trois à quatre heures qui s'est achevée sur une incohérence entre structure modifiable et structure constante dans le class_register de LinuxKPI. Du code noyau AMD écrit pour un comportement Linux plus récent l'appelait, le qualificatif ne correspondait pas, et la machine a paniqué. Rien dans la signature de la fonction ne le laissait deviner. On le trouve en bissectant une panique.
C'est la texture de ce travail. Le progrès visible est un pilote qui se charge. Le progrès invisible est une liste d'endroits où deux noyaux étaient discrètement en désaccord et où quelqu'un a dû décider lequel corriger.
Quatre couches, toutes à déplacer
Le travail ne s'est pas limité au noyau. AMD maintient une variante de LLVM à travers laquelle ROCm compile, et elle a demandé des correctifs, dont certains sont partis en amont. Les environnements d'exécution GPU de ROCm ont demandé des ajustements. Le module drm-kmod, par lequel FreeBSD porte le pilote graphique noyau, a demandé des modifications. Et LinuxKPI a demandé des correctifs pour les bogues et les différences de comportement révélés par le portage.
Cet étalement explique qu'un portage de pile de calcul prenne plus de temps qu'un portage d'application. Une chaîne de compilation, un environnement d'exécution en espace utilisateur, un module noyau et une couche d'adaptation doivent s'accorder au même moment sur le même matériel, et un écart n'importe où se manifeste comme une panne ailleurs.
Ce qui reste, et pourquoi c'est la partie chère
La gestion mémoire hétérogène est désignée comme le prochain chantier, et c'est le bon endroit pour poser un repère.
HMM est la mécanique noyau qui permet à un GPU et à un processeur de partager un espace d'adressage : un pointeur désigne la même chose des deux côtés, et les pages migrent à la demande au lieu d'être copiées explicitement. Le calcul GPU moderne la présuppose. L'obtenir sur FreeBSD ne relève pas de la traduction d'une interface Linux, car le sous système de mémoire virtuelle de FreeBSD est réellement différent. C'est du travail à l'intérieur de ce sous système.
Le stage est terminé et Sourojeet compte poursuivre. Autant le dire simplement plutôt que de l'habiller : l'état actuel, c'est un développeur, sorti du débogage initial le plus rude, devant la plus grosse pièce restante.
Le point plus large sur les piles de calcul propriétaires
ROCm est libre, et c'est ce qui rend la tentative possible. Elle est aussi vaste, mouvante et écrite pour Linux, et c'est ce qui la rend difficile. AMD a passé l'année à la réorganiser, en sautant directement à ROCm 10.0 avec une pile pour développeurs, et chaque réorganisation en amont ajoute de la surface à rattraper.
Comparez avec la voie que prend une interface graphique. Quand une fonction de fabricant arrive comme extension Vulkan, à l'image du flux optique NVIDIA entré dans FFmpeg ce week end, tout ce qui parle Vulkan en hérite, FreeBSD compris. Une pile de calcul propriétaire prend l'autre voie, et quelqu'un doit la porter à la main.
Ne bâtissez pas un déploiement de calcul FreeBSD là dessus. Lisez le compte rendu si le coût réel d'un portage vous intéresse, car c'est un récit public rare où le débogage n'a pas été effacé.
Sources et pour aller plus loin
- FreeBSD Foundation intern Sourojeet Adhikari on bringing ROCm to FreeBSD, blog de la FreeBSD Foundation, 24 août 2026
- ROCm on FreeBSD, rapport trimestriel FreeBSD, avril à juin 2026
- The Challenges In Bringing AMD ROCm To FreeBSD, Phoronix, 30 août 2026
Questions fréquentes
Dans quel état se trouve réellement ROCm sur FreeBSD ?
Inutilisable pour un utilisateur final, et le compte rendu le dit. La FreeBSD Foundation indique que le projet approche du jalon consistant à exécuter une simple charge d'addition de vecteurs, et que le pilote parvient à se lier, se charger et s'exécuter, des problèmes subsistant en espace utilisateur. Le travail a été mené par l'étudiant développeur Sourojeet Adhikari pendant un stage de la Fondation à l'été 2026. Le stage est terminé, le développeur compte poursuivre, et la gestion mémoire hétérogène est désignée comme le prochain chantier.
Qu'a t il fallu corriger pour arriver là ?
Quatre couches. La variante LLVM maintenue par AMD et utilisée par ROCm, avec certaines modifications reversées en amont. Les environnements d'exécution GPU de ROCm. Le module drm-kmod, par lequel FreeBSD porte le pilote graphique noyau. Et LinuxKPI, la couche de compatibilité qui traduit les interfaces du noyau Linux, où le portage a révélé de vrais bogues et différences de comportement, et pas seulement des fonctions manquantes.
Pourquoi une couche de compatibilité ne suffit elle pas ?
Parce qu'elle doit reproduire non pas la forme d'une interface du noyau Linux mais ses attentes exactes. Le compte rendu décrit une session de débogage de trois à quatre heures qui s'est achevée sur une incohérence entre structure modifiable et structure constante dans le class_register de LinuxKPI, provoquant une panique du noyau quand du code AMD écrit pour un comportement Linux plus récent l'appelait. Un qualificatif const n'est pas une différence sémantique que l'on devine depuis une signature de fonction, et c'est cette classe d'écart qui rend un portage lent.
Qu'est ce que HMM et pourquoi cela compte ici ?
La gestion mémoire hétérogène est la mécanique noyau qui permet à un GPU et à un processeur de partager un espace d'adressage unique, de sorte qu'un pointeur désigne la même chose des deux côtés et que les pages migrent à la demande. Le calcul GPU moderne la présuppose. Les systèmes de gestion mémoire de FreeBSD fonctionnent différemment de ceux de Linux, ce n'est donc pas un travail de traduction mais un travail dans le sous système de mémoire virtuelle de FreeBSD lui même. Il est désigné comme la prochaine exploration, ce qui donne une bonne idée de ce qui reste.
Pourquoi vouloir ROCm sur FreeBSD ?
Pour la même raison que l'on veut quoi que ce soit sur FreeBSD : une licence et un système de base qui conviennent à certains déploiements, et des équipements ou plateformes de stockage qui y vivent déjà et préféreraient ne pas ajouter un hôte Linux pour faire tourner de l'inférence ou du calcul. FreeBSD porte déjà un pilote AMDGPU issu du DRM du noyau Linux, le graphique existe donc. Le calcul était le manque. Personne ne devrait planifier sur cette base aujourd'hui, mais la direction mérite d'être suivie.