해결책
GPU API에는 이식성 속에 숨은 컴파일러 문제가 있었다. 모든 드라이버가 고수준 소스를 파싱해야 한다면 드라이버 복잡성이 커지고, 각 언어마다 각 런타임으로 들어가는 경로가 필요했다. 그 때문에 새로운 프런트 엔드를 정당화하기 어려웠다.
크로노스의 2015년 조치는 중간을 표준화하는 것이었다. SPIR-V 1.0은 그래픽 셰이더와 컴퓨트 커널을 위한 간결한 바이너리 중간 언어를 정의했다. OpenCL 2.1은 이를 소비하도록 보장했고, 불칸은 이를 셰이더 입력으로 채택했다.
영리한 부분은 분리였다. 프런트 엔드는 SPIR-V를 생산하고, 드라이버는 SPIR-V를 소비한다. 크로노스는 이것이 내장 고수준 컴파일러 복잡성을 줄이고, 언어 다양성을 장려하며, 이식성을 개선하고, 컴파일과 리플렉션의 일부를 오프라인에서 수행할 수 있게 했다고 말했다.
이룬 것
드라이버가 소스가 아니라 IR을 소비하게 하라
통한 이유
바이너리 IR은 크로노스가 완전히 명세했으므로, 벤더는 소스 언어를 소유하지 않고도 백 엔드를 최적화할 수 있었다.
불칸과 OpenCL에서 같은 IR을 사용함으로써 도구 제작자들은 그래픽과 컴퓨트를 위한 하나의 타깃을 갖게 되었다.
오프라인 컴파일은 런타임 셰이더 작업을 줄이고 검증, 리플렉션, 도구 사용을 더 쉽게 만들었다.
오픈소스 번역기, 어셈블러, 디스어셈블러는 출시 당시 생태계의 씨앗을 뿌리는 데 도움을 주었다.
표준 중간 형식은 N대 M 컴파일러 문제를 두 개의 더 작은 시장, 즉 다수의 프런트 엔드와 다수의 최적화된 백 엔드로 바꿀 수 있다.
그 후
SPIR-V는 불칸과 OpenCL 툴체인의 핵심 부분이 되었다. 통합 명세는 이제 1.0 이후의 모든 버전을 포괄하며, 크로노스는 여러 그래픽 및 컴퓨트 API 아래의 이식 가능한 바이너리 계층으로서 이를 계속 유지하고 있다.
근거 확인하기
출처
- Khronos Releases OpenCL 2.1 and SPIR-V 1.0 Specifications for Heterogeneous Parallel Programming Khronos Group · khronos.org ·
- SPIR-V Specification Khronos Group · registry.khronos.org