CUDA Toolkit 13.0 para Jetson Thor: Ecossistema Unificado de Arm e Mais

Visão geral

O CUDA Toolkit 13.0 para o Jetson Thor oferece uma cadeia de ferramentas CUDA unificada para plataformas Arm, eliminando a necessidade de manter toolchains separados para dispositivos embarcados e servidores SBSA. Alimentado pela arquitetura de GPU NVIDIA Blackwell, o Jetson Thor ganha memória virtual unificada (UVM) com coerência total, permitindo que a memória pageable do host seja acessada pela GPU através das tabelas de página do host. Essa unificação alinha o comportamento de compartilhamento de memória dos dispositivos Jetson com sistemas dGPU em termos de semântica de memória, reduzindo a carga de gerenciamento entre CPU e GPU. O lançamento visa simplificar o desenvolvimento, simulação, teste e implantação, consolidando toolchains e imagens de contêiner em uma linha de base portátil entre borda e servidor. Uma exceção importante é o Orin (sm_87), que permanece no caminho atual por enquanto. O impacto maior é um fluxo de trabalho de desenvolvimento mais simples: construa uma vez, simule em sistemas de alto desempenho e implante o mesmo binário em alvos embarcados como o Jetson Thor sem alterações no código. A unificação também se estende a contêineres, permitindo uma linha de imagem compartilhada entre simulação e implantação em borda, reduzindo reconstruções, incentivo de CI mais simples e menos inconsistências entre SDKs. O Jetson Thor também passará a suportar uso simultâneo de iGPU e dGPU, oferecendo uma experiência de computação contínua entre núcleos gráficos integrados e dedicados. Além da unificação, o CUDA 13.0 traz várias funcionalidades que melhoram a utilização da GPU, produtividade do desenvolvedor e interoperabilidade. A memória dmabuf baseada em OpenRM é suportada, permitindo compartilhamento de memória entre drivers e pilhas externas sem cópias. Suporte NUMA é introduzido para plataformas Tegra, ajudando workloads com múltiplos soquetes a posicionar a memória mais próxima das CPUs. A Biblioteca de Gerenciamento da NVIDIA (NVML) e a ferramenta nvsm (nvidia-smi) passam a ser suportadas no Jetson Thor, disponibilizando APIs familiares para monitorar o uso da GPU. OpenRM/dmabuf se integra com opções já existentes de compartilhamento de memória em plataformas Tegra, como EGL ou NvSci. O Jetson Thor também ganha capacidades para melhorar workloads multi-processo e em tempo real. O MPS (Multi-Process Service) permite que múltiplos processos compartilhem a GPU de forma concorrente com menor overhead de mudança de contexto, aumentando ocupação e throughput. Contextos verdes fornecem recursos leves pré-atribuídos para isolar recursos da GPU e facilitar a execução determinística. A combinação de MPS, contextos verdes e futuras capacidades MIG (Multi-Instance GPU) habilitam execuções multi-processo mais previsíveis em robótica, SLAM, percepção e planejamento. Em termos de interoperabilidade, o CUDA 13.0 permite importar um dmabuf para memória CUDA e exportar alocações CUDA como fds dmabuf em plataformas OpenRM. A API do Driver expõe cuMemGetHandleForAddressRange() para exportar memória como dmabuf e cuDeviceGetAttribute() com CU_DEVICE_ATTRIBUTE_HOST_ALLOC_DMA_BUF_SUPPORTED para consultar o suporte.

Principais recursos

Toolkit unificado para Arm entre alvos embarcados e servidores SBSA (exceção: Orin).
Memória Virtual Unificada (UVM) com coerência total no Jetson Thor; memória do host acessível pela GPU via tabelas de página do host.
Interoperabilidade OpenRM/dmabuf para compartilhamento de memória com drivers/pilhas externas.
Suporte NUMA para plataformas Tegra, melhorando posicionamento de memória em sistemas com múltiplos soquetes.
MPS para consolidar workloads leves em um único contexto de GPU; facilita adoção sem mudanças em apps.
Contextos verdes para alocação determinística de SMs e execução previsível; compatível com MIG no futuro.
Ferramentas de desenvolvedor aprimoradas: nvidia-smi e NVML no Jetson Thor.
Linha única de imagens de contêiner para simulação e borda, reduzindo recargas e overhead de CI.
Uso concorrente de iGPU/dGPU em plataformas Jetson e IGX.
Compartilhamento de memória via OpenRM/dmabuf (importação/exportação) com CUDA.
Fluxos de compartilhamento de memória com EGL/NvSci como parte da interoperabilidade.
Melhorias de visibilidade de memória com memória pageable mapeada para espaço de endereço da GPU; cudaMallocManaged não é cacheado pela GPU para paridade de coerência.
Binaries MPS: nvidia-cuda-mps-control e nvidia-cuda-mps-server sob /usr/bin; cliente MPS executa com os mesmos diretórios de pipe/log.

