카테고리 보관물: TECH

[WAYLAND] HARDWARE COMPOSER (in ANDROID)

오늘은 안드로이드에서 HARDWARE COMPOSER (HWC) 라고 부르는 기능에 대해 소개하고자 한다. 사실 이 기능은 안드로이드 3.0 에서 소개된 기능이긴 하지만, 유사한 기능이 데스크탑에서 꽤 오래전부터 사용되어 왔었고, 현재 WESTON 에도 유사한 기능이 들어가있다. 암튼 이게 어떤 역할을 하고, 어떤 장점을 가지는지 살펴보자.

hwc0

위 그림은 HWC 가 없는 일반적인 하드웨어 가속을 이용한 렌더링 과정이다. 하나의 배경화면과 두 개의 윈도우가 있고, 각각 텍스처를 하나씩 할당받아 현재의 위치에 렌더링된다. 렌더링된 프레임버퍼는 HDMI 를 통해 디스플레이로 전송되어 결국 화면에 나타나게 되는데, 사실 이 정도만 해도 충분히 나쁘지 않은 결과를 보여준다. 하드웨어 가속(GPU)을 사용하기 때문에 프로세서(CPU)의 부담을 줄일 수 있고, 또한 충분히 빠르고 효과적이다. 하지만, GPU로 CPU의 역할을 대체하는 것만이 최선일까? 결국 GPU 또한 성능의 한계가 있고, 많은 전력을 사용하는 장치일뿐이다. 그래서 GPU를 보다 효과적으로 사용하기 위한 다양한 연구가 진행 중이고, 그 중에 비교적 작은 노력으로 작지 않은 효과를 볼 수 있는 방법 중의 하나가 바로 HWC 이다. 아래 그림은 HWC 와 하드웨어 가속을 이용하여 렌더링하는 과정을 나타내고 있다.hwc1

앞의 예제와 동일하게 하나의 배경화면과 두 개의 윈도우가 있지만, 배경화면을 제외한 두 개의 윈도우만 하드웨어 가속을 이용하여 렌더링하고 있다. 이럴 경우 우리가 얻을 수 있는 장점은 무엇일까? 예를 들어, 배경화면에 초당 60 프레임의 애니메이션이 들어가있는 경우를 상상해보자. 만약, HWC 가 없다면 전체화면을 덮고 있는 배경화면이 변경되었기 때문에, 프레임버퍼에 배경화면을 덮어씌우고 그 위에 윈도우 두 개를 다시 덮어씌워야 원하는 결과를 얻을 수 있다. 이런 과정을 GPU 가 초당 60번씩 해야한다. 하지만, 아래 그림처럼 HWC 를 사용하는 경우라면 어떨까? 배경화면만 변경되고 두 개의 윈도우는 변경사항이 없기 때문에 GPU 는 프레임버퍼를 다시 렌더링하지 않아도 되고, 배경화면만 HDMI 를 통해 디스플레이로 전송하면 동일한 결과를 얻을 수 있다. 즉, GPU 가 했던 컴포지팅의 일부를 디스플레이가 제공하는 오버레이 기능으로 대체함으로써 GPU 의 사용량을 극단적으로 줄일 수 있게 된 것이다. 그렇다면 원하는 모든 컴포넌트(배경화면, 윈도우, 마우스 포인터, …)에 독립적인 오버레이를 지정하면 더 좋지 않을까? 여기에는 다음과 같은 몇 가지 제약 사항이 있다.

  • 첫 번째는 디스플레이가 지원하는 오버레이의 수가 제한되어 있다. (약 2~4개 정도이지만, 대부분 하나는 마우스 포인터를 위해 할당해서 사용되고 있다.)
  • 두 번째는 회전과 같은 변형을 지원하지 않는다. 만약에 특정 윈도우가 기울어져 있다면 현재의 디스플레이가 제공하는 오버레이 기능은 사용하기 힘들다.
  • 세 번째는 중간에 끼어있는 컴포넌트는 오버레이를 사용할 수 없다. 예를 들어, 배경화면과 앞에 있는 윈도우가 하드웨어 가속을 사용한다면, 뒤에 있는 윈도우를 오버레이로 지정해서 동일한 결과를 얻기는 어려워진다.

이 외에도 여러 가지 제약사항이 더 있을 수 있겠지만, 앞으로 HWC 기능이 더 활발히 사용된다면 디스플레이 쪽에 더 유용한 기능이 들어갈 수 있지 않을까 기대해본다.

마지막으로 정리하면, 우리가 앞으로 기억해야 가장 중요한 사실은 기존에 CPU 와 GPU 가 나눠서 하던 컴포지팅에 디스플레이까지 참여하게 되었다는 것이다. 이는 컴포지팅 과정을 좀 더 복잡하게 만들겠지만, 그만큼 더 효과적으로 만들 수 있을 것으로 기대된다. 이제 플랫폼 개발자들은 CPU, GPU 그리고 디스플레이의 장단점을 파악해 보다 효과적인 컴포지팅 기술을 연구/개발해야 할 것 같다.

Advertisements

[TECH] 3D 영화를 위한 영상 압축 기술 소개 (MPEG 3DG)

