시그래프(SIGGRAPH) 2017이 열렸을 때 크로노스 그룹(Khronos Group)의 대표인 Neil Trevett(President, Khronos, Vice President Mobile Ecosystem, NVIDIA)와 인터뷰한 내용을 소개합니다.

 

 

OpenGL 4.6가 출시. 벌칸과 상호 연동 기능을 탑재

 

 

OpenGL은 2017년에 탄생 25주년을 맞이했습니다. 2017년에 크로노스 그룹에게 있어 가장 뜨거운 주제라면 최신 버전의 OpenGL 4.6이 출시됐다는 것입니다. 다만 새로운 쉐이더 지원처럼 큰 확장이 포함되지 않고, 4.5에서 0.1이 늘어난 마이너 체인지입니다. 그래도 주목할만한 점이 3개 있습니다. 

 

첫번째는 OpenGL의 핵심 시스템에 SPIR-V의 통합이 진행됐다는 점입니다. SPIR-V는 크로노스가 총괄하는 다양한 개방형 표준 API 군에서 공통적으로 쓸 수 있도록 추진 중인 중간 언어(미들 랭기지) 스펙입니다.

 

원래 SPIR-V의 원형인 SPIR(Standard Portable Intermediate Representation)은 OpenGL 대신 병렬 컴퓨팅을 위한 API인 OpenCL의 중간 언어로 채택됐습니다. 그 SPIR도 LLVM(Low Level Virtual Machine)이라는 다른 중간 언어 스펙을 바탕으로 만들어진 것입니다. 

 

SPIR는 OpenCL 1.2에서 SPIR 1.2, OpenCL 2.0에서 SPIR 2.0같은 식으로 업데이트를 계속했으나, 2015년에 출시된 OpenCL 2.1이나 그래픽 API인 벌칸에서는 크로노스가 자체 개발한 SPIR-V로 전환했습니다. 

 

이런 방침 전환은 LLVM의 표준화 단체인 LLVM Developer Group과의 정치적 문제를 해결하면서 크로노스가 자유롭게 스펙을 결정할 수 있게 된 덕분이라고 합니다. 2015년을 기점으로 크로노스는 자체 개발한 SPIR-V, OpenCL과 OpenGL, 벌칸 등 크로노스가 책정한 API를 통합하는 방향으로 진행해 나가고 있습니다.

 

바꿔 말하면 OpenGL 4.6은 SPIR-V 완성도가 높아지고, 쉐이더 프로그래밍 환경의 다양성이 보다 향상됐다고 합니다. 크로노스가 새로 공개한 쉐이더 프런트 엔드 컴파일러 Glslang은 OpenGL 기반의 쉐이더 프로그래밍 언어 GLSL과 DirectX 계열 쉐이더 프로그래밍 언어 HLSL을 모두 지원하며, 이런 소스 코드에서 SPIR -V 중간 언어 코드를 출력 할 수 있다고 합니다. 

 

SPIR-V에서 출력하는 중간 언어 코드는 크로노스가 제공하는 새로운 소스코드 생성기인 SPIR-V Cross를 이용, GLSL과 HLSL은 물론 애플이 iOS와 macOS에서 쓰는 셰이더 프로그래밍 언어인 MSL(Metal Shading Language)에 대한 디컴파일을 지원합니다. 

 

 

SPIR-V를 기반으로 하는 개발 환경이 진화하면서 OpenGL 4.6, 쉐이더 프로그램을 다른 API에 이식하기가 더 쉬워 졌다고 할 수 있겠습니다.

 

OpenGL 4.6의 두번째 특징은 OpenGL과 벌칸의 상호 연계를 확장하는 기능을 구현했다는 것입니다. 그럼 여기에서 '원래 OpenGL의 오버헤드 문제를 줄인 것이 벌칸인데, 오버헤드가 큰 OpenGL을 벌칸과 상호 연계하는게 무슨 의미가 있는가?'라고 생각할 수도 있을 것입니다. 당연히 게임 개발에선 이게 별 의미가 없습니다. 

 

 

