SPIR-V conquistou a portabilidade de GPUs ao dividir o compilador em dois

As APIs de GPU tinham um problema de compilador escondido dentro da portabilidade. Se cada driver tivesse que analisar código-fonte de alto nível, a complexidade dos drivers aumentava e cada linguagem precisava de um caminho para cada runtime. Isso tornava difícil justificar novos front ends.

A medida da Khronos em 2015 foi padronizar o meio. O SPIR-V 1.0 definiu uma linguagem intermediária binária compacta para shaders gráficos e kernels de computação. O OpenCL 2.1 garantiu o consumo dela, e o Vulkan a adotou como entrada de shaders.

A parte inteligente foi a divisão: os front ends produzem SPIR-V, os drivers consomem SPIR-V. A Khronos afirmou que isso reduziu a complexidade do compilador de alto nível embutido, incentivou a diversidade de linguagens, melhorou a portabilidade e permitiu que partes da compilação e da reflexão ocorressem offline.

Fazer o driver consumir IR, não código-fonte

A IR binária foi totalmente especificada pela Khronos, então os fornecedores puderam otimizar back ends sem possuir a linguagem de origem.

Usar a mesma IR no Vulkan e no OpenCL deu aos criadores de ferramentas um único alvo para gráficos e computação.

A compilação offline reduziu o trabalho de shaders em tempo de execução e facilitou a validação, a reflexão e o ferramental.

Tradutores, montadores e desmontadores de código aberto ajudaram a semear o ecossistema no lançamento.

Uma forma intermediária padrão pode transformar um problema de compilador N-por-M em dois mercados menores: muitos front ends e muitos back ends otimizados.

O SPIR-V tornou-se parte central das cadeias de ferramentas do Vulkan e do OpenCL. Sua especificação unificada agora cobre todas as versões desde a 1.0, e a Khronos continua a mantê-lo como a camada binária portátil sob múltiplas APIs de gráficos e computação.