로우레벨 그래픽 API의 등장

OpenGL 등의 API을 책정하는 Khronos Group는 미국 샌프란시스코에서 열린 GDC(Game Developers Conference)에 맞춰 새로운 그래픽 API 벌칸(Vulkan)을 발표했습니다. 마이크로소프트의 다이렉트 X 12, AMD의 맨틀, 애플의 메탈과 같은 로우레벨 API입니다.

다른 신형 API와 마찬가지로 기존 그래픽 API의 복잡한 점을 없애고 GPU 하드웨어에 직접 접근할 수 있는 API며, 현존하는 쉐이더 GPU와 멀티코어 CPU의 성능을 최대한 끌어낼 수 있습니다. 드로우 콜을 대폭 줄여 오버헤드를 극적으로 낮춰 그래픽 성능을 높일 수 있습니다. 이러한 특징은 다른 로우레벨 API와 같습니다.

다른 로우레벨 API처럼 그래픽 API를 보다 슬림하게 만들어 줍니다.

Khronos는 2014년 여름에 벌칸의 계획을 Next Generation OpenGL Initiative(glNext)로 발표했습니다. Khronos의 API 제정은 원래 시간이 오래 걸렸지만 이번에는 이례적으로 빨랐습니다. 이는 그래픽 업계의 로우레벨 API 흐름에 신속하게 대응하기 위함입니다.

벌칸이란 이름은 AMD 맨틀을 떠올리게 합니다. 실제로 벌칸의 책정에는 AMD가 많은 힘을 썼다고도 합니다. 그러나 맨틀과 벌칸은 같은 것이 아닙니다. 드라이버 계층 구조나 메모리 액세스에 분명한 차이가 존재하며 Khronos의 독자적인 성격이 강한 API입니다. 드라이버 레벨은 새로 미들 랭귀지를 만들어 그래픽을 담당하는 벌칸과 컴퓨팅을 맡은 OpenCL 같은 컴파일러를 프론트 엔드에 흡수할 수 있습니다.

벌칸에는 AMD가 많은 공을 들였습니다.

이런 구조에서 벌칸의 야심찬 구상을 볼 수 있습니다. 벌칸은 그래픽 API를 로우레벨로 처음부터 다시 만드는 것일 뿐만 아니라, 그래픽과 컴퓨트를 모두 통합하는 소프트웨어층의 구축을 목표로 합니다. 나중에 설명할 LLVM의 발상을 도입했다는 게 벌칸의 특징입니다.

맨틀에 이어 벌칸은 게임 엔진 개발사의 지원을 받고 있습니다. 밸브는 자사의 게임 엔진인 소스 2가 벌칸을 지원하도록 만들어, 자신의 게임 클라이언트 머신인 스팀 머신에서 사용할 계획입니다. 벌칸의 워크 그룹을 보면 게임 엔진 개발사의 이름을 볼 수 있습니다.

OpenGL이 벌칸을 정식으로 발표하면서 맨틀에서 시작된 로우레벨 그래픽 API로의 변화는 마침내 종착역이 보이게 됐습니다. 시장 구도를 보면 다이렉트 X 12와 벌칸의 두 크로스 플랫폼 그래픽 API 계열이 대처할 것처럼 보이는데요. 이번에는 상황이 약간 다릅니다. 벌칸의 위치에는 다소 불분명한 점이 있습니다.

아직 알 수 없는 애플과 구글의 움직임

작년 GDC에서 다이렉트 X 12를 발표했을 때는 AMD, NVIDIA, 인텔, 퀄컴을 비롯한 GPU 하드웨어 개발사가 함께 모습을 보였습니다. 그러나 이번의 벌칸 발표에선 밸브 소프트웨어를 비롯한 게임엔진 개발사 위주였습니다. Khronos의 세미나에선 하드웨어 제조사도 있어 AMD 외에도 NVIDIA와 Imagination Technologies, ARM 등이 등장했습니다. 인텔과 퀄컴도 벌칸 워킹 그룹에 포함돼 있으니 지원은 할 것으로 보입니다. 그러나 다이렉트 X 12 시절처럼 PC 그래픽 제조사가 모두 벌칸을 앞세우던 분위기는 아닙니다. 다이렉트 X 12와의 차이를 느낄 수 있는 부분입니다.

벌칸의 중요한 특징은 OpenGL 뿐만 아니라 OpenGL ES가 커버하는 모바일이나 임베디드 영역까지도 커버한다는 것입니다. 실제로 모바일 계열 GPU인 PowerVR의 Imagination Technologies와 Mali의 ARM은 벌칸을 강조하고 있습니다. 자사의 기술 세션에서도 벌칸을 언급하였지요.

로우레벨 그래픽 API는 맨틀이 등장한 시점에서 게임용 PC의 성능 향상만 강조했습니다. 그러나 마이크로소프트는 다이렉트 X 12로 모바일 윈도우 폰 계열까지 커버할 것이라 밝혔으며, 애플은 모바일 iOS에서 로우레벨 API인 메탈을 채용했습니다. 현재 로우레벨 API의 흐름은 고성능 PC부터 모바일/임베디드까지를 모두 커버합니다.