필자가 관심을 가지고 있는 분야 중의 하나는 전역 조명 기반의 실시간 렌더링 기술이다. 그리고 이를 활용하는 증강/가상 현실과 3D 영화 분야도 늘 관심있게 지켜보고 있었는데, 얼마 전에 아시는 분과 이야기를 하다가 2D 영화는 기존의 수많은 압축 기술을 이용하여 배포하는데 3D 영화는 어떻게 해야하나는 의문이 생겼었다. 그때 막연히 이런저런 것들이 필요하겠구나라는 생각만 하고 넘어갔었는데, 최근에 우연히 관련 연구가 MPEG 쪽에서 이미 꽤 오랜 시간 동안 진행되고 있었다는 사실을 알게 되었다. 그래서 오늘은 MPEG 에 포함되어있는 3DG 관련 부분에 대해 간단히 소개하고자 한다. 필자가 영상 압축과 관련된 분야의 전문가가 아니기 때문에 상세한 이야기는 할 수 없고, 말그대로 간단한 소개 및 개념 이해 정도라고 보면 좋겠다.

우선 필자가 관심을 가지고 있는 3D 영화에 대한 정의부터 하겠다. 기존에도 3D 영화가 있었고, 현재도 JauntVR 과 같은 회사가 새로운 형태의 3D 영화 제작 기술을 공개하고 있지만, 필자가 관심을 가지고 있는 3D 영화는 영화를 관람하는 사람의 시점에서 실시간으로 렌더링을 하는 형태의 영화를 의미한다. 즉, 폴리곤, 텍스처, 그리고 3D 장면을 구성하는데 필요한 모든 정보를 실시간으로 넘겨받아 관람자의 시점에서 렌더링을 한다는 것이다. 여기에는 기본적으로 해결해야 할 두 가지 문제가 있다. 첫 번째는 3D 장면을 구성하는데 필요한 데이터가 기존의 2D 영화와 비교해 굉장히 많다는 것이고, 두 번째는 이러한 많은 데이터를 이용해 실시간으로 고품질의 렌더링을 해야한다는 것이다. 두 번째 문제는 필자가 직접적으로 관심을 가지고 있는 분야이기 때문에 관련된 글을 몇 번 올린 적이 있고, 오늘은 첫 번째 문제와 관련하여 MPEG 쪽에서는 어떤 연구를 진행하고 있는지를 살펴보려고 한다.

겨울왕국과 같은 3D 애니메이션 영화를 이용하여 2D 영화와 3D 영화의 차이점을 좀 더 알아보자. 3D 애니메이션의 제작 과정을 살펴보면, 물체의 형태를 만들고, 물체의 표면에 입혀질 이미지를 만들고, 물체의 움직임을 표현할 수 있는 애니메이션까지 만든 다음, 모든 장면을 렌더링하여 2D 영상으로 제작/배포한다. 즉, 아무리 많은 데이터를 이용해서 렌더링을 하더라도 렌더링된 장면은 지정된 해상도의 크기를 넘지 않는다. (HD급(1080p)은 장면당 1920x1080x4 bytes 만큼) 하지만, 실시간으로 렌더링하기 위해서는 렌더링에 필요한 모든 데이터가 필요하므로 배포해야할 데이터의 양이 기하급수적으로 늘어나게 된다. 또한, 기존의 2D 영상 압축 기술은 기본적으로 연속된 장면에서 중복 데이터를 제거해서 압축 효율을 높이는 것이다. 이를 위해 앞, 뒤에 있는 장면들을 재활용하는 등의 다양한 기술이 활용되는데, 3D 영상 압축 기술은 렌더링에 필요한 폴리곤, 텍스처, 애니메이션 등 데이터의 특성에 맞는 새로운 압축 기술이 필요하다.

우선 물체의 형태를 표현하는 폴리곤과 애니메이션에 대해 살펴보자. 기존의 3D 게임이나 그래픽 관련 작업을 해본 사람은 알겠지만, 일반적으로 3D 모델링을 할 때는 세 개의 점을 연결한 삼각형(폴리곤)을 이어붙여서 물체를 표현한다. 그래서 물체를 매끈하게 표현하기 위해서는 무수히 많은 폴리곤이 필요해지는 것이다. 이외에도 NURBS 와 3차원 베지어 곡선과 같은 수학적인 표현기법을 이용하는 경우도 있지만, 서로 다른 장단점을 가진다. 2차원 그래픽과 비교해서 설명하면, 폴리곤이 비트맵 방식이고, NURBS 가 벡터 방식이라고 보면 된다. 폴리곤은 표현의 자유도가 높지만 해상도와 애니메이션에서 문제가 있고, NURBS 는 자유도는 조금 낮지만 해상도와 애니메이션에서 장점을 가지고 있다. 그래서 물체의 애니메이션을 어떻게 나타낼지는 물체의 형태를 어떻게 표현했는지와 직접적인 연관이 있다. 경우에 따라 하나하나 따져봐야하지만, 실사 느낌이 강할 수록 폴리곤이 유리할 것이고, 겨울왕국 같은 애니메이션 느낌이 강할 수록 NURBS 와 같은 수학적인 표현기법이 유리할 것이다. (실제로 2D 에서도 비슷한 형태로 사용된다. 실사 사진이나 복잡한 이미지를 저장할 때는 JPEG 나 PNG 를 사용하고, 간단한 아이콘이나 이미지를 저장할 때는 SVG 와 같은 벡터 방식을 주로 사용한다.)

