NVIDIA EGLStreams vs GBM

http://www.phoronix.com/scan.php?page=news_item&px=Wayland-Dev-NV-Thoughts
http://www.phoronix.com/scan.php?page=news_item&px=Streams-vs-GBM-Toolkits

2년전 즈음 관련 뉴스가 나왔을 때부터 우려했던 상황이 벌어졌네요. GBM 은 기존의 MESA/DRM 쪽에서 사용하는 일종의 GPU 버퍼 관리 인터페이스인데, NVIDIA 가 이걸 자신들이 정의한 EGL 확장 인터페이스로 대체하려고 하고 있습니다. 당연히 오픈소스 진영에서는 반대를 하고 있구요. NVIDIA 입장은 EGL 이 표준이니 잘 정의된(?) 새로운 표준을 만들어서 같이 잘 해봅시다 이고, 오픈소스 진영은 기존의 GBM 잘 쓰고 있는데 먼소리냐 이러고 있습니다. 아무래도 윈도우 매니저 개발자 입장에서는 동시에 두 가지의 버퍼 관리 인터페이스를 지원하는게 상당히 큰 부담이기 때문에, 모든 관련 개발자들이 NVIDIA 가 GBM 을 그대로 따라주길 바라고 있지요. 개인적으로 여러가지 이유로 NVIDIA 상용 드라이버를 사용할 수 있는 날이 오기를 손꼽아 기다렸는데…당분간 쉽지 않겠네요;;

이번 사건은 오픈소스 진영에서도 종종 발생하는 일종의 초일류 기업의 갑질이라고 볼 수 있는데요, 해당 사건이 어떻게 진행되고, 마무리될지 궁금하네요. (아 귀찮아 그냥 GBM 만 쓰자;;;)

MS 윈도우10 홀로렌즈 공개!

MS 가 윈도우10 을 공개하면서 홀로렌즈라는 기술을 같이 공개했습니다. 간단한 소개 영상을 통해 살펴보면, 윈도우 매니저 계층에서 증강 현실을 지원하는거 같습니다. 증강 현실을 지원하는 앱은 많았지만, 윈도우 매니저 계층에서 지원하는 건 처음인데요, 사실 저희가 2013년도에 개발했던 레이트레이싱 기반의 윈도우 매니저와 유사한 컨셉이라고 볼 수 있습니다. 페이스북이 오큘러스 리프트를 인수하고, MS 가 홀로렌즈라는 기술을 공개하고, …글로벌 기업들의 가상/증강 현실 기술에 대한 관심이 나날이 커지고 있는 것 같아 3년, 5년 뒤가 정말로 기대가 됩니다. 아래에 주목할만한 관련 기술 영상 몇 개를 첨부하여 드립니다.

SpaceGlasses 라는 스타트업이 공개한 증강 현실 기술입니다. MS 에 비해 약간 초라해보이긴 하지만, 스타트업이니만큼 자신들만의 멋진 기술을 만들어나가면 좋겠습니다.

MS 가 공개한 홀로렌즈 홍보 영상입니다. 윈도우 플랫폼 기술을 가지고 있는 회사인 만큼 플랫폼 계층에서만 할 수 있는 기능들이 추가되어있습니다.

모질라 측에서 파이어폭스에 가상 현실 기능을 추가하였습니다. 아래는 MOZVR 이라는 기술을 통해 3D 가상 현실 기반의 웹페이지를 시연하는 영상입니다.

아직은 약간 부족해 보이고, 불편해 보이지만, 그래도 상당히 매력적으로 보이는 기술임에는 틀림없는 것 같습니다. 저희도 지금 진행 중인 프로젝트 잘 마무리하고 다시 3D 가상 현실 기반의 윈도우 매니저 개발에 뛰어들고 싶은 마음이 불끈 솟습니다!

[WAYLAND] HARDWARE COMPOSER (in ANDROID)

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

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

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

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

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

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

[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 에서 정의된 내용들은 아직은 초기 단계라고 보는 것이 좋을 것 같다.

대구 MBC 방송에 네모아트 출현!

대구 MBC에서 초/중학생들을 대상으로 한 ‘3D프린터 미래창조 올림피아드’를 소개하면서 네모아트가 방송에 나왔습니다. ㅎㅎ

http://www.dgmbc.com/news/view2.do?nav=news&selectedId=181163&class_code1=040000&news_cate=

중간에 학생들이 들고 있는 아이패드에 설치되어있는 앱이 저희가 개발한 네모아트입니다. 어린 학생들이 네모아트를 이용하여 각자가 원하는 것을 디자인하고, 3D 프린터를 이용하여 출력하는 모습을 보니 재밌네요. ㅎㅎ

소니, ‘픽셀’ 영화 2015년 7월 24일 미국 개봉!!!

필자가 큐브 기반의 3D 모델링과 레이트레이싱 기반의 렌더링 기능을 가진 ‘네모아트’ 앱을 개발하게 된 결정적인 계기가 되었던 단편영화가 소니에 의해 장편영화로 제작되었네요! 대박!!! 2년전 즈음에 우연히 이걸 보고 굉장히 충격을 받고 푹 빠졌었는데…너무나 반가운 소식이고, 기대가 되네요~ 아래는 원작인 단편영화입니다.

그리고 아래는 이번에 소니에서 공개한 포스터입니다.

상당히 기대를 갖게 만드는 포스터네요~ 대박 기원!!!

헐리우드 SF 영화 UI 디자인 관련 블로그 소개!

아이언맨, 트랜스포머, 스타트랙, 프로메테우스 등 쟁쟁한 헐리우드 SF 영화의 FUI (Fictional or Fantasy User Interface) 를 디자인했던 사람들과의 인터뷰를 포스팅하는 블로그가 있습니다. 정말 흥미롭고 재밌는 블로그네요. 블로그 운영자는 현재 구글의 안드로이드 UI 개발팀에 있는 사람이라고 하네요. SF 영화를 사랑하는, 특히 SF 영화에 나오는 UI 를 사랑하는 사람에게는 정말 소중한 블로그인것 같습니다!

http://www.pushing-pixels.org/inmotion/

[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) 라는 기술인데, 오늘은 이 기술에 대해 간단히 살펴보고자 한다.

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 처럼 서버가 하는 것이다. 이것만으로도 사실 상당히 많은 장점들을 가진다. 하지만, 여기에서 끝이 아니고 새로운 응용 방법들이 하나둘씩 제안되고 있다.

위의 그림을 자세히 보면, 어플리케이션의 프로그레스바와 종료 버튼 등이 윈도우 프레임과 패널, 그리고 스마트폰 타입의 레이아웃에 그대로 적용되는 것을 볼 수 있다. 이는, 클라이언트가 해당 프로그레스바와 종료 버튼을 서버에 등록해놓으면 서버가 필요에 따라 다양한 형태로 사용할 수 있다는 것이다. 그리고 더 나아가면, 클라이언트는 개별 컴포넌트들을 그리는 역할을 하고, 서버는 환경에 따라/필요에 따라 해당 컴포넌트들을 적절히 배치할 수 있게 된다. 아직 초기 제안 수준이기 때문에 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 의 특성상, 코어가 많고 운영체제와 같은 관리 체계가 없는 것을 감안하면 나름 최선의 선택이라고 볼 수 있다.

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

위의 그림은 일반적으로 하드웨어 가속을 이용하는 소프트웨어에서 프레임버퍼 렌더링(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 에 의해 정확한 순서대로 작업이 처리되는 것이다.

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

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

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