CUDA Toolkit 13.0 para Jetson Thor: Ecosistema Unificado de Arm y Más

Descripción general

CUDA Toolkit 13.0 para Jetson Thor ofrece una cadena de herramientas CUDA unificada para plataformas Arm, eliminando la necesidad de mantener toolchains separados para dispositivos embebidos y servidores SBSA. Potenciado por la arquitectura de GPU NVIDIA Blackwell, Jetson Thor obtiene Memoria Virtual Unificada (UVM) con coherencia total, permitiendo que la memoria pageable del host sea accesible por la GPU a través de las tablas de páginas del host. Esta unificación alinea las plataformas Jetson con sistemas dGPU en términos de semántica de memoria y reduce la carga de gestión entre CPU y GPU. El lanzamiento apunta a simplificar el desarrollo, la simulación, las pruebas y el despliegue consolidando toolchains e imágenes de contenedor en una sola línea de verdad portable entre borde y servidor. Una excepción relevante es Orin (sm_87), que seguirá en su camino actual por ahora. El impacto general es un flujo de trabajo de desarrollo más fluido: compilar una vez, simular en sistemas de alto rendimiento y desplegar el mismo binario en dispositivos embebidos como Jetson Thor sin cambios en el código. La unificación también se extiende a contenedores, permitiendo una línea de imagen compartida entre simulación y despliegue en borde, reduciendo reconstrucciones y costos de CI. Jetson Thor también ofrece uso simultáneo de iGPU y dGPU en plataformas Jetson e IGX para una experiencia de cómputo unificada. Además de la unificación, CUDA 13.0 introduce varias características que mejoran la utilización de la GPU, la productividad del desarrollador y la interoperabilidad. El acceso a memoria OpenRM/dmabuf permite compartir memoria entre controladores y pilas externas cuando se admite. El soporte NUMA se introduce para plataformas Tegra, ayudando a que las cargas multinodo coloquen la memoria más cerca de las CPUs. NVIDIA Management Library (NVML) y la utilidad nvidia-smi ahora son compatibles en Jetson Thor, proporcionando API y herramientas familiares para monitorear el uso de la GPU. OpenRM/dmabuf complementa opciones existentes como EGL y NvSci para compartir memoria en plataformas Tegra. Jetson Thor también aporta capacidades para mejorar cargas de trabajo multi-proceso y en tiempo real. MPS (Multi-Process Service) permite que múltiples procesos compartan la GPU concurrentemente con menos sobrecarga de cambio de contexto, mejorando la ocupación y el rendimiento. Los contextos verdes preasignan recursos de la GPU para garantizar una ejecución determinista, útil en tareas con restricciones de tiempo. La combinación de MPS, contextos verdes y MIG (Multi-Instance GPU) en el futuro permite ejecuciones multi-proceso más predecibles en robótica, SLAM, percepción y planificación. En términos de interoperabilidad, CUDA 13.0 permite importar un dmabuf en la memoria CUDA y exportar asignaciones CUDA como descriptores dmabuf en plataformas OpenRM. La API del driver expone cuMemGetHandleForAddressRange() para exportar, y cuDeviceGetAttribute() con CU_DEVICE_ATTRIBUTE_HOST_ALLOC_DMA_BUF_SUPPORTED para consultar el soporte.

Principales características

Toolkit unificado para Arm entre embebido y servidores SBSA (excepción: Orin).
Memoria Virtual Unificada (UVM) con coherencia total en Jetson Thor; memoria host accesible por la GPU mediante tablas de páginas del host.
Interoperabilidad OpenRM/dmabuf para compartir memoria con drivers y pilas externas.
Soporte NUMA para plataformas Tegra, mejorando la colocación de memoria en sistemas multi-socket.
MPS para consolidar cargas livianas en un único contexto de GPU; adopción sin cambios en la aplicación.
Contextos verdes para asignación determinística de SMs y ejecución predecible; MIG vendrá en el futuro.
Herramientas de desarrollo mejoradas: nvidia-smi y NVML en Jetson Thor.
Línea de imágenes de contenedor compartida entre simulación y borde para reducir reconstrucciones y costos de CI.
Uso concurrente de iGPU y dGPU en plataformas Jetson e IGX.
Compartición de memoria mediante OpenRM/dmabuf (importación/exportación) con CUDA.
Flujo de compartición de memoria con EGL/NvSci como parte de la interoperabilidad.
Mejoras de visibilidad de memoria: memoria pageable mapeada en el espacio de direcciones de la GPU; cudaMallocManaged no está en caché por la GPU para la paridad de coherencia.
Binaries MPS: nvidia-cuda-mps-control y nvidia-cuda-mps-server bajo /usr/bin; cliente MPS se ejecuta con los mismos directorios de pipe/log.