그러나 벌칸은 응용 프로그램에서 GPU를 조작하는데 특화해 설계했기에, 일반적인 응용 프로그램을 만드는 개발자에겐 개발 난이도가 높습니다. 그래픽 엔진이나 게임 엔진을 맡은 개발자가 아니라면 벌칸을 쓰기 어렵습니다. 여기에 대해서는 크로노스 그룹도 벌칸의 로우레벨 제어가 모든 프로그램에 적합하다고는 생각지 않으며, 드라이버에 부담을 주는 작업이 필요한 소프트웨어도 적지 않게 존재한다고 설명한 바 있습니다.

 

반면 OpenGL은 오버헤드가 크지만 기본적인 그래픽 프로그래밍의 난이도는 벌칸보다 낮습니다. 또 25년이나 되는 긴 역사 동안 방대한 소프트웨어 자산을 쌓아 왔습니다. 그래서 벌칸이 나온 후에도 새로운 OpenGL 자료가 나오고 있습니다. 특히 CAD 소프트웨어나 작업용 그래픽 소프트웨어에선 오랬동안 OpenGL 기반으로 업데이트 해왔기에, 벌칸으로 전환할 필요성이 많지 않습니다.

 

그러나 이러한 애플리케이션에서도 매우 부하가 높거나 실시간 응답성을 높이려는 부분을 벌칸을 이용해 속도를 개선하려는 움직임이 있습니다. 그래서 OpenGL과 벌칸의 상호 연계를 확장하는 것입니다. 

 

 

구체적으로는 OpenGL에서의 실행 결과와 벌칸의 실행 결과를 서로 교환하는 버퍼 공유 기능 위주가 될 것입니다.

 

마지막 세번째는 자잘한 기능의 업데이트이다. 몇가지 예를 들면 쉐이더 컴파일 스레드를 다수 발행, OpenGL 소프트웨어 렌더링 텍스처의 비등방성 필터링(Anisotropic Texture Filtering)을 표준 스펙으로 채택한 것을 꼽을 수 있겠습니다. 

 

이제와서 비등방성 필터링이 표준이라니 실화냐? 라고 생각하셨을 수도 있겠는데 정말입니다. 텍스처의 비등방성 필터링은 PC 게임의 그래픽 설정에서 자주 보이는 옵션이나, 이것은 미국의 Evans & Sutherland가 특허를 낸 기술입니다. 이 회사는 3D 그래픽 관련 기본 특허를 다수 갖고 있으며 NVIDIA도 그런 특허 중 일부를 구입했을 정도입니다. 2016년에 와서야 비등방성 필터링의 특허가 끝나면서 소프트웨어 렌더링에서 이 기능을 구현하게 됐습니다.

 

 

OpenGL 4.6의 업데이트 요소

 

OpenGL 4.6도 지원 드라이버의 발표는 NVIDIA가 빠릅니다. 시그래프 2017이 열리는 동안 지포스/쿼드로 드라이버인 382.96이 출시됐습니다. 베타버전이지만. 그리고 이 글이 올라왔을 당시의 공식 최신 드라이버인 지포스 385.41은 OpenGL 4.5까지만 지원합니다. 

 

 

2017년엔 벌칸 업데이트 없음. 이식 공정을 단축하는 개발이 진행 

 

다음은 벌칸입니다. 벌칸은 기존 API보다 하드웨어에 더 가까운 층에서 GPU를 직접 구동하는 API로 2016년에 정식 출시됐습니다. 크로노스는 Game Debate에서 벌칸과 다이렉트 X 중 어느 쪽이 더 뛰어난 그래픽 API냐는 설문에, 벌칸이 다이렉트 X보다 16배 더 많이 득표했다고 설명했습니다. 출시 1년만에 상당히 좋은 평가를 받고 있는 것이죠.

 

 

