CUDA Toolkit 13.0 pour Jetson Thor : Écosystème Arm Unifié et Plus

Aperçu

CUDA Toolkit 13.0 pour Jetson Thor offre une chaîne d’outils CUDA unifiée pour les plates-formes Arm, éliminant le besoin de maintenir des toolchains distincts pour les périphériques embarqués et les serveurs SBSA. Alimenté par l’architecture GPU NVIDIA Blackwell, Jetson Thor bénéficie d’une mémoire virtuelle unifiée (UVM) avec une cohérence totale, permettant à la mémoire pageable du host d’être accessible par le GPU via les tables de pages du host. Cette union aligne les comportements de partage mémoire des dispositifs Jetson avec les systèmes dGPU afin de réduire la charge de gestion entre CPU et GPU. La release vise à simplifier le développement, la simulation, les tests et le déploiement, en consolidant les toolchains et les images contenues dans une lignée portable entre l’edge et le serveur. Une exception importante est Orin (sm_87), qui reste sur le chemin actuel pour l’instant. L’impact global est un flux de travail de développement plus fluide : construire une fois, simuler sur des systèmes haute performance et déployer le même binaire sur des cibles embarquées comme Jetson Thor sans modification du code. L’unification s’étend également aux conteneurs, permettant une lignée d’images partagée entre la simulation et le déploiement en edge, réduisant les reconstructions et le surcoût CI. Jetson Thor peut également exploiter conjointement iGPU et dGPU, offrant une expérience de calcul fluide sur les plateformes Jetson et IGX. Au-delà de l’unification, CUDA 13.0 introduit plusieurs fonctionnalités améliorant l’utilisation du GPU, la productivité du développeur et l’interopérabilité. L’interopérabilité mémoire basée sur OpenRM via dmabuf est prise en charge, permettant un partage mémoire zéro-copie avec les pilotes et piles externes lorsque cela est supporté. Le support NUMA est introduit pour les plateformes Tegra, aidant les workloads Multi-Socket à placer la mémoire plus près des CPU. NVML et la commande nvidia-smi sont désormais supportées sur Jetson Thor, donnant aux développeurs des API et outils familiers pour surveiller l’utilisation du GPU. OpenRM/dmabuf complète les options EGL et NvSci existantes pour le partage mémoire sur les plateformes Tegra. Jetson Thor bénéficie aussi de capacités qui améliorent les charges multi-process et temps réel. Le MPS (Multi-Process Service) permet à plusieurs processus de partager le GPU de manière concurrente avec moins d’overhead de changement de contexte, améliorant l’occupation et le débit. Les contextes verts pré-allocent des ressources GPU pour une exécution déterministe, utile pour des tâches à forte contrainte temporelle. La combinaison MPS, contextes verts et les futures capacités MIG (Multi-Instance GPU) permet d’avoir des exécutions multi-processus plus prévisibles dans la robotique, SLAM, perception et planification. En termes d’interopérabilité, CUDA 13.0 permet d’importer une dmabuf dans la mémoire CUDA et d’exporter des allocations CUDA sous forme de fds dmabuf sur les plateformes OpenRM. L’API du pilote expose cuMemGetHandleForAddressRange() pour exporter, et cuDeviceGetAttribute() avec CU_DEVICE_ATTRIBUTE_HOST_ALLOC_DMA_BUF_SUPPORTED pour vérifier le support.

Principales caractéristiques

Kit d’outils unifié pour Arm entre embarqué et serveurs SBSA (exception: Orin).
Mémoire virtuelle unifiée (UVM) avec cohérence totale sur Jetson Thor ; mémoire hôte accessible par le GPU via les tables de pages de l’hôte.
Interop OpenRM/dmabuf pour le partage mémoire avec des pilotes/piles externes.
Support NUMA pour les plateformes Tegra, améliorant le placement mémoire sur des systèmes multi-sockets.
MPS pour consolider les charges légères dans un seul contexte GPU; adoption sans changement d’application nécessaire.
Contextes verts pour une attribution déterministe des SM et une exécution prévisible; MIG à venir.
Outils de développement améliorés : nvidia-smi et NVML sur Jetson Thor.
Ligne d’images conteneurisée partagée entre simulation et edge, réduisant les reconstructions et les coûts CI.
Utilisation simultanée d’iGPU et de dGPU sur les plateformes Jetson et IGX.
Partage de mémoire via OpenRM/dmabuf (import/export) avec CUDA.
Flux de partage mémoire via EGL/NvSci comme partie de l’interopérabilité.
Améliorations de visibilité mémoire : mémoire pageable mappée dans l’espace d’adresses du GPU; cudaMallocManaged n’est pas mis en cache par le GPU pour la parité de cohérence.
Binaries MPS : nvidia-cuda-mps-control et nvidia-cuda-mps-server sous /usr/bin ; client MPS s’exécute avec les mêmes répertoires de pipe/log.

Cas d’usage courants

