다이렉트 X 11을 넘어선 Khronos의 OpenGL 4.2

기글 하드웨어 뉴스 리포트 - 다이렉트 X 11을 넘어선 Khronos의 OpenGL 4.2  http://gigglehd.com/zbxe/6341966

 

Khronos에 속하는 멤버를 나타낸 슬라이드

 

 

Khronos이 스펙 책정에 참여하는 오픈 스탠다드 API

Khronos 그룹은 임베디드 디바이스용의 오픈 스탠다드 API 워킹 그룹으로 2000년에 발족한 단체입니다. 활동 초기에는 임베디드용 OpenGL ES의 스펙 책정에 주력하였지만 2006년부터 OpenGL의 규격 책정을 담당하는 OpenGL ARB(Architecture Review Board)와 통합하게 되었습니다. 그 결과 Khronos는 크로스 플랫홈을 지원하는 오픈 스탠다드 API의 규격화 단체 중에서 제일 큰 곳이 되었습니다.

그런 Khronos는 최근 Game Developers Conference(GDC)와 SIGGRAPH 기간 중에 큰 발표를 하는 것이 관습처럼 되었습니다. 저번 SIGGRAPH 2011에서도 몇개 중요한 발표가 이루어졌으며, 여기서는 그 내용을 보도록 하겠습니다.

 

다이렉트 X 11을 크게 능가하는 OpenGL 4.2

SIGGRAPH 2011에서 Khronos의 제일 큰 화제는 3D 그래픽을 위한 오픈 스탠다드 API인 OpenGL 4.2의 발표입니다.

 

 

Khronos의 대표인 Neil Trevett. NVIDIA Mobile Content의 부사장이기도 합니다.

Khronos의 대표이며 NVIDIA의 모바일 컨텐츠 부문 부사장인 Neil Trevett는 이번 OpenGL 4.2의 발표를 'OpenGL의 역사에서 오래간만에 다이렉트 X를 추월했다고 말하는 사람도 있다'고 평가했습니다.

 

 

2010년부터 OpenGL은 급격히 발전하여 다이렉트 X를 추격하고 있습니다.

그렇다면 왜 'OpenGL 4.2가 다이렉트 X 11을 앞질렀다'라고 말하는 것일까요.

2009년에 윈도우즈 7이 출시된 이후 다이렉트 X 11이 그리 큰 업데이트를 하지 않았는데 비해, 다이렉트 X 11보다 5개월 늦게 발표된 OpenGL 4.0은 다이렉트 X 11과 동일한 기능을 갖췄다고 설명하며, 이후에 SIGGRAPH 2010에서 OpenGL 4.1, 그리고 이번에 OpenGL 4.2까지 순조롭게 버전업이 진행되고 기능도 추가되고 있기 때문이라는 것이 그 이유입니다.

여전히 다이렉트 X 11에 머물러 있는 다이렉트 X와 비교하여, 윈도우즈와 거리를 두고 있는 개발자가 '추월했다'라고 표현하려는 것도 무리는 아닌 것으로 보입니다.

그럼 OpenGL 4.2가 어떻게 다이렉트 X 11을 추월했다는 것인지 기능적인 부분에서 보도록 하겠습니다.

 

 

Image_load_Store and Atomic Counters

일반적으로 픽셀 쉐이더-OpenGL에서는 Fragment Shader라고 부르지만 일반적으로는 픽셀 쉐이더가 더 대중적인 표현이기 때문에 여기서는 픽셀 쉐이더라고 표기-에서는 단일 버퍼밖에 사용할 수 없습니다. 또한 텍스처를 읽어낼 수는 있어도 한번 썼던 버퍼를 다시 읽을 수는 없습니다.

OpenGL 4.2에서는 Image_load_Store를 제공하여 임의의 2D 텍스처 배열에 대해 픽셀 쉐이더가 읽고 쓰기를 할 수 있는 기능을 제공하고 있습니다.