그리고 물체의 표면을 표현하는 방식에는 텍스처와 재질이 있다. 텍스처는 말그대로 물체의 표면에 특정 이미지를 덮어씌우는 용도로 사용되고, 재질은 전역 조명 렌더링에서 주로 사용되는 방식으로 물체가 가지는 물리적인 성질을 표현하는 용도로 사용된다. 예를 들어, 거울이나 플라스틱, 철과 같은 느낌은 적절한 재질과 적절한 렌더링을 통해 표현될 수 있다.

이처럼 3D 영상을 렌더링하기 위해서는 다양한 데이터가 필요하고, MPEG 에서는 폴리곤, 텍스처(재질), 애니메이션 각각의 데이터에 맞는 압축 기법을 제시하고 있다. 하지만 위에서 설명한 것처럼 3D 영상을 표현하는 방식에도 다양한 형태가 존재하고, 아직 구체적인 사례가 거의 없기 때문에 MPEG 에서 정의된 내용들은 아직은 초기 단계라고 보는 것이 좋을 것 같다.

[TECH] 3D 영화의 미래?!

지금까지 3D 영화라고 하면 단순히 입체감이 느껴지는 정도의 영화를 의미했다. 하지만 앞으로 나올 3D 영화는 그 정도 수준이 아니라, 내가 마치 영화 속 공간 안에 실제로 있는 듯이 주변을 자유롭게 둘러보면서 원하는 장면을 볼 수 있는 것을 의미한다. 정확히 무슨 의미인지 이해가 안 간다면 오큘러스 리프트와 같은 가상 현실 장치를 생각해보라. 오큘러스 리프트는 헤드 트래킹을 통해 사용자가 마치 3D 공간 안에 있는듯한 착각을 느끼게 하는 기술로, 최근 페이스북 뿐 아니라 삼성까지 큰 관심을 가지고 있는 기술이다. 즉, 앞으로 나올 3D 영화는 오큘러스 리프트와 같은 가상 현실 장치를 이용하여 감상할 수 있는 영화를 의미한다는 것이다. 기존 영화처럼 하나의 시점을 따라가면서 촬영된 영상을 감상하는 것이 아니라, 감상자가 원하는 시점을 선택해서 감상할 수 있다는 것이다. 여기에는 다양한 새로운 연출 기법들이 필요할 것이다. 감상자의 위치를 어떻게 변경할 것인가, 장면을 어떻게 변경할 것인가 등등등…하지만 오늘은 가장 기본적인 3D 영화에 사용할 영상을 어떻게 제작할 것인가에 초점을 맞춰 살펴볼 계획이다.

3D 영상을 만드는 가장 좋은 방법은 영화 속에 등장할 모든 물체를 3D 로 제작하는 것이다. 하지만, 현재 3D 모델링과 애니메이션의 한계로 섬세한 물체를 표현하는 것은 한계가 있고, 또한 감상자의 시점에 따라 실시간으로 렌더링을 하는 것도 아직은 미흡하기 때문에 다른 대체 기술이 필요하다. 그래서 상당히 제한적이지만 충분한 활용 가치를 가지고 있는 것으로 보이는 3D 영화 제작 기술을 가지고 있는 스타트업이 큰 관심을 받고 있다.

https://www.facebook.com/jauntvr

위 링크는 JAUNT 라는 스타트업의 페이스북 페이지이다. 이 스타트업은 360 도를 한번에 촬영할 수 있는 새로운 카메라를 개발하고, 이를 활용하여 실제 영화를 제작 중이라고 한다. 이는 앞에서 설명한 3D 모델링/렌더링 기반의 영화와는 서로 다른 장단점을 가진다. 해당 기술을 이용하면 실사 영화 제작이 가능하고, 영화 감상에 큰 부담이 없지만, 원하는 시점에서 볼 수 있는 장면은 3D 가 아니고, 미리 촬영된 2D 영상일 뿐이라는 것이다. 하지만 이 또한, 앞으로 나올 다양한 3D 영상 제작 기술 중의 하나일 뿐이니, 생각보다 별거 아니네라고 실망할 필요는 없다.

사실 필자가 개인적으로 관심을 가지고 있고, 2년 전부터 개발해왔던 실시간 레이트레이싱 기술을 이용하면 좀 더 혁신적이고, 도전적인 3D 영화 제작이 가능하다.

위의 영상은 3D 모델링과 애니메이션으로 제작하고, 실시간 레이트레이싱 기술을 이용하여 렌더링한 영상이다. 사실 대충 보면 실사 영상이라고 느껴질만큼 놀랍지만, 자세히 보면 사람과 같이 섬세한 표현이 필요한 물체가 없고, 영상에 노이즈가 많이 껴있는게 보일 것이다. 하지만, 이렇게 실사 느낌의 렌더링이 아니라, 현재 드래곤 길들이기나 겨울왕국 같은 스타일의 렌더링을 한다면 훨씬 안정적인 렌더링이 가능할 것이다. (개인적으로는 앞에서 언급했던 스타트업의 방식보다 3D 애니메이션을 이용한 3D 영화가 훨씬 더 재밌을 것 같다는 생각이 든다. 사실, 1년 전쯤에 같이 일하는 후배들에게 오큘러스 리프트와 실시간 레이트레이싱 기술을 이용한 3D 영화를 제작해보면 굉장히 재밌을것같다는 얘기를 한적이 있다. 정말 하고 싶은 일 중의 하나이다.)