현재 게임 엔진과 그래픽 미들웨어에서 벌칸의 채용 사례가 늘어나고 있습니다. 언리얼 엔진 4와 유니티 5가 2016년 중에 벌칸의 지원을 추가했으며, 크라이텍도 올해 7월의 크라이엔진 5.4에서 벌칸을 지원한다고 발표했습니다. 

 

 

또 벌칸은 안드로이드 OS나 닌텐도 스위치 등 주요 플랫폼에서 표준 그래픽 API로도 채용되고 있어, 게임 업계에서의 지위가 갈수록 높아지고 있습니다. 

 

벌칸 1.0이 나온지 겨우 1년이 지났을 뿐이며, 올해엔 벌칸에 새로운 기능을 추가하는 등 구체적인 업데이트는 없습니다. 대신 벌칸을 둘러싼 환경을 개선해 나가는 프로젝트를 크로노스가 진행 중입니다. 구체적으로는 다른 그래픽 API에서 벌칸으로 그래픽 응용 프로그램을 쉽게 이식하도록 해주는 프로젝트를 진행 중이라고 합니다. 

 

현재 게임을 비롯한 그래픽 응용 프로그램은 대상 플랫폼마다 그래픽 API를 구분해서 개발하는 게 기본입니다. 예를 들어 iOS 용 앱은 메탈, 안드로이드 앱은 벌칸, 윈도우/Xbox 응용 프로그램은 다이렉트 X를 사용해 개발하는 식입니다. 이 경우 하나의 응용 프로그램을 여러 플랫폼에 배포하려면 그래픽 프로그램을 각각의 API에 맞춰 이식 작업을 해야 합니다. 

 

 

이 번거로운 공정에 필요한 시간을 어떻게든 줄이기 위해 Vulkan Universally Portable Subset(VUPS)라는 구조를 개발하는 프로젝트가 나왔습니다.

 

벌칸, DirectX 12, 메탈은 등장 배경과 발전 경과는 제각각이지만, 모두 하드웨어에 가까운 로우레벨에서 GPU를 구동하는 API며 기능적으로도 비슷한 부분이 많습니다. 85% 정도가 유사성을 보이니 기능적으로는 큰 차이가 없습니다. 예를 들어 벌칸이라면 vk, DirectX12라면 d3d12를 붙인 비슷한 이름의 API가 많습니다. 좌표의 취급이나 옵션의 지정에선 차이가 있으나, 제공하는 API의 라인업은 상당히 비슷합니다.

 

 

그래서 공통 부분은 VUPS 컨버터가 그 차이를 흡수하고, 이걸로 커버하지 못하는 부분은 VUPS를 위해 준비한 벌칸 확장 API를 사용해 해결하겠다는 것입니다. 또한 쉐이더 언어는 OpenGL 4.6의 SPIR-V를 사용해 대응해 나갈 수 있다고 봅니다.

 

 

OpenCL의 소프트웨어 자산을 벌칸에서 구동하는 솔루션을 개발

 

다음은 병렬 컴퓨팅을 위한 API 인 OpenCL의 미래에 대한 것입니다. OpenCL은 NVIDIA나 AMD의 GPU, 다른 회사의 프로세서에서도 동작하는 병렬 컴퓨팅 플랫폼입니다.

 

 

크로노스는 OpenCL의 최신 버전인 OpenCL 2.2을 2017년 5월에 출시했습니다. OpenCL 2.2은 2015년에 등장한 OpenCL 2.1의 마이너 체인지 버전으로 기본적인 기능에서 달라진 점은 크게 없습니다. 다만 OpenCL 2.1부터 시작된 C++ 언어 지원이 강화돼, OpenCL 2.1의 C ++ 11에서 C ++ 14로 바뀌었습니다. 또 OpenCL 2.1와 마찬가지로 SPIR-V 기반으로 구축됐습니다.

 

 