지금까지는 Multiple Render Target을 사용하여 다이렉트 X 10 이후부터 최대 8개의 버퍼까지 동시에 쓰기가 가능했습니다. 하지만 OpenGL 4.2에서는 메모리 용량이 허락하는 범위 내에서 몇개까지 쓰기가 가능한 데다가 읽기도 가능하게 되었습니다.

 

 

그래픽 파이프라인에 컴퓨트 쉐이더 확장성을 주었다고 할 수 있는 매우 강력한 기능 확장입니다.

Image_load_Store와 같이 소개된 Atomic Counters는 Atomic Operation에 대응되는 카운터 조작을 실시하는 기능으로, 이 카운터 조작에서는 덧셈과 뺄셈이 가능하며 여러 카운터를 버퍼에 저장할 수도 있습니다.

사실 이런 기능은 NVIDIA의 페르미 아키텍처에서 확장 기능으로 내장된 것으로, 실제로 이를 사용한 Order Independent Transparency 대응 렌더링 파이프라인이 고안되기도 했습니다.

샘플 프로그램도 공개되고 있으니 관심 있으신 분은 한번 보시길: http:///blog.icare3d.org/2010/06/fast-and-accurate-single-pass-buffer.html

 

Transform Feedback Instanced Example

다이렉트 X 11(OpenGL 4.x) 세대의 GPU에서는 Tessellation Stage가 준비되어 있습니다. 간단하게 설명하면 적은 폴리곤 모델을 프로그래머블로 자동 분할하여 폴리곤 수를 늘리거나 Displacement Mapping을 통해 디테일을 추가하는 것입니다. 하지만 여기에는 1가지 큰 문제가 있습니다.

그 문제란 똑같은 폴리곤 분할과 똑같은 Displacement Mapping이 중복 실행되어, 테셀레이션 스테이지의 의미가 없고 부하가 높아진다는 것입니다.

예를들어 1초에 60프레임을 리프레시하는 게임에서, 캐릭터 시점에서 10m 떨어진 곳에 100개의 다각형이 있는 모델을 배치한다고 가정합시다. 이를 테셀레이션 스테이지를 활용하여 10배인 1000개의 다각형으로 만들어 낸다고 칩시다.

그러면 그 다음 프레임을 1/60초 후에 그려야 하지만, 캐릭터가 3cm 전진하면 9.7m 떨어진 곳에 다시 100개의 다각형으로 이루어진 모델을 배치해야 합니다. 이 경우 테셀레이션 스테이지가 이 모델을 1000개로 분할해야 하는데, 그 결과는 앞서 그렸던 것과는 다르지만 사실상은 거의 비슷합니다.

즉, 2 프레임 사이에 거의 비슷한 분할을 2번 반복하게 되는 것입니다.

 

 

테셀레이션 스테이지를 활용했을때 그래픽 성능이 떨어지는 문제를 줄여줄 수 있는 신기능입니다

이렇게 불필요해 보이는 작업을 해소하기 위해 도입된 것이 Transform Feedback Instanced Example 입니다. 이것은 테셀레이션 스테이지에 의해 분할/변형된 3D 모델을 그대로 캡처하여 재사용할 수 있다는 것입니다.

아까 설명했던 예를 들어보자면, Transform Feedback Instanced Example 기능은은 시점으로부터 거리가 바뀔 때마다 테셀레이션을 다시 해야하지만, 거기까지 거리가 변하지 않을 경우에는 바로 이전의 테셀레이션 결과를 테셀레이션 스테이지로 재사용하는 최적화 처리를 넣을 수 있게 됩니다.

또한 테셀레이션 스테이지에 의한 처리 결과를 복사하여, 개별의 인스턴스를 주어 각각 다른 자세나 렌더링을 할 수 있게 됩니다. 그 때문에 테셀레이션 스테이지를 사용하여 같은 모델의 캐릭터를 다시 만들어낼때 극적인 최적화 효과가 가능하게 됩니다.

 

 

Compressed Pixel Texture Storage

 

 