재밌는건, 이러한 3D 영화가 실제 제작되기 시작하면 기존의 영화관에서는 상영이 불가능하다. 가장 큰 이유는 기존의 3D 영화와 달리 앞으로 나올 3D 영화는 감상자마다 시점이 모두 다르기 때문에 결국, 개인 상영관 밖에 존재할 수 없다는 것이다. 사실 영화관보다는 현재의 DVD 방과 같이 개인 감상실 같은 형태로 운영될 것으로 예상된다. 어찌됐든 앞으로 3D 영화 제작 기술이나 시장이 어떻게 흘러갈지 개인적으로 무척(!) 기대가 된다.

[WAYLAND] CSD + SSD <= DWD?!

최근 KDE 측에서 매우(!) 흥미로운 기술을 하나 공개했다. 바로 DWD(Dynamic Window Decorations) 라는 기술인데, 오늘은 이 기술에 대해 간단히 살펴보고자 한다.

http://kver.wordpress.com/2014/10/25/presenting-dwd-a-candidate-for-kde-window-decorations/

이전 글들에서 WAYLAND 와 X11 을 비교하면서 가끔 언급했었지만, 윈도우 데코레이션(Window Decorations)은 최소/최대/종료 버튼이 있는 윈도우 프레임을 그리는 일을 의미하고, CSD(Client-Side Decorations)는 클라이언트가 윈도우 프레임을 그리는 방식, 그리고 SSD(Server-Side Decorations)는 서버가 윈도우 프레임을 그리는 방식을 의미한다. 각각의 장단점에 대해 간단히 정리해보면 다음과 같다.

  • SSD 는 서버에서 직접 그리는 작업을 해야하기 때문에 다양한 폰트/벡터/아이콘/… 렌더링을 지원해야하는 문제가 발생한다. 반면에, CSD 는 클라이언트가 모든 것을 그리기 때문에 상대적으로 서버를 가볍게 유지할 수 있다. (WAYLAND 의 탄생 목적이 서버의 경량화이기 때문에 당연히 WAYLAND 는 CSD 를 선호한다.)
  • CSD 는 윈도우 프레임을 클라이언트가 그리기 때문에 최소/최대/종료 이벤트를 클라이언트가 확인해서 서버에게 요청해야 한다. 그래서 클라이언트가 어떤 오류에 의해 종료 이벤트를 처리하지 못 하면 정상적인 종료가 힘들어진다. (SSD 는 클라이언트와 상관없이 종료 이벤트를 처리할 수 있기 때문에 이러한 문제는 발생하지 않는다.)
  • SSD 는 서버에서 모든 윈도우의 프레임을 그리기 때문에 일관성을 유지할 수 있다. 하지만 CSD 는 각종 위젯 엔진이나 어플리케이션들이 자발적으로 윈도우 프레임을 일관성있게 유지해야 한다.

이러한 장단점들을 가지는 CSD 와 SSD 에 대한 갑론을박은 최근 X11 에서 빠르게 WAYLAND 로 전환되면서 더해지고 있었는데, 최근 KDE 측에서 상당히 획기적인 아이디어를 제안한 것이다. 사실 아이디어 자체는 매우 간단하다. 하지만, CSD 와 SSD 의 장점을 결합한 새로운 윈도우 데코레이션 기법이라는 점을 훨씬 넘어서는, 다양한 응용이 가능한 기법이 탄생했다는 사실에 다들 놀라워하고 있다. 원리는 간단하다. 예를 들면, 클라이언트는 최소/최대/종료 버튼으로 사용할 아이콘을 서버에 등록하고, 서버는 이 아이콘들을 원하는대로 배치해서 사용할 수 있다. 즉, 그리는 것은 CSD 처럼 클라이언트가 하지만, 레이아웃과 이벤트 처리는 SSD 처럼 서버가 하는 것이다. 이것만으로도 사실 상당히 많은 장점들을 가진다. 하지만, 여기에서 끝이 아니고 새로운 응용 방법들이 하나둘씩 제안되고 있다.

multiformfactor