OpenCL 2.2 이후의 로드맵은 3가지로 나눠 볼 수 있습니다. 첫번째는 C ++의 다음 버전인 C ++ 17의 지원입니다. 마이크로소프트의 병렬 컴퓨팅 기술인 C ++ AMP와 NVIDIA의 CUDA도 C ++ 17을 지원해 나갈 전망이며, 개발자의 부담을 줄여주는 병렬 컴퓨팅 확장형 C ++ 언어 스펙을 업계에서 제대로 수립하는 게 좋다는 분위기가 높아지고 있습니다.

 

그래서 앞으로는 C ++ 언어의 표준 개발을 담당하는 표준화 단체인 ISO(국제 표준화기구)와 IEC(국제 전기 표준 회의) 등과 연계해 스펙을 결정해 나갈 것이라고 합니다. 머신 러닝 AI와 컴퓨터 비전 처리, 이를 기반으로 한 자동 운전 기술 등 병렬 컴퓨팅에 대한 관심이 높아지면서 앞으로 소프퉤어 자산의 사용을 위해선 프로그래밍 언어의 차이에서 비롯된 표준 포맷 경쟁을 멈춰야 한다는 판단인 듯 합니다.

 

두번째는 컴퓨터 비전을 위한 DSP(Digital Signal Processor)와 영상 신호 프로세서(Image Signal Processor, ISP) 머신 러닝 가속기(Tensor Processing Unit, TPU) 등을 위한 OpenCL의 하위 세트를 개발하는 프로젝트의 출범입니다. 현재 OpenCL을 지원하는 각종 프로세서는 최소한 단정밀도 부동 소수점(FP32)을 지원해야 했습니다. 그러나 머신 러닝 AI와 컴퓨터 비전 처리, 자동 운전 기술에 쓰이는 DSP나 IST는 정수, 반정밀도 부동소수점 FP16만으로도 충분합니다.

 

임베디드에서는 불필요한 기능을 배제한 프로세서를 개발하는 일이 자주 있습니다. 그래서 FP32를 생략한 프로세서에서 OpenCL을 지원하고 싶다는 요구가 많았다고 합니다. 여기에 부응하기 위해 OpenCL의 임베디드 일부를 제공하는 것을 검토 중이라고 합니다. 이름은 정해지지 않고 OpenCL for DSP라 부릅니다. OpenGL과 OpenGL ES의 관계와 비슷하니 정식 명칭은 OpenCL ES가 되지 않을까 싶네요.

 

 

OpenCL과 벌칸 로드맵을 나타낸 슬라이드. 아래에 OpenCL for DSP가 있습니다.

 

세번째는 OpenCL을 벌칸 환경에서 작동시키려는 프로젝트입니다. 특수 형상 처리나 프로그래머블 쉐이더에서 수행하기 어려운 포스트 이펙트 처리처럼 색다른 그래픽 처리를 GPGPU적인 방법으로 처리하는건 벌칸의 컴퓨트 쉐이더만으로도 대부분은 처리됩니다. 그럼에도 불구하고 OpenCL을 벌칸 환경에서 쓰는 데엔 큰 이유가 있습니다.

 

구글 안드로이드 플랫폼은 OpenCL 지원을 거부하고 있습니다. 구글은 안드로이드 7.0 이상 표준 그래픽 API인 벌칸을 플랫폼에 통합했습니다. 이것은 벌칸이 그래픽 전용 API이기 때문입니다. 한편 OpenCL은 병렬 컴퓨팅을 위한 플랫폼이며 그 대상도 광범위합니다. 구글은 안드로이드 디바이스에서 OpenCL을 실행하는 데 관심이 없어서인지 운영체제 레벨에서 OpenCL을 지원하려는 움직임이 없습니다.

 