위쪽과 중간에 기록된 것이 기존의 방법. 아래쪽에 있는 것이 Compressed Pixel Texture Storage를 사용한 텍스처 부분 갱신 방법입니다.

Compressed Pixel Texture Storage는 압축된 텍스처의 부분 갱신에 관련된 기능 확장입니다.

프로그래머블 쉐이더가 도입된 이후에 텍스처는 다각형에 붙이는 그래픽 텍스처 뿐만 아니라 시뮬레이션의 결과 같은 통용 수치 데이터를 저장하는 데에도 사용하고 있습니다.

예를 들어서 물결의 높낮이 정보를 데이터화한 압축 데이터가 있고, 이를 기초로 GPU가 물결을 그려낸다고 칩시다. 여기서 플레이어가 수면에 총알을 발사하면 GPU는 총알과 수면의 인터렉션-interaction-을 처리해야 합니다.

지금까지면 수면의 텍스처를 한번 처리한 다음 GPU에 넘겨주던가, 혹은 CPU와 GPU가 공유할 수 있는 메모리 스페이스에 갱신하려 하는 텍스처 블럭을 복사하는 형태로 처리하였기 때문에 처리가 복잡했습니다.

그러나 Compressed Pixel Texture Storage를 사용하면 직접 GPU의 로컬 메모리에 저장된 텍스처를 임의대로 수정이 가능합니다. 따라서 지금까지 했던 불필요한 작업을 생략하고 텍스처의 부분 갱신을 할 수 있는 것입니다.

 

 

Map Buffer Alignment

CPU는 캐시 시스템이나 메모리 시스템의 구조 때문에 16바이트, 64바이트, 128바이트 같은 특정 단위가 아니면 최대 성능을 내지 못하는 경우가 있습니다.

Map Buffer Alignment는 데이터 주소를 컨트롤하는 기능으로서 CPU의 SIMD 명령 셋트인 SSE나 AVX를 효율적으로 사용할 수 있게 해주며, CPU와 GPU가 같은 데이터를 사용하는 애플리케이션에서 효과를 발휘할 수 있습니다.

 

Conservative depth

Conservative depth는 픽셀 쉐이더를 사용하는 Z 버퍼 렌더링을 실행할때 유효한 확장 기능입니다. 원래는 AMD GPU 전용 확장 기능이었지만 이번에 표준 스펙이 되었습니다.

 

Shading Language Packing

Shading Language Packing에 의해 벡터형 변수와 정수형 변수를 서로 패킹하거나 형태를 변환할 수 있게 되었습니다.

 

 

웹 브라우저로 플러그인 없이 3D 그래픽을 그려내는 WebGL

 

 

WebGL은 HTML5에 포함된 웹 플랫홈의 3D 그래픽 API입니다.

 

 

WebGL의 소프트웨어 계층 다이어그램

Khronos는 OpenGL에만 신경을 쓰고 있는 것이 아닙니다. 최근 주력하는 분야는 웹 브라우저에서 프로그래머블 쉐이더 세대의 3D 그래픽을 실시간으로 실행하는 오픈 규격인 WebGL이 있습니다.

지금까지 웹 브라우저에서 3D 그래픽이라고 하면 별도의 플러그인 소프트웨어를 도입하여 실현하는 것이었습니다. 따라서 아무나 제약 없이 볼 수 있어야 한다는 웹 컨텐츠와는 거리가 멀었습니다. 애플의 iOS가 플래시를 지원하지 않으려는 이유도 이걸 내세우고 있습니다.

그 점에서 WebGL은 HTML5 규격의 일부에 포함되기 때문에 플러그인 없이 웹브라우저에서 3D 그래픽을 사용할 수 있습니다. 좀 더 구체적으로 설명하면 OpenGL ES 2.0 수준의 3D 그ㅏ래픽을 자바스크립트로 실행하는 것입니다.