위의 그림을 자세히 보면, 어플리케이션의 프로그레스바와 종료 버튼 등이 윈도우 프레임과 패널, 그리고 스마트폰 타입의 레이아웃에 그대로 적용되는 것을 볼 수 있다. 이는, 클라이언트가 해당 프로그레스바와 종료 버튼을 서버에 등록해놓으면 서버가 필요에 따라 다양한 형태로 사용할 수 있다는 것이다. 그리고 더 나아가면, 클라이언트는 개별 컴포넌트들을 그리는 역할을 하고, 서버는 환경에 따라/필요에 따라 해당 컴포넌트들을 적절히 배치할 수 있게 된다. 아직 초기 제안 수준이기 때문에 DWD 라는 아이디어가 어디에서 어떻게 쓰일지는 알 수 없다. 하지만 상당히 획기적인 아이디어이기 때문에 현재의 윈도우 매니저들에게 작든, 크든 영향을 끼칠거라는 점은 명백한 것 같다. 또한, 향후 컴퓨팅 환경이 데스크탑 뿐 아니라, 스마트폰, 스마트TV, 스마트카 등 크기와 모양이 다양해지는 점을 감안해보면, 클라이언트 측에서 처리해야했던 레이아웃에 대한 부담을 서버가 적절히 가져갈 수 있을 것으로 기대된다.

[WAYLAND] GPU 동작 원리 (렌더링 & 동기화)

오늘은 GPU 의 가장 기본적인 역할인 렌더링과 관련된 내용을 살펴보고자 한다. 특히, OPENGL 을 사용하는 어플리케이션과 윈도우 매니저, 그리고 GPU 간의 동기화가 어떻게 이루어지는지에 대해 초점을 맞춰서 설명할 계획이다. 그럼 우선 기본적인 용어 몇 가지부터 살펴보자. (이후부터 모든 설명은 TESLA 아키텍처 이후의 NVIDIA 그래픽 카드를 기준으로 한다.)

첫 번째로 알아야 할 것은 채널(channel)이다. 일반적인 CPU 는 코드를 메모리에 올려놓고 PC(Program Counter) 레지스터를 이용하여 명령을 순차적으로 수행한다. 하지만 GPU 는 채널이라는걸 이용하는데, 이는 일종의 링(ring) 버퍼라고 생각하면 된다. 즉, 3D 어플리케이션은 채널의 링버퍼에 명령어를 주입하고, GPU 는 채널의 링버퍼에서 명령어를 읽어와서 실행하는 과정을 반복적으로 수행하는 것이다. 채널의 링버퍼에 들어가는 명령어에는 OPENGL 에서 제공하는 기본 명령어들(glVertex, glColor, …)과 렌더링에 관련된 다양한 명령어들이 존재한다.

두 번째로 알아야 할 것은 버퍼(buffer)이다. 기본적인 버퍼에는 폴리곤의 표면에 그려지는 그림을 저장하는 텍스처와 렌더링한 결과물을 저장하는 프레임버퍼가 있고, 이외에도 버텍스를 저장하는 버퍼, 인덱스를 저장하는 버퍼 등 다양한 버퍼들이 있다.

마지막으로 알아야 할 것은 펜스(fence)이다. 위의 두 가지는 들어본 적이 있을 가능성이 높지만, 펜스는 아마 처음 들어본 사람이 많을 것이다. 이는 간단히 얘기하면, 동기화를 위한 일종의 세마포어라고 보면 된다. 사실 따지고 보면, 스핀락(spinlock) 이라고 보는 것이 더 정확한 표현인것 같다. 즉, 하나의 변수를 미리 지정해놓고, 한 채널에서는 작업이 완료되면 해당 변수를 특정 값으로 설정하고, 다른 채널에서는 해당 변수의 값이 특정 값이 될때까지 반복적으로 확인하면서 기다리는 것이다. GPU 의 특성상, 코어가 많고 운영체제와 같은 관리 체계가 없는 것을 감안하면 나름 최선의 선택이라고 볼 수 있다.

그럼 간단한 용어 설명은 여기까지 하도록 하고, 기본적인 렌더링 과정부터 살펴보도록 하자.

fence1

위의 그림은 일반적으로 하드웨어 가속을 이용하는 소프트웨어에서 프레임버퍼 렌더링(swapbuffer)과 디스플레이 동기화(pageflip)를 수행하는 과정을 나타내고 있다. 우선 그림에서 보이는 몇 가지 용어들에 대해 추가로 설명하면, 세마포어(semaphore)는 펜스(fence)에서 사용하는 변수를 의미하고, 펜스에 EMIT 이 붙어있는 것은 세마포어에 특정 값을 설정하는 역할을 하고, 펜스에 SYNC 가 붙어있는 것은 세마포어가 특정 값인지를 확인하면서 기다리는 역할을 한다. 그리고 오브젝트는 텍스처와 프레임버퍼만 표시해두었는데, 모든 오브젝트는 특정 펜스와 연관되어 있다. 이유는, 예를 들어, 프레임버퍼로 사용되는 오브젝트는 렌더링이 완료되어야만 유효해지기 때문이다. (이외에도 오브젝트에 펜스를 연결시켜두는 이유는 여러 가지가 있다.) 이러한 이유로 렌더링이 완료되었음을 나타내는 펜스를 미리 만들어두고, 프레임버퍼로 사용되는 오브젝트가 해당 펜스를 참조하게 해놓은 것이다. 그리고 다른 채널에서 해당 오브젝트를 사용할 때는 오브젝트가 참조하는 펜스를 이용하여 동기화(SYNC)를 하면 아무 문제없이 사용할 수 있게 된다.

