SPIR-V se impuso en la portabilidad de GPU al dividir el compilador en dos

Las API de GPU tenían un problema de compilador oculto dentro de la portabilidad. Si cada controlador tenía que analizar código fuente de alto nivel, aumentaba la complejidad del controlador y cada lenguaje necesitaba una ruta hacia cada entorno de ejecución. Eso hacía difícil justificar nuevos front ends.

El movimiento de Khronos en 2015 fue estandarizar el nivel intermedio. SPIR-V 1.0 definió un lenguaje intermedio binario compacto para sombreadores gráficos y kernels de cómputo. OpenCL 2.1 garantizó su consumo, y Vulkan lo adoptó como su entrada de sombreadores.

La parte ingeniosa fue la división: los front ends producen SPIR-V, los controladores consumen SPIR-V. Khronos afirmó que esto reducía la complejidad del compilador de alto nivel integrado, fomentaba la diversidad de lenguajes, mejoraba la portabilidad y permitía que partes de la compilación y la reflexión ocurrieran fuera de línea.

Hacer que el controlador consuma IR, no código fuente

El IR binario estaba completamente especificado por Khronos, de modo que los proveedores podían optimizar los back ends sin ser dueños del lenguaje fuente.

Usar el mismo IR en Vulkan y OpenCL dio a los creadores de herramientas un único objetivo para gráficos y cómputo.

La compilación fuera de línea redujo el trabajo de sombreadores en tiempo de ejecución y facilitó la validación, la reflexión y las herramientas.

Los traductores, ensambladores y desensambladores de código abierto ayudaron a sembrar el ecosistema en el lanzamiento.

Una forma intermedia estándar puede convertir un problema de compilador de N por M en dos mercados más pequeños: muchos front ends y muchos back ends optimizados.

SPIR-V se convirtió en una parte central de las cadenas de herramientas de Vulkan y OpenCL. Su especificación unificada ahora cubre todas las versiones desde la 1.0, y Khronos sigue manteniéndolo como la capa binaria portátil bajo múltiples API de gráficos y cómputo.