WebGL의 3D 그래픽은 인터랙티브 컨텐츠로 구성할 수 있으며 플러그인 소프트웨어에 구애받지 않는다는 특징이 있습니다. 동영상, 정지화면, 3D 그래픽을 자유롭게 합성하여 이를 CSS와 웹페이지에 자유롭게 표시할 수 있는 것입니다.

즉, HTML5와 WebGL, 그리고 자바스크립트의 편성은 일종의 소프트웨어 플랫홈이 될 수 있으며, 이를 가능성 높은 게임용 오픈 플랫홈으로 보고 있는 게임 개발사가 상당수 있습니다.

WebGL 1.0은 GDC 2011에서 정식 발표되었고, SIGGRAPH 2011에서 몇개의 업데이트가 보고되었습니다.  WebGL 1.0은 Typed Array 변수나 동작 검증이 추가된 것이 특징이며, 버그 수정판인 WebGL 1.0.1이 5월에 규격을 책정하기 시작했습니다.

 

 

WebGL의 API를 사용하려면 3D 그래픽 관련 지식이 필요합니다. 따라서 서드파티를 통해 WevGL을 간단하게 사용하기 위한 미들웨어 개발이 진행되고 있습니다. 최근에는 기능의 확충과 동작의 안정성 강화가 진행되면서 WebGL 기반의 미들웨어 개발 프로젝트가 시작되었습니다.

WebGL은 Web 버전의 OpenGL ES지만 웹 프로그래머의 상당수가 아직 3D 그래픽에 익숙하지 않기 때문에 3D 그래픽을 HTML5에서 간단하게 사용할 수 있는 엔진의 구축이 시작된 것으로 보입니다. 본격적인 보급까지는 아직 시간이 걸리겠지만 머지않아 HTML5와 WebGL에서 동작하는 게임 엔진도 나올 것입니다.

그 외에도 Khronos는 WebGL의 보안 문제를 찾아내는 데에도 주력하고 있습니다.

예를 들어 무한 루프의 쉐이더를 실행하여 그 사이에 화면을 캡처하여 인터넷으로 전송하는 스파이웨어형 바이러스가 기술적으로 가능한지, 이를 어떻게 검출하는지, 그리고 처리가 가능하는지를 조사중입니다.

하지만 이것은 WebGL만의 문제가 아니고 웹 브라우저나 HTML5의 스펙에도 깊이 관련된 부분이기 때문에 관련 부서와 상호 제휴하여 진행중이라고 합니다.

 

 

현재는 파이어폭스, 사파리, 크롬이 WebGL을 기본 지원하는 브라우저입니다.

 

 

Khronos는 WebGL의 보안 문제도 연구중입니다.

 

 

보다 현실적인 WebCL

GDC 2011에서 Khronos는 HTML5에 추가되는 새로운 API로 WebCL의 존재를 분명히 발표했지만, 이번의 SIGGRAPH에서는 WebCL에 관련된 업데이트를 발표하고 있습니다.

WebCL은 간단히 말해서 HTML 버전의 OpenCL입니다. .HTML5 버전의 OpenGL ES라고 할 수 있으며 WebGL과 비슷한 위치 설정이라 할 수도 있을 것입니다. OpenCL은 데이터 병렬 컴퓨팅을 하기 위한 프로그램 언어, 혹은 체제로 사용되고 있지만 웹 페이지에서도 이것을 이용 가능하게 하려는 것이 WebCL이라는 것입니다. 덧붙여서 CL은 Computing Language의 줄임말입니다.

WebGL 뿐만 아니라 HTML5에서 WebCL을 사용하게 된 것은 '3D 그래픽과 물리 시뮬레이션을 구사한 웹 페이지를 동작할 수 있다'는 이야기가 됩니다. 혹은 동영상 편집이나 필터 처리 기능이 있는 리터칭 소프트웨어가 HTML5만으로 실행하는 것이 가능하다는 말이기도 합니다. 그게 가능한 것인지 의문을 가진 사람들도 적지 않겠지만 WebCL에 주력하는 노키아와 삼성의 동영상을 보면 그것이 터무니없는 이야기가 아님을 알 수 있을 것입니다.