그럼 이제 그림을 보면서 동작 과정을 살펴보도록 하자. OPENGL 어플리케이션에서 렌더링을 하기 위해 두 개의 텍스처 오브젝트와 렌더링과 관련된 명령어들을 준비한 다음, MESA/DRM 을 통해 렌더링을 요청한다. 그러면 MESA/DRM 에서는 채널을 하나 할당받은 다음, 우선 렌더링에 사용할 두 개의 오브젝트가 참조하는 펜스를 SYNC 하는 명령어를 집어넣는다. 이는 해당 오브젝트들이 다른 목적에 의해 작업이 아직 완료되지 않았을 수도 있기 때문에 반드시 필요한 과정이다. 그리고나서 렌더링에 필요한 명령어들을 순서대로 집어넣고, 마지막으로 프레임버퍼 오브젝트에서 참조하게 될 펜스를 만든 다음, 이를 EMIT 하는 명령어를 집어넣는다. 여기서 한 가지 명심할 것은 채널에 명령어를 집어넣는 것은 CPU 에서 처리하는 것이고, 실제 채널에 있는 명령어를 수행하는 것은 CPU 와 상관없이 GPU 에서 비동기로 수행하게 된다는 점이다. 즉, 언젠가 GPU 가 해당 채널에 있는 명령어를 처리하게 되면 맨 앞에 있는 펜스를 SYNC 하는 부분부터, 렌더링과 관련된 명령어들, 그리고 마지막에 있는 펜스에 EMIT 하는 부분까지 순서대로 수행한다는 말이다.

그렇다면 디스플레이 동기화는 어떻게 처리할까? 이것 또한 렌더링과 유사한 과정을 거친다. OPENGL 어플리케이션에서 디스플레이 동기화(pageflip)를 요청하면 MESA/DRM 에서는 해당 요청을 처리할 채널을 하나 할당받은 다음, 화면에 출력할 프레임버퍼 오브젝트가 참조하는 펜스를 SYNC 하는 명령어를 집어넣는다. 이를 통해 해당 프레임버퍼를 위한 렌더링이 완료된 다음, 이후의 요청이 처리되어 안전하게 프레임버퍼를 화면에 표시할 수 있게 되는 것이다. 그래서 해당 펜스를 SYNC 하는 명령어를 넣은 다음에 실제 VBLANK 에 맞춰서 프레임버퍼를 교체하는 명령어들을 집어넣게 되면, CPU 의 할일은 끝나게 된다. 즉, 프레임버퍼 렌더링부터 디스플레이 동기화까지 CPU 입장에서는 필요한 명령어와 펜스만 잘 설정해주면 GPU 에 의해 정확한 순서대로 작업이 처리되는 것이다.

이제 마지막으로 윈도우 환경에서 클라이언트와 서버가 동시에 하드웨어 가속을 사용하는 과정을 간단히 살펴보자.

fence2

위의 그림을 보면, 클라이언트는 프레임버퍼 렌더링 요청을 한 후, 바로 서버에게 해당 버퍼를 전달한다. (wl_surface_commit) 그리고 서버는 클라이언트가 요청한 프레임버퍼 또한 일반적인 오브젝트이기 때문에 해당 오브젝트가 참조하는 펜스를 SYNC 한 후에 앞에서 계속 언급했던 것과 동일한 과정을 수행한다. 즉, 클라이언트가 요청한 프레임버퍼 오브젝트의 펜스는 클라이언트가 요청한 렌더링이 완료된 후에 EMIT 되기 때문에 아무 문제없이 렌더링이 완료된 프레임버퍼가 화면에 출력된다.

여기까지 CPU 와 GPU 가 어떤 방식으로 프레임버퍼를 렌더링하고 동기화하는지에 대해 살펴보았다. 지난 글에서 소개했던 메모리 및 주소 공간 관리처럼 GPU 는 CPU 와 비슷한 듯하면서도 상당히 다른 방식으로 동작한다. 가장 큰 이유는 GPU 는 CPU 에 의해 동작하는 수동적인 장치라는 것이다. 그리고 매번 CPU 가 동일한 요청을 반복해서 보내지 않는다는 것이다. 왜냐하면 기본적으로는 매번 다른 화면이 모니터에 표시되기 때문이다. 이러한 차이점들을 잘 이해하고 생각을 정리해본다면 GPU 가 동작하는 방식에 대해 이해하는 것이 좀 더 쉬울 것 같다.

[TECH] 리눅스 DIRECTX 지원 방식 소개

오늘은 리눅스에서 DIRECTX 를 지원하는 방식에 대해 간단히 살펴보도록 하겠습니다. 가장 기본적으로는 윈도우 에뮬레이션 기능을 제공하는 WINE 이 떠오르실텐데요, 이외에 어떠한 방식들이 있는지, 그리고 어떤 차이점들이 있는지를 알아보도록 하겠습니다.

d3d9

