Le portage ROCm sur FreeBSD approchait une addition vectorielle dans l’entretien publié le 24 août par la Fondation. Un pilote qui se lie et se charge marque un progrès réel, sans établir une pile d’apprentissage automatique complète et prise en charge.
Lire les étapes dans l’ordre
L’entretien de la Fondation décrit le travail de Sourojeet Adhikari sur le fork LLVM d’AMD, les runtimes ROCm, drm-kmod et LinuxKPI. Il reste des problèmes en espace utilisateur, et l’addition vectorielle est un objectif proche. Le rapport trimestriel détaille un état antérieur des composants et leurs branches ; l’entretien plus récent ne prouve pas que tous les éléments restants soient terminés.
Le schéma sépare compilation, runtime hôte, interface noyau et exécution GPU. Un compilateur qui accepte le programme valide une frontière différente du runtime qui le soumet ou du GPU qui renvoie un résultat correct.
L’intérêt d’un calcul minuscule
Un exemple simple prend A = [1, 2, 3] et B = [10, 20, 30], avec C = [11, 22, 33] attendu. C’est une illustration arithmétique, pas une sortie obtenue avec le portage FreeBSD.
Un test réel devrait allouer les tampons, rendre les entrées accessibles au GPU, soumettre le travail, attendre la fin et comparer les valeurs renvoyées. Une exécution sans contrôle du résultat manque une étape essentielle. Après ce premier cas, varier les tailles et répéter allocation puis libération permettrait de rechercher des défauts de durée de vie ou de synchronisation. Une addition réussie ne certifierait toujours pas tout un framework, une famille de GPU ou une charge de production.
La compatibilité porte aussi sur le comportement
L’exemple class_register concerne du code attendant une structure const face à une implémentation de compatibilité qui l’attendait encore modifiable. Notre ancienne phrase affirmant que rien dans la signature ne pouvait révéler le problème était trop absolue : const fait partie du contrat d’interface. Un nom de fonction identique ne suffit pas si les arguments sont traités différemment.
HMM constitue un travail mémoire supplémentaire
La documentation HMM du noyau décrit les mécanismes de miroir d’espaces d’adressage et de migration entre RAM et mémoire de périphérique. Elle n’affirme pas qu’une addition avec copies explicites exige toutes les fonctions HMM, ni que HMM rend seul tous les pointeurs GPU utilisables partout.
Pour suivre l’adoption, distinguez construction de la chaîne d’outils, exactitude du runtime, matériel supporté, comportement mémoire et compatibilité des frameworks. Les branches de développement se testent sur des systèmes de laboratoire récupérables. Nous n’avons pas exécuté ce portage ; les sources ne permettent pas de le recommander comme installation prête pour les utilisateurs.
Sources
- Entretien de la Fondation FreeBSD du 24 août
- Rapport trimestriel ROCm
- Documentation de conception HMM
Entretien de la Fondation et rapport trimestriel vérifiés ; addition vectorielle conservée comme objectif, interface const précisée et calcul simple distingué du support HMM.