노키아는 WebCL의 전용 사이트를 마련하여 WebCL을 마련한 사진 리터칭 웹툴을 공개하고 있습니다.

 

 

이 인터렉티브 데모를 사용하려면 파이어폭스 5 이후 이 사이트에서 공개중인 프로토타입 WebCL의 설치가 필요합니다.

이 사이트에서는 실제로 작동하는 WebCL을 사용한 인터렉티브 데모의 체험 페이지도 공개하고 있습니다. 이 데모는 WebCL이나 그래픽 처리를 실행했을 경우와 자바 스크립트를 실행했을 경우를 비교할 수 있어, 사용자가 자신의 PC에서 WebCL의 성능을 체감할 수 있게 되어 있습니다.

삼성도 1024개의 파티클을 사용하는 N-BODY 시뮬레이션 데모나 사진에 물방울을 흘린것처럼 보이는 효과 처리를 프로토타입 WebCL을 사용했을 경우와 자바스크립트를 사용했을 때를 비교하여 성능을 비교하고 있습니다.

이런 데모를 보면 웹 페이지에서 본격적인 게임이나 실용 어플리케이션이 등장하는 것도 꿈같은 이야기는 아니라는 것을 알 수 있을 것입니다.

 

 

WebCL은 OpenCL의 웹버전에 해당합니다.

 

 

현재 공개된 WebCL 관련 리소스.

Khronos는 WebCL의 시작을 위해 2011년부터 워킹 그룹을 발족하고 있었으며, 여기서는 Khronos의 Trevett이 그룹 내부에서 논의중인 '현 시점에서의 WebCL 방향성과 규격 책정'에 대해 설명해 주었습니다.

Trevett은 WebCL이 가능한 OpenCL과 동등하게 하드웨어에 가까운 로우 레벨 형태로 정리하도록 결정되었다고 설명했습니다. 미들웨어적인 요소는 미들웨어 개발사에게 맡기고 기초적인 체제 스펙과 언어 스펙만을 규정하기로 했다는군요. OpenCL 기반의 물리 시뮬레이션 라이브러리 등에 Khronos가 관여하진 않는다고 합니다.

다만 아직 WebCL의 최종 스펙은 정해지지 않았습니다.

 

 

새 API, StreamInput이란?

최근의 스마트폰, 타블렛, 그 외의 모바일 디바이스는 스크린의 멀티 터치 뿐만 아니라 GPS, 가속 센서, 전자 컴퍼스 등 다양한 센서가 1개의 본체에 내장된 경우가 대부분입니다.

그 때문에 OS 개발자나 어플리케이션 개발자는 기기에 내장된 다양한 디바이스 상태를 알아내기 위해, 디바이스(센서) 제조사에서 제공하는 디바이스 드라이버를 활용해야 합니다. 탑재된 센서의 제조사가 다르면 복합적인 센싱을 실시하지 않을 수 없게 되어 모든 디바이스 드라이버의 스펙을 이해해야 할 필요가 생기게 되면서 개발 부하가 커지게 됩니다.

게다가 이렇게 힘들게 완성된 OS나 어플리케이션은 특정 제조사의 특정 센서에 지나치게 의존하는 설계가 되버립니다. 그 결과 센서가 바뀌면 프로그램의 대폭적인 변화가 필요하게 되버립니다.

다양한 센서를 사용한 OS나 어플리케이션에서는 이 때문에 이식성이 낮아지는 문제가 생기게 됩니다.

이런 문제에 대응하기 위해 Khronos에서 발족한 것이 Input Working Group입니다. 이 Input Working Group에 의해서 개발되고 있는 것이 StreamInput이라고 불리는 새 API입니다.

 

 

 

Khronos가 규격 책정에 나선 새 API, StreamInput

 

StreamInput 프로젝트에 참가하는 기업들. PrimeSense는 키넥트의 심도 센서를 개발한 회사입니다.