이런 구글도 특정 분야의 OpenCL 소프트웨어 자산은 안드로이드 플랫폼에서 운영하자고 생각하기 시작했다네요. 구글은 어도비 시스템즈가 OpenCL 기반으로 구축한 방대한 이미지 처리 라이브러리를 안드로이드에 도입하려 합니다. 경쟁상대인 애플은 2017년 6월에 발표 한 iOS와 macOS 용 API 메탈 2에서 데이터 병렬 컴퓨팅 처리에 특화된 기능을 갖추고 있어, 구글도 이를 방관하고 있을 수만은 없게 됐습니다.

 

 

컴퓨터 비전 처리는 OpenVX 지원 전용 프로세서에 맡겨야 하지만, 스마트폰 GPU도 GPGPU 처리에 대응하는 경우가 늘어나면서 OpenCL 소프트웨어 자산을 벌칸 환경에서 구현시키려 합니다.

 

 

구글은 OpenCL은 싫지만 벌칸 환경에서 OpenCL 소프트웨어 자산을 이용한다면 된다는 식으로 정책을 바꿨으며, 이에 따라 이번 프로젝트를 시작했다고 합니다. 현재는 벌칸과 OpenCL을 크게 바꾸거나 확장하지 않고, OpenCL 소프트웨어 자산을 벌칸 환경에서 동작하는 코드로 변환하는 크로스 컴파일러 Clspv를 개발해 나간다고 합니다. OpenCL의 Cl과 SPIR-V 약자인 spv을 합친 단어지요. 여기에는 구글과 어도비, 크로스 컴파일러 개발로 잘 알려진 영국 코드플레이가 참여하며, 출시 시기는 아직 미정입니다. 

 

 

glTF는 물리 기반 렌더링 지원. 플래시 지원이 중단되며 WebGL이 보급

 

 

최근 크로노스가 주력하는 새로운 사업에는 OpenGL Transmission Format, 줄여서 glTF라는 크로스 플랫폼 지원 3D 그래픽 리소스(데이터 세트) 체제가 있습니다. 3D 그래픽 관련 데이터를 자유롭게 가져오거나 내보내는 규격이지요.

 

glTF는 3D 모델 데이터뿐만 아니라 움직임(애니메이션)을 포함한 3D 그래픽 장면을 통째로 취급하는 파일 포맷입니다. 구체적으로는 쉐이더나 텍스처 애니메이션(키 프레임), 스키닝 정보 등의 데이터를 포함합니다. WebGL을 이용하면 웹 브라우저에서 3D 그래픽을 작동할 수 있고, 이런 환경에 맞춰서 3D 모델과 텍스처, 모션, 쉐이더 같은 장면을 구성하는 데이터를 하나의 패키지에 포함하는 표준 파일 포맷을 내놓으라는 요청에 따라 탄생한 것이 glTF입니다. 

 

 

glTF 2.0이 취급하는 데이터의 종류

 

첫번째 정식 버전인 glTF 1.0은 2015년에 출시, 2017년 6월에는 glTF 2.0이 등장했습니다. glTF 2.0에서 중요한 포인트는 물리 기반 렌더링(PBR)을 지원할 수 있게 됐다는 것입니다. 유니티 5와 언리얼 엔진 4 등의 주요 게임 엔진은 모든 PBR을 지원하며 스마트폰에서도 지원합니다. 스마트폰 게임에서 PBR이 당연하게 쓰이는 날이 멀지 않았으니 glTF에도 지원하게 될 것입니다.

 

 

PBR은 게임 엔진과 렌더러마다 재질을 해설하는 매개 변수의 종류가 다르나, 이 부분을 최소화하고 현재 쓰이는 것에 대응해 나가도록 포맷을 설계했다고 합니다.

 

 