Robotique et IA en edge : exécuter SLAM, détection d’objets et planification de mouvement simultanément avec contraintes temps réel.
Applications multi-processus partageant le GPU efficacement sans coûts élevés de changement de contexte.
Flux de travail de simulation vers bord : développer et simuler sur des systèmes haute performance (ex. GB200, DGX Spark) et déployer les mêmes binaires sur des cibles embarquées.
Charges en temps réel nécessitant une allocation déterministe des SM et l’isolement des ressources via des contextes verts et, à l’avenir, MIG.
Partage de mémoire cross-stack avec OpenRM/dmabuf pour une intégration zéro-copie avec d’autres stacks (EGL, NvSci).

Mise en place et installation

Observations tirées directement de l’article : deux binaires associés au MPS (nvidia-cuda-mps-control et nvidia-cuda-mps-server) se trouvent typiquement sous /usr/bin. Pour démarrer le daemon de contrôle MPS, suivez les étapes décrites dans l’article. Pour exécuter une application comme client MPS, définissez le même répertoire pipe et le répertoire de journaux que le daemon, puis exécutez l’application normalement. Les journaux se trouvent dans $CUDA_MPS_LOG_DIRECTORY/control.log et $CUDA_MPS_LOG_DIRECTORY/server.log. Pour le partage dmabuf OpenRM, utilisez cuMemGetHandleForAddressRange() et vérifiez le support via cuDeviceGetAttribute(…, CU_DEVICE_ATTRIBUTE_HOST_ALLOC_DMA_BUF_SUPPORTED).

Mise en place MPS (exemples de commandes)

# Les binaires MPS existent sous /usr/bin
ls -l /usr/bin/nvidia-cuda-mps-control /usr/bin/nvidia-cuda-mps-server
# Démarrer le daemon de contrôle MPS (exemple; options exactes peuvent varier)
nvidia-cuda-mps-control
# Démarrer le serveur MPS (exemple)
nvidia-cuda-mps-server
# Exécuter une application en tant que client MPS (exemple)
export CUDA_MPS_LOG_DIRECTORY=/chemin/LogsMPS
export CUDA_MPS_PIPE_DIRECTORY=/chemin/pipeMPS
./mon_app_cuda
# Logs se trouvent dans le répertoire défini

Démo OpenRM/dmabuf (concepts)

#include
#include
int main() {
CUdevice dev;
cuInit(0);
cuDeviceGet(&dev, 0);
int supported = 0;
cuDeviceGetAttribute(&supported, CU_DEVICE_ATTRIBUTE_HOST_ALLOC_DMA_BUF_SUPPORTED, dev);
printf("HOST_ALLOC_DMA_BUF_SUPPORTED=%d\n", supported);
// Si supporté, utiliser cuMemGetHandleForAddressRange() pour exporter/importer
return 0;
}

Quick start: exemple minimal (mapping avec mmap)

#include
#include
#include
#include
#include
#include
__global__ void hist_kernel(const unsigned char* data, unsigned int* hist, size_t n) {
size_t i = blockIdx.x * blockDim.x + threadIdx.x;
if (i >>(d_data, d_hist, n);
cudaDeviceSynchronize();
for (int i = 0; i < 256; ++i) {
printf("%d: %u\n", i, hist[i]);
}
munmap(data, sz);
munmap(hist, 256 * sizeof(unsigned int));
close(fd);
return 0;
}

Avantages et inconvénients

Avantages
Une chaîne d’outils unique pour Arm entre embarqué et serveur SBSA, réduisant l’overhead CI.
UVM avec cohérence totale facilite le partage mémoire sans copies explicites entre CPU et GPU.
MPS réduit l’overhead de changement de contexte dans les environnements multi-processus et augmente l’occupation et le throughput.
Contextes verts et MIG (à venir) permettent une exécution déterministe et une isolation des ressources.
Interop OpenRM/dmabuf pour le partage mémoire entre piles et pilotes externes.
NVML et nvidia-smi sur Jetson Thor offrent visibilité et outils de surveillance familiers.
Inconvénients
Orin (sm_87) suit encore son chemin actuel; l’unification ne couvre pas encore ce SoC.
Certaines fonctionnalités de nvidia-smi (horloge, énergie, thermique, utilisation par processus, surveillance mémoire SoC) ne sont pas encore disponibles sur Jetson Thor.
L’écosystème dmabuf/OpenRM dépend du support matériel et logiciel, qui peut varier selon la plateforme.

Alternatives (brève comparaison)

Garder des toolchains séparés pour les serveurs SBSA et les dispositifs embarqués reste envisageable, mais augmente l’overhead CI et la duplication.
Le partage mémoire via EGL/NvSci offre des voies d’interopérabilité, mais OpenRM/dmabuf apporte un canal standardisé pour le partage mémoire entre stacks et périphériques externes.
En l’absence d’une chaîne unifiée, on dépendrait de pipelines de simulation et de compilation croisée; l’objectif est de réduire ce coût avec une compatibilité binaire sur le matériel.