Khronos는 GDC 2011에서 OpenInput라는 이름의 새 API 규격을 책정하고 있음을 발표했지만, SIGGRAPH가 열릴 때까지 워킹 그룹에서 논의가 오간 결과 StreamInput으로 프로젝트명이 바뀐 것입니다.

이 이름에 대해 Trevett은 StreamInput도 개발 코드네임일 뿐이지만 큰 반대가 없을 경우 이대로 정식 명칭이 될 것이라고 설명했습니다. 마지막 순간에 OpenSI 같은 식으로 바뀔 수는 있겠지만요.

 

 

StreamInput은 입력 인터페이스의 합리적인 모듈화를 추진하는데 유효한 수단입니다.

이 StreamInput은 스마트폰이나 타블렛 디바이스에서 사용되는 제스처 입력이나 모션 입력을 체계적으로 취급할 수 있도록 해주는 API입니다. 이것은 WebGL이나 WebCL과 같은 HTML5 관련 기술과는 (아직까지는) 관계가 없으며, 임베디드 디바이스용의 API라고 봐야 합니다. 다양한 센서가 얻어낸 값을 어플리케이션이 바라는 형태의 정보로 만들어주는 역할을 담당하게 됩니다.

StreamInput의 프로그래머는 센서에서 취득한 정보를 처리-조립하여 기능 블럭의 1개 1개를 노드로 정의합니다. 각각의 노드를 어떻게 연결할지도 정의할 수 있고, 각 노드의 프로그래밍에 OpenMAX나 OpenCL을 사용하는 것이 가능합니다.

즉, 센서류가 변경되었을 경우 StreamInput에서 구축한 기능 모듈을 쪽을 수정하거나 재개발하면 OS나 어플리케이션을 수정할 필요 없이 실행할 수 있는 것입니다.

예를 들어 조준하여 공격하는 게임 어플이 있을 경우, StreamInput 프로그래머는에서 StreamInput이 '조준하고' '공격하는' 액션을 돌려줄 수 있는 기능 블럭을 개발할 필요가 있습니다.

터치 인터페이스에 맞춘 '조준' '공격' 액션을 돌려주는 기능 블럭을 만들면, 게임 어플이 터치 인터페이스를 지원하는 것이 됩니다. 여기서 키넥트처럼 제스처 인식 시스템에 대응시키면 게임 어플을 고치지 않고 키넥트용으로 다시 사용할 수 있게 된다는 것입니다.

StreamInput은 입력 인터페이스의 합리적인 모듈화를 추진하기 위한 유효한 수단이 될 뿐만 아니라, 다른 하드웨어에서 어플리케이션을 실행하는데 공헌하는 것이라고도 말할 수 있습니다.

 

StreamInput을 사용하 증강 현실 어플리케이션을 구축했을 경우.

 

 

센서의 이용과 인식을 어플리케이션에서 분리한 점이 특징.

OpenGL 4.2의 발표로 다이렉트 X가 앞으로 어떻게 대응하는지를 주목

SIGGRAPH 2011에서 Khronos의 발표를 정리하면 다이렉트 X 11을 넘었다는 것입니다. OpenGL 4.2의 발표, WebGL의 본격적인 보급을 위한 노력, 정식 출시 전의 최종 조정에 들어간 WebCL, StreamInput의 컨셉 결정 등등.

그 중에서도 OpenGL 4.2는 업계에 주는 영향이 클 것입니다. OpenGL 4.2의 확장 기능 가운데 Image_load_Store and Atomic Counters,Transform Feedback Instanced Example,Compressed Pixel Texture Storage의 3가지는 개발자에게 큰 환영을 받는 것이며, 다이렉트 X 11의 마이너 체인지 버전(나온다는 가정 하에)에도 탑재될 것입니다. 덧붙여서 Compressed Pixel Texture Storage는 블리자드 엔터테인먼트에서 요구했던 확장 스펙이라고 합니다.

이제 다이렉트 X가 앞으로 어떻게 대응할 것인지 주목할 필요가 있을 것입니다.