Casos de uso comuns

Robótica e IA de borda: executar SLAM, detecção de objetos e planejamento de movimento simultaneamente com requisitos de tempo real.
Aplicações multi-processo que desejam compartilhar a GPU de forma eficiente sem overhead significativo de context switching.
Fluxos de trabalho de simulação para borda: desenvolver e simular em sistemas de alto desempenho (ex.: GB200, DGX Spark) e implantar os mesmos binários em alvos embarcados.
Trabalhos com latência sensível que exigem alocação determinística de SMs e isolamento de recursos via contextos verdes e, futuramente, MIG.
Compartilhamento de memória entre pilhas com OpenRM/dmabuf para integração zero-copy com outros stacks de software (EGL, NvSci).

Instalação e configuração

Observações extraídas diretamente do artigo: há dois binários associados ao MPS (nvidia-cuda-mps-control e nvidia-cuda-mps-server), tipicamente armazenados em /usr/bin. Para iniciar o daemon de controle MPS, siga as etapas descritas no artigo. Para executar um aplicativo como cliente MPS, defina o mesmo diretório de pipe e de logs do daemon e execute o aplicativo normalmente. Os logs ficam em $CUDA_MPS_LOG_DIRECTORY/control.log e $CUDA_MPS_LOG_DIRECTORY/server.log. Para memória compartilhada OpenRM/dmabuf, utilize cuMemGetHandleForAddressRange() e consulte cuDeviceGetAttribute(…, CU_DEVICE_ATTRIBUTE_HOST_ALLOC_DMA_BUF_SUPPORTED).

Configuração do MPS (exemplos de comandos)

# Bins MPS existem em /usr/bin
ls -l /usr/bin/nvidia-cuda-mps-control /usr/bin/nvidia-cuda-mps-server
# Iniciar o daemon de controle MPS (exemplo; as flags exatas podem variar)
nvidia-cuda-mps-control
# Iniciar o servidor MPS (exemplo)
nvidia-cuda-mps-server
# Executar um aplicativo como cliente MPS (exemplo)
export CUDA_MPS_LOG_DIRECTORY=/caminho/para/logs
export CUDA_MPS_PIPE_DIRECTORY=/caminho/para/pipe
./meu_app_cuda
# Logs estarão em $CUDA_MPS_LOG_DIRECTORY/control.log e server.log

Configuração de OpenRM/dmabuf (conceito)

#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);
// Se suportado, utilize cuMemGetHandleForAddressRange() para export/import de memory via dmabuf
return 0;
}

Quick start: exemplo mínimo executável (roteiro mmap)

#include
#include
#include
#include
#include
#include
// Kernel simples de histograma
__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;
}

Prós e contras

Prós
Toolchain único para Arm entre ambientes embarcados e servidores, reduzindo complexidade de CI.
UVM com coerência total facilita o compartilhamento de memória entre CPU e GPU sem cópias explícitas.
MPS diminui overhead de mudanças de contexto para workloads multi-processo, aumentando ocupação e throughput.
Contextos verdes permitem alocação determinística de SMs para workloads sensíveis a latência; MIG vem no futuro para partitions adicionais.
Interoperabilidade OpenRM/dmabuf facilita compartilhamento com stacks externos sem dependência de soluções proprietárias.
Suporte NVML/nvidia-smi no Jetson Thor oferece visibilidade de uso e ferramentas familiares de monitoramento.
Linhagem única de imagens de contêiner simplifica CI e move rapidamente de simulação para borda.
Contras
Orin (sm_87) continua no caminho atual; não há unificação completa para esse SoC ainda.
Algumas capacidades do nvidia-smi, como consulta de clock, energia, thermal, utilização por processo e monitoramento de memória SoC, ainda não estão disponíveis no Jetson Thor.
O caminho OpenRM/dmabuf depende de suporte de plataforma e pilha de software, com maturidade variável entre dispositivos.

Alternativas (breve comparação)

Manter toolchains separados para servidores SBSA e dispositivos embarcados ainda é uma opção, mas aumenta overhead de CI e duplicação de código; CUDA 13.0 busca reduzir essa fragmentação.
Compartilhamento de memória com EGL/NvSci oferece caminhos interoperáveis diferentes; OpenRM/dmabuf adiciona um canal padronizado para compartilhamento de memória entre stacks, complementando EGL/NvSci em plataformas Tegra.
Ambientes sem toolchain unificada podem depender de fluxos de simulação e compilação cruzada; a unificação busca reduzir isso mantendo a portabilidade entre hardware.