Casos de uso comunes

Robótica e IA en borde: ejecutar SLAM, detección de objetos y planificación de movimiento simultáneamente con requisitos de tiempo real.
Aplicaciones multi-proceso que comparten la GPU de manera eficiente sin grandes costos de cambio de contexto.
Flujos de trabajo de simulación-bound edge: desarrollar y simular en sistemas de alto rendimiento (p. ej., GB200, DGX Spark) y desplegar los mismos binarios en targets embebidos.
Cargas en tiempo real con garantías deterministas mediante asignación de SMs y aislamiento de recursos con contextos verdes y MIG en el futuro.
Compartición de memoria entre pilas usando OpenRM/dmabuf para integración cero-copia con otros stacks (EGL, NvSci).

Instalación y configuración

Notas tomadas directamente del artículo: hay dos binarios asociados a MPS (nvidia-cuda-mps-control y nvidia-cuda-mps-server), típicamente almacenados en /usr/bin. Para iniciar el daemon de control MPS, siga los pasos descritos en el artículo. Para ejecutar una aplicación como cliente MPS, configure el mismo directorio de pipe y de logs que el daemon y ejecute la aplicación normalmente. Los registros se almacenan en $CUDA_MPS_LOG_DIRECTORY/control.log y $CUDA_MPS_LOG_DIRECTORY/server.log. Para compartir memoria OpenRM/dmabuf, utilice cuMemGetHandleForAddressRange() y verifique el soporte con cuDeviceGetAttribute(…, CU_DEVICE_ATTRIBUTE_HOST_ALLOC_DMA_BUF_SUPPORTED).

Configuración MPS (ejemplos de comandos)

# Los binarios MPS están en /usr/bin
ls -l /usr/bin/nvidia-cuda-mps-control /usr/bin/nvidia-cuda-mps-server
# Iniciar el daemon de control MPS (ejemplo; las opciones exactas pueden variar)
nvidia-cuda-mps-control
# Iniciar el servidor MPS (ejemplo)
nvidia-cuda-mps-server
# Ejecutar una aplicación como cliente MPS (ejemplo)
export CUDA_MPS_LOG_DIRECTORY=/ruta/a/logs
export CUDA_MPS_PIPE_DIRECTORY=/ruta/a/pipe
./mi_app_cuda
# Registros en el directorio de logs

Interoperabilidad OpenRM/dmabuf (conceptos)

#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 soportado, usar cuMemGetHandleForAddressRange() para exportar/importar memoria dmabuf
return 0;
}

Quick start: ejemplo mínimo (mapeo con 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
Chaîne d’outils unifiée pour Arm entre embarqué et serveurs SBSA, réduisant le coût CI.
UVM avec cohérence totale permet le partage mémoire sans copies explicites entre CPU et GPU.
MPS réduit l’overhead des processus multiples et améliore l’occupation et le débit.
Contextes verts et MIG (à venir) offrent une exécution déterministe et une isolation des ressources.
OpenRM/dmabuf offre une interopérabilité mémoire cross-stack pour intégrations externes.
NVML et nvidia-smi sur Jetson Thor apportent des outils de surveillance familiers.
Inconvénients
Orin (sm_87) n’est pas encore couvert par l’unification.
Certaines fonctionnalités de nvidia-smi (horloge, puissance, thermique, utilisation par processus) ne sont pas encore disponibles sur Jetson Thor.
Le chemin OpenRM/dmabuf dépend du matériel et du logiciel, avec des niveaux de maturité variables.

Alternatives (brève comparaison)

Conserver des toolchains séparés pour serveurs SBSA et embarqué est possible, mais augmente l’overhead CI et la duplication.
Le partage mémoire via EGL/NvSci propose des chemins d’interopérabilité différents; OpenRM/dmabuf propose un canal standardisé pour le partage mémoire entre couches et périphériques.
En l’absence d’une chaîne unifiée, on dépendrait de flux de travail de simulation et de compilation croisée; l’objectif est de réduire ce coût en assurant une compatibilité binaire sur le matériel.