La semana pasada se liberó AMD ROCm 7.14 como el primer lanzamiento de producción construido sobre TheRock, y ya hay más por delante para el stack ROCm de AMD. En particular, el soporte de SPIR-V en ROCm se está volviendo una realidad, lo que abre la puerta a binarios unificados que funcionan a través de distintas arquitecturas de GPU, mejor portabilidad entre hardware y otras mejoras al apuntar a una representación intermedia común.

¿Qué es SPIR-V y por qué importa en ROCm?

SPIR-V es la representación intermedia que se asocia típicamente a los controladores de la API Vulkan, pero que también soportan otras APIs de Khronos como OpenGL y OpenCL. AMD ROCm ha venido trabajando hacia un modelo para soportar el IR de SPIR-V, con el fin de reducir la necesidad de compilar objetivos específicos por cada GPU y permitir una experiencia más unificada.

El costo de este enfoque es una mayor latencia de JIT en el primer arranque, cuando se produce la primera invocación de un kernel para un dispositivo o objetivo de GPU dado, además de la necesidad de sortear el código con partes específicas de arquitectura en tiempo de compilación.

Este camino de SPIR-V con ROCm lleva tiempo gestándose, como parte también de su apuesta por MLIR. El tema se ha cubierto muchas veces en el pasado, con esta tendencia asomando de forma clara en los últimos años.

¿Qué funciona hoy y qué falta?

AMD publicó una entrada de blog que detalla el nivel actual de soporte de SPIR-V en ROCm y lo que viene. ROCm 7.2 y versiones posteriores ya cuentan con soporte base, con funcionalidades como el objetivo AMD GCN SPIR-V en LLVM y Clang, la ruta del SPIRV-LLVM Translator con grado de producción hoy, y el caché de JIT por proceso.

Lo que aún queda por delante:

  • Lograr que el back-end de SPIR-V de LLVM en el árbol principal reemplace al traductor como la ruta de conversión por defecto.
  • La compilación JIT en el momento de instalar el paquete.
  • Mejorar la experiencia de depuración en la ruta JIT de SPIR-V para AMDGCN.
  • Resolver las compilaciones de SPIR-V para las bibliotecas de dispositivo por arquitectura.

El panorama a futuro es prometedor: un único binario de AMD ROCm que "simplemente funcione" en muchas GPUs, un tiempo de compilación y un tamaño de binario planos, compatibilidad hacia adelante "gratis", buen rendimiento y amplia cobertura de bibliotecas. Este stack de SPIR-V sobre ROCm ya está dando resultados como prueba de concepto exitosa para PyTorch.

El trasfondo de todo esto es la vieja batalla contra el bloqueo por proveedor: mientras Nvidia consolidó su dominio con CUDA, AMD apuesta a que la portabilidad, sostenida en estándares abiertos de Khronos, sea su argumento diferenciador. Es probable que se conozcan más detalles esta semana en el evento Advancing AI de AMD, en California.