WebGL 지원 브라우저에서 3D 모델을 볼 수 있는 서비스인 Sketchfab도 일찌감치 glTF 2.0을 지원하고 나섰습니다. 샘플 페이지(https://sketchfab.com/models/b81008d513954189a063ff901f7abfe4 )에서는 PBR 기반 데이터를 돌려가며 볼 수 있습니다. 

 

 

윈도우 10 크리에이터스 업데이트에 설치된 View 3D와 그림판 3D도 glTF 2.0입니다. 또 DCC 툴인 블렌더에서도 지원을 추가하고 나섰습니다. 마이크로소프트는 오피스 시리즈에 glTF 지원을 계획 중이며, 앞으로는 3D 그래픽을 게임 엔진으로 만들고 그 데이터를 파워포인트 프리젠테이션에 통합하는 것도 가능할지 모릅니다.

 

 

glTF과의 연동을 통해 WebGL에 대한 IT 업계의 관심이 높아지고 있습니다. WebGL은 3D 그래픽을 웹 브라우저에서 처리하는 구조로, 실질적으로는 OpenGL ES의 웹 버전이 됩니다. 첫 WebGL 1.0은 OpenGL ES 2.0 수준 기능을 포함해 2011년에 나왔고, 2017년 1월의 최신 WebGL 2.0에선 OpenGL ES 3.0 수준의 기능을 갖췄습니다. 다이렉트 X와 비교하면 OpenGL ES 3.0은 DirectX 10세대에 해당되기에, 웹 브라우저로 PS3, Wii U와 같은 수준의 그래픽 표현을 할 수 있게 된 셈입니다. 

 

 

왜 glTF와 WebGL 2.0이 업계의 관심을 모으고 있냐면 플래시의 종말이 다가오고 있어서입니다. 어도비는 2020년 말에 플래시의 배포와 업데이트를 중단한다고 발표했습니다. 이에 따라 앞으로 인터랙티브하면서도 풍부한 그래픽을 활용한 웹 컨텐츠를 제공하려면 HTML5와 WebGL의 조합 위주가 될 것이며, 웹 애플리케이션 개발에서도 3D 그래픽을 취급할 기회가 늘어날 것입니다. 그래서 glTF이 더욱 중요해지고 있습니다.

 

 

그래서 glTF는 게임 개발과 영상 제작은 물론이고 스마트폰과 임베디드에서 사용도 상정해 스펙을 책정해 나가고 있습니다. PC나 스마트폰에 비해 스펙이 낮은 임베디드에서 이용을 상정하려면 데이터 크기가 중요합니다. 데이터 압축이 더욱 중요해집니다. 크로노스는 구글에서 개발한 3D 모델(다각형 메쉬)와 포인트 클라우드(법선과 색상, 재질 특성 정보를 가진 점의 집합체로 3D 형상을 표현하는 데이터 형식)을 1/30~40 가까이까지 압축할 수 있는 3D 데이터 압축 기술 Draco를 통합하는 계획을 추진 중입니다. 구글은 여기에도 관심이 없지만 특허는 갖고 있습니다. glTF 2.0에 이것이 포함되면 소프트웨어개발자가 무료로 Draco을 이용한 압축과 확장 코드를 소프트웨어에 통합하게 됩니다.

 

 

AMD의 원시 쉐이더는 OpenGL과 벌칸에 도입되는가?

 

그럼 크로노스는 AMD가 베가 세대 GPU에 탑재한 원시 쉐이더에 대해선 어떻게 생각하고 있을까요? 원시 쉐이더는 복잡해진 지금의 지오메트리 파이프라인을 정리한 쉐이더 아키텍처로, AMD가 라데온 RX 베가 시리즈에 탑재했습니다. 다만 이 기능을 사용할 방법을 AMD가 공개하지 않아 여전히 궁금한 점이 많은 상태입니다.

 

 

현재 AMD는 원시 쉐이더에 대한 공식적인 제안을 크로노스에 하지 않았습니다. 따라서 OpenGL과 벌칸에 이를 넣을 예정은 당분간 없다는 거. GPU 제조사가 새로 탑재한 독자적인 기능은 OpenGL의 핵심 기능이 아닌 확장 기능으로 넣는 게 보통인데, 이쪽으로도 아직 진행되지 않았습니다. 그러나 크로노스에는 AMD 직원도 많으니 내년에는 뭔가 진전된 점이 있을수도 있습니다.