위의 그림에 나와있는 것처럼, 현재 리눅스에서 DIRECTX 를 지원하는 프로젝트는 세 가지 정도가 있습니다. 첫 번째는 가장 유명한 WINE 이고, 두 번째는 VALVE 에서 윈도우용 게임을 포팅하기 쉽게 도와주기 위해 만든 ToGL 이라는 프로젝트이고, 세 번째는 MESA 에서 제공하는 D3D9 state tracker 입니다. 우선 가장 큰 차이점은 WINE 과 ToGL 은 DIRECTX 를 OPENGL 인터페이스와 셰이더(GLSL)로 변환해주는 방식이지만, D3D9 state tracker 는 MESA 에서 DIRECTX 인터페이스를 바로 처리해주는 방식입니다. 그래서 직접 테스트해보진 않았지만 D3D9 state tracker 가 WINE 에 비해 성능이 월등히 좋다고 합니다. (당연한 결과겠죠?!) 하지만 그림에 보시는 것처럼 WINE 과 ToGL 은 오픈소스 드라이버뿐 아니라 NVIDIA/AMD 드라이버까지 지원하지만 D3D9 state tracker 는 당연히 MESA 에서만 지원하고 있습니다. (그래서그런지 WINE 측에서는 반응이 시큰둥한 것 같습니다.) 그리고 WINE 과 ToGL 도 확연히 다른 목표를 가지고 있는데요, WINE 은 DIRECTX 전체를 에뮬레이션하는 것이 목표지만, ToGL 은 리눅스로 포팅하기 쉽게 도와주고 성능도 최대한 유지하는 것이 목표입니다.

이 세 가지 프로젝트가 향후 어떻게 흘러가는지 살펴보는 것 또한 소소한 재미가 될것 같습니다. 앞으로 점점 더 많은 게임엔진과 게임들이 OPENGL 을 지원하게 되면 굳이 이런 짓(?)을 할 필요는 없어지겠지만…

[WAYLAND] OPENGL 소프트웨어스택의 미래 (XDC 2014)

오늘은 얼마 전에 있었던 XDC 2014 에서 발표됐던 내용을 바탕으로 향후 OPENGL 소프트웨어스택이 어떤 방향으로 발전해나갈지를 간단히 정리해보려고 합니다. 그에 앞서 OPENGL 소프트웨어스택이 정확히 무엇을 의미하는지에 대해 간단히 살펴보도록 하겠습니다.

opengl-sw

위의 그림은 오픈소스 기반의 OPENGL 소프트웨어스택(MESA/DRM)의 구조를 간단히 표현한 것입니다. 계층적으로 보면 MESA/DRM 라이브러리와 드라이버가 있습니다. 우선 DRM 라이브러리는 미리 정의된 IOCTL 인터페이스를 이용해 DRM 드라이버를 단순 호출해주는 역할만을 하므로 길게 설명하지 않고, MESA 라이브러리와 DRM 드라이버에 대해 설명하도록 하겠습니다. (앞으로 DRM 이라고하면 커널 드라이버를 의미한다고 생각하시면 됩니다.)

OPENGL 소프트웨어스택이 하는 역할은 크게 보면 두 가지입니다. 첫 번째는 윈도우 시스템(X11, WAYLAND, …)을 지원하는 것이고, 두 번째는 하드웨어 가속을 지원하는 것입니다. 그렇다면 이를 위해 MESA 라이브러리와 DRM 드라이버는 각각 무슨 일을 할까요? 간단한 예를 들어 설명하면, 하드웨어 가속을 이용하여 OPENGL 렌더링을 하기 위해서는 GPU 에 렌더링을 위한 명령어 스트림을 전달해야 합니다. 그러기 위해서는 GPU 에서 접근할 수 있는 메모리를 할당받아서 필요한 명령어 스트림을 채워야겠죠. 이 때, 실제로 메모리를 할당해주는 역할을 DRM 드라이버가 하고, 명령어 스트림을 채워주는 역할은 MESA 가 하는 것입니다. 즉, 메모리 할당/해제와 같이 커널의 권한이 필요한 것은 DRM 드라이버가 하고, 나머지는 모두 MESA 가 한다고 보시면 됩니다. (사실 역할을 나누기 좀 애매한 부분도 있긴 하지만, 대략 이 정도로 이해하시면 무난할 것 같습니다.) 그래서 우리가 일반적으로 많이 듣는 윈도우 시스템을 지원하는 GLX, EGL 등과 OPENGL 버전 3 이나 4, ES 같은 것들은 실제로는 MESA 와 직접적으로 연관이 있습니다.

그럼 이제 윈도우 환경에서 OPENGL 을 어떻게 사용하는지 살펴보도록 하겠습니다. 우선, 클라이언트와 서버가 OPENGL 을 사용하는 방식에 대해 간단히 살펴보면, 클라이언트는 자기가 원하는 결과물을 렌더링해서 서버로 전달하는 일을 하고, 서버는 모든 클라이언트가 렌더링한 결과물을 받아서 실제 화면에 표시될 결과물을 렌더링한 후 디스플레이에 출력하는 일까지 합니다. 서버와 클라이언트는 렌더링하는 방식도 조금 다르고, 서버는 디스플레이 관리까지 해야하니 사용하는 인터페이스도 차이가 조금 있습니다. 다음은 클라이언트와 서버에서 사용하는 인터페이스들에 대한 설명입니다.

  • GL-API..클라이언트와 서버 모두가 사용하는, 렌더링을 하기 위해 사용하는 기본적인 드로잉 인터페이스입니다. (glVertex3f, …)
  • EGL-API(wl-client)..클라이언에서 사용하는 윈도우 시스템 관련 인터페이스로, 렌더링을 위한 버퍼를 생성하고, 렌더링 후에 서버에게 전달하는 일 등을 처리해줍니다.
  • EGL-API(wl-server)..서버에서 사용하는 윈도우 시스템 관련 인터페이스로, 클라이언트가 렌더링한 결과물을 받아서 사용할 수 있도록 준비하는 일 등을 처리해줍니다.
  • EGL-API(gbm)..서버에서 실제로 화면에 출력될 결과물을 렌더링하기 위해 사용하는 인터페이스입니다.
  • KMS-API..서버에서 렌더링한 최종 결과물을 실제 화면에 뿌리기 위해 사용하는 인터페이스입니다. (pageflip, …)

