La couche logicielle des Jetson de NVIDIA n'évolue que par petites touches ces derniers mois. Le constructeur a en effet pris du retard sur la prochaine grande version, qui n'arrivera qu'en 2022. Elle abandonnera au passage certains produits, des solutions de secours devant être proposées d'ici là.
NVIDIA propose depuis plusieurs années sa gamme Jetson, des solutions basées sur des SoC avec cœurs CPU ARM et GPU maisons, pensés pour des besoins industriels. Des kits de développement sont régulièrement annoncés, certains étant très accessibles comme les Nano 2 Go lancés en fin d'année dernière, trouvables à 70/80 euros.
La société propose un OS spécifiquement adapté à ces machines : le JetPack SDK. Il est basé sur Ubuntu, intégrant de nombreux outils pour le traitement visuel, vidéo, l'IA, le calcul via CUDA, etc. L'année dernière, la version 4.4 était mise en ligne. La 4.5 était annoncée pour fin 2020 mais n'a finalement été mise en ligne qu'en janvier.
JetPack 4.6 arrive
Nous en sommes désormais à la 4.5.1. NVIDIA a récemment communiqué la suite de ses plans, confirmant qu'elle est en retard puisque « JetPack Next » devait être mis en ligne durant le second trimestre 2021, ce ne sera pas le cas.
JetPack 4.6 doit ainsi être mis en ligne courant juillet apportant « des mises à jour des briques CUDA, cuDNN et TensorRT ». Linux for Tegra (L4T) sera bien entendu mis à jour mais toujours basé sur le vieillissant Ubuntu 18.04 LTS. La société promet également des améliorations pour la mise à jour OTA, la sécurité, le bootloader, le multimédia, etc.
Triton Inference Server sera intégré avec des backends TensorFlow 1.x et 2.x, TensorRT ou PyTorch. Une vesion 4.6.1 mettant à jour cuDNN, TensorRT et VPI (1.2) est attendue d'ici la fin de l'année.
JetPack 5.0 en 2022, mais pas pour les Nano, TX1 et TX2
Cette annonce s'accompagne d'une mauvaise nouvelle : cette branche sera la dernière supportée par les Jetson Nano, Nano 2 Go, TX1, TX2 NX, TX2, TX2 4 Go et TX2i. Elle n'aura ainsi droit qu'à des mises à jour de sécurité et autres corrections de bugs critiques. Cela signifie que ces produits ne passeront jamais à Jetson 5.0 basé sur Ubuntu 20.04.
Face aux contestations sur son forum, NVIDIA dit travailler à une solution pour que les clients puissent accéder à des distributions et versions de noyaux différentes, plus récentes, sur ces produits. On apprécierait en effet qu'un travail soit mené avec des acteurs très actifs dans le domaine de Linux sous ARM comme Ubuntu ou Manjaro pour que leurs distributions soient nativement compatibles avec les Jetson ici abandonnés.
La société promet de produire du code envoyé au noyau Linux de manière croissante pour le support des Jetson, et de travailler avec l'écosystème pour améliorer la situation. De premiers effets de ces efforts sont attendus pour 2022.
Pour rappel Ubuntu 18.04 bénéficiera d'un support jusqu'en 2023.
NVIDIA prépare le terrain pour Orin et Nano Next
JetPack 5.0 se basera donc sur Ubuntu 20.04 et le noyau 5.10, gérant l'UEFI (plutôt que CBoot), OP-TEE et intégrant nativement la version 11 de CUDA. Une préversion est prévue pour la première moitié de 2022, la version stable pour la seconde. Cette nouvelle branche supportera uniquement les Jetson Xavier NX et Jetson AGX à sa sortie.
Elle servira également de base aux deux prochains grands produits de la gamme Jetson : Orin (ARM Hercules et GPU Ampere) ainsi que le prochain Nano sur lequel on ne sait rien pour le moment. Simplement nommé « Next ». Ils sont respectivement attendus pour 2022 et 2023. Les différentes feuilles de route ont été mises à jour en conséquence.
Commentaires (11)
“On apprécierait en effet qu’un travail soit mené avec des acteurs très actifs dans le domaine de Linux sous ARM comme Ubuntu ou Manjaro pour que leurs distributions soient nativement compatibles avec les Jetson ici abandonnés.”
Comme d’habitude avec nvidia, si c’est un problème de pilote proprio qui ne supporte plus ces sock, les distributions ne pourront rien faire de plus…
C’est surtout que tu rentres dans la magie de l’écosystème ARM où il faut adapter pas mal pour chaque SoC/Architecture, du coup l’idée est d’upstream des éléments travaillés pour JetPack. Rien à voir avec d’éventuels pilotes proprio ou non (qui de toutes façons sont très bien gérés par Ubuntu & co).
Tu as mal saisi ce que je veux dire, si bien soit gérés les pilotes nvidia intégrés à ubuntu and co, si nvidia ne supporte plus un gpu, tu n’as plus de pilote proprio donc c’est mort.
Et ça aucune distribution ne peut rien faire.
Toute la question restant donc toujours pareil, si l’arrêt du support signifie l’absence d’un pilote proprio nécessaire ben c’est mort.
Oui et comme dit, ce que tu évoques (les pilotes) n’a rien à voir avec ce dont il est question.
Pour la tablette shield, NVidia mettait à dispo les pilotes, scripts, doc pour recompiler android AOSP. Si bien que certains on passé leur shield en Android 8⁄8.1.
Les Jetson ne font pas partie de ce programme?
Pas les mêmes SoC, et ce n’est pas AOSP, du coup y’a “quelques” trucs à revoir
Même si ce n’est pas directement un pilote, ça revient exactement au même.
Si toute la tambouille que nvidia avait fait pour le portage avait été envoyé en openSource au niveau du kernel, on n’en serait pas là.
Non, comme dit tu mélanges deux problématiques différentes. Je sais que la tentation du “nvidia ça pue c’est pas libre” est toujours forte, mais ici le souci ne vient pas des pilotes.
Sur le fond, NVIDIA a adapté Ubuntu à ses Jetson pour constituer un OS maison exploitable tant par ses clients industriels que les développeurs, ils arrivent au bout d’une phase de développement et indiquent que le support des cartes existantes sera possible dans d’autres distributions via du code qui sera envoyé au noyau. C’est une bonne chose, on jugera sur pièce.
Les sources de L4T sont disponibles, certains l’utilisant déjà à leur sauce. Bien entendu, il aurait été idéal que tout le code soit directement préparé pour être envoyé au noyau (qui supporte déjà des SoC Tegra de mémoire). Où même que des distributions s’en emparent.
On peut toujours tout améliorer faire mieux, plus vite, autrement (surtout quand on a simplement à le dire plutôt qu’à le faire). L’important, c’est que le boulot soit fait et que les utilisateurs y trouvent leur compte. Dans tous les cas, le souci à régler n’a rien à voir avec un pilote ne supportant plus les SoC.
Question, comment peut-on sortir un fork d’OS libre sans être légalement obligé de fournir son code source modifié ?
Il me semble qu’une grosse partie du système linux est sous GPL qui imposent de rendre disponible les composants modifiés ?
Par ex : Free liste toutes les modifications sur des composants opensources pour freebox : https://floss.freebox.fr/freebox_player/1.3.21/index.html ou https://floss.freebox.fr/freebox_player/1.3.21/index.html
Y’a un passe-droit chez Nvidia ou Ubuntu ?
Ce n’est pas un fork d’Ubuntu à proprement parler, c’est un Ubuntu avec des modules spécifiques installés de base pour les calculs sur GPU, (et avec L4T côté noyau, dont les sources sont publiées comme indiqué au-dessus)
OK merci je n’avais pas pigé que c’était un dérivé de Tegra