모바일 디바이스에서 API의 오버헤드는 소비 전력을 의미합니다. 로우레벨 API가 성능을 높일 수 있다면, 성능을 유지했을 때 소비 전력을 낮출 수 있다는 이야기입니다. CPU와 GPU의 효율을 높이는 로우레벨 API는 사실 배터리 구동 시간이 문제가 되는 모바일 디바이스에도 최적입니다. 그러나 벌칸은 모바일 시장에서 애플과 구글의 움직임을 신경쓰지 않을 수가 없습니다.

ARM의 벌칸 프레젠테이션

벌칸 워킹 그룹의 목록. 애플도 있네요.

우선 애플은 iOS의 로우레벨 그래픽 API로 메탈을 추진합니다. 애플은 벌칸의 워킹 그룹에 이름을 올렸으나 메탈과 벌칸을 어떻게 할 것인지는 명확하지 않습니다. 구글은 벌칸의 워킹 그룹에 이름을 올리지도 않았습니다.

벌칸의 이상적인 미래는 OpenGL 계열과 OpenGL ES 계열을 통합한 공통의 로우레벨 그래픽 API로 자리잡아 PC와 모바일을 모두 커버하는 것입니다. 그러나 모바일의 양강 구도를 구축한 애플과 구글이 벌칸을 어떻게 대응할지를 아직 알 수 없는 상황입니다. 안드로이드는 칩 제조사 차원에서 지원할 순 있어도 표준이 될 지는 모릅니다.

벌칸은 PC부터 임베디드까지 폭넓은 애플리케이션을 지원합니다.

벌칸에 맞춰 새로운 미들 랭귀지인 SPIR-V를 도입

Khronos는 벌칸에 맞춰 새로운 미들 랭귀지인 SPIR-V도 발표했습니다. Khronos는 원래 LLVM(Low Level Virtual Machine) 컴파일러 인프라를 지원하는 SPIR(Standard Portable Intermediate Representation)를 OpenCL에 채용해 왔습니다. 그러나 이번에 Khronos가 책정한 SPIR-V는 LLVM에서직접 지원하지 않으며 Khronos의 컴파일러층 전용 중간 표현이 됩니다.

 

 

 

 

SPIR-V는 GPU에서 실행되는 프로그램 언어를 컴파일하는 런타임 스택의 프론트 엔드가 되는 미들 랭귀지입니다. 쉐이더 언어 소스는 SPIR-V로 변환돼 벌칸의 컴파일러층에 넘어갑니다. 그리고 SPIR-V의 컴파일은 오프라인에서 이루어지며 벌칸 런타임은 쉐이더 소스 코드를 컴파일하지 않습니다.

 

 

 

 

 

예전 버전의 SPIR를 사용하는 현재의 OpenCL은 오픈 컴파일러 인프라 스트럭처인 LLVM을 사용합니다. LLVM에서는 프론트 엔드를 통해 각종 프로그래밍 언어를 지원하며 백엔드가 다양한 하드웨어를 지원합니다. 컴파일러는 스택으로 나뉘어 고급 컴파일러가 SPIR을 비롯한 상위 미들 랭귀지에서 하위 미들 랭귀지로 변환됩니다. 파이널라이저 컴파일러가 로우레벨의 미들 랭귀지를 하드웨어의 네이티브 랭귀지로 컴파일합니다. HSA(Heterogeneous System Architecture)의 경우 이 로우레벨 미들랭귀지가  GPU의 가상 ISA(Instruction Set Architecture)인 HSAIL이 됩니다.

 

 

 

현재 OpenCL과 HSA 컴파일러 스택

 

LLVM이 두 흐름으로 나뉜 구조를 쓰는 이유는 확장성과 이식성 때문입니다. 프런트 엔드를 확장함으로써 다양한 프로그래밍 언어에 대응할 수 있습니다. 백엔드를 확장하면 다양한 하드웨어에 대응할 수 있습니다.

 

기존의 OpenCL은 LLVM 인프라 스트럭처에 SPIR 1.2/2.0을 도입하는 구조였으나, 이번 Khronos의 발표를 보면 벌칸과 OpenCL이 모두 SPIR-V에서 Khronos의 컴파일러 스택에 적용되는 형태입니다.  SPIR-V는 예전처럼 바이트 코드가 아닌 바이너리의 미들 랭귀지가 됩니다.

벌칸의 컴파일 스택이 LLVM과 비슷한 구조로 되는지는 아직 모릅니다. 그러나 Khronos의 그동안 움직임을 감안하면 LLVM과 비슷한 구조로 되어 있을 가능성이 높습니다. 그렇다면 Khronos는 LLVM을 떠나면서 LLVM적인 컴파일러 인프라 스트럭처를 독자적으로 만들려는 움직임을 하는 것입니다. 한 업계 관계자는 "큰 목소리를 내는 일부 멤버의 영향이 강한 LLVM과 거리를 두면서 Khronos에 있어서 최적인 언어 스펙을 만드려는 것"이라고 말합니다. 그렇지만 Khronos는 SPIR-V와 LLVM사이의 변환 도구도 오픈 소스로 한다고 발표하기에, 거리를 두면서도 LLVM의 장점을 어느 정도 쓸 수 있도록 할 것입니다.