일단 클라이언트와 서버에서 사용되는 인터페이스들을 나누어보면 이 정도가 되겠습니다. 그럼 이제 본격적으로 XDC 2014 에서 발표된 OPENGL 소프트웨어스택과 관련된 발표들을 살펴보도록 하겠습니다. 이 발표들의 기본 목적은 딱 한 가지입니다. 현재 WAYLAND 를 기반으로 한 윈도우 매니저들이 MESA/DRM 에 기반한 EGL/KMS 인터페이스만을 지원하고 있기 때문에 상용 드라이버의 거취가 애매해지고 있습니다. 즉, 위에서 얘기했던 EGL-API 와 KMS-API 를 현재 상용 드라이버는 지원하지 않고 있기 때문에 앞으로 WAYLAND 기반 윈도우 매니저에서는 상용 드라이버를 사용할 수 없다는 것입니다. 그래서 이를 어떻게 해결해 나갈지에 대한 AMD 와 NVIDIA 측이 발표한 내용입니다.

http://www.x.org/wiki/Events/XDC2014/XDC2014DeucherAMD/amdgpu_xdc_2014_v3.pdf
첫 번째로 AMD 에서 발표한 내용을 살펴보도록 하겠습니다. AMD 는 상당히 적극적인 오픈소스 지원/통합 계획을 소개했습니다. 아직 공개되진 않았지만 AMDGPU 라는 기존의 오픈소스 드라이버에 기반한 새로운 오픈소스 드라이버를 제공할 계획이라고 합니다. 이를 통해 기존의 오픈소스 드라이버에서 지원하지 못했던 최신 그래픽 카드를 지원할 계획이라고 하니, 상당히 기대되는 부분입니다. 그리고 향후에는 상용 드라이버보다 오픈소스 드라이버에 더 집중하겠다는 얘기도 하고 있습니다. 일단 더 지켜봐야겠지만, AMD 는 오픈소스 드라이버에 대한 적극적인 지원을 통해 호환성 문제를 해결할 계획인 것 같습니다.

http://www.x.org/wiki/Events/XDC2014/XDC2014RitgerEGLNonMesa/nvidia-and-compositors.pdf
두 번째로 NVIDIA 에서 발표한 내용입니다. 일단 NVIDIA 는 AMD 와는 반대로, 상용 드라이버에서 필요한 인터페이스를 지원할 계획이라고 합니다. 그리고 더 나아가서 EGL 에서 WAYLAND, GBM, KMS 와 관련된 부분들을 표준 인터페이스로 다시 정의해서 개발하자는 얘기를 하고 있습니다. 오픈소스 쪽에서 어떻게 반응할지, 구체적으로 일이 어떻게 진행될지는 지켜봐야겠지만, 개인적으로는 나쁘진 않은 것 같습니다. 그리고 조만간 제안하는 인터페이스를 이용해서 수정한 WESTON 패치를 공개한다고 하니, 그 결과물을 보고나서 좀 더 생각을 해봐야겠습니다.

http://www.x.org/wiki/Events/XDC2014/XDC2014RitgerGLABI/presentation-xdc2014.pdf
마지막으로 NVIDIA 에서 진행하고 있는 좀 더 포괄적인 OPENGL 소프트웨어스택 통합에 대한 발표입니다. 얼마 전에 XDC 2014 행사 소개하는 글을 올리면서 개인적으로 관심이 가는 프로젝트라고 언급했었는데요, 아쉽지만 큰 진척이 있거나 크게 기대할만한 결과물이 나올꺼같진 않아보입니다. 이 프로젝트의 목적을 간단히 소개하면 위에서 언급했던 GL-API 를 제공하는 라이브러리를 하나로 통합하고, EGL-API 도 제조사와 독립적인 부분을 따로 떼서 하나의 라이브러리 형태로 공유하자는 것입니다. 그래서 하나의 시스템에서 여러 드라이버를 동시에 사용하거나, 그 이상의 일들을 해보자는 것입니다. 일단은 이 프로젝트가 계속 진행이 될지, 어떻게 진행이 될지 더 지켜봐야겠습니다.

결론적으로 DRM 드라이버 인터페이스와 EGL/KMS 가 업계 표준으로 인정받은 상황이고, 상용 드라이버 측의 지원도 문제없이 진행될꺼같습니다. 그리고 개인적으로는 ARM 쪽에서도 이런 흐름에 잘 편승했으면 하는 바램을 가져봅니다.