태그 보관물: WAYLAND

[NEMOSHELL] Steam, XBMC, MS office, … 데모 공개!

오늘 촬영한 NEMOSHELL 데모 영상을 공개합니다. WAYLAND 윈도우 프로토콜을 지원하는 플랫폼을 개발한 보람을 드디어 느끼게 되는군요^^

첫 번째는 두 개의 키보드/마우스와 가상키보드/터치를 이용하여 두 명이 동시에 게임을 진행하는 영상입니다.

두 번째는 WINE 기반의 PlayOnLinux 로 동작시킨 MS 오피스를 사용하는 영상입니다.

세 번째는 Steam, XBMC 그리고 Chrome 을 동시에 사용하는 영상입니다.

다음 달에는 훨씬(!) 멋진 데모를 공개할 예정입니다. 기대하세요!

[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 그리고 디스플레이의 장단점을 파악해 보다 효과적인 컴포지팅 기술을 연구/개발해야 할 것 같다.

[NEMOSHELL] 안드로이드 지원!!!

NEMOSHELL 에서 드디어 안드로이드를 지원하기 시작했습니다! 예전에 간단히 에뮬레이팅 방식을 이용해 안드로이드를 시연한 적이 있지만, 저희가 원하는 것은 개별 앱을 띄우는 것이었는데, 드디어 크롬을 통해 가능하게 되었습니다. (인텔 & 구글에 감사^^) 아래에 간단히 앵그리버드를 사용하는 영상을 첨부하여 드리니 관심있으신 분들은 참고하시기 바랍니다.

크롬은 ozone-wayland 기반으로 동작하는 것이고, 안드로이드 앱은 archron 확장 기반으로 동작하고 있습니다.

[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 가 동작하는 방식에 대해 이해하는 것이 좀 더 쉬울 것 같다.

[스터디-공지] WAYLAND 기반 윈도우 매니저 동작 원리 이해 (3주차)

이번 스터디에서는 윈도우 매니저의 입력 장치 관련된 내용을 진행하려고 합니다. 스터디에서 다룰 구체적인 내용은 아래와 같습니다.

  • 윈도우 매니저 입력 : 기본 동작 과정 (포커스, …)
  • 그랩 인터페이스 : 윈도우 위치/크기 변경 과정
  • 데이터 인터페이스 : 드래그&드롭, 셀렉션(클립보드), …
  • 가상 키보드/한글 입력 동작 과정
  • 세션 관리 : TTY(VT), SEAT, SYSTEMD/LOGIND, …

그리고 세미나 때 사용할 자료를 첨부하였으니 관심있으신 분들은 참고하시기 바랍니다.
http://www.slideshare.net/nemoux/3-39954418

세부 모임 공지는 아래와 같습니다.

일시 : 2014년 11월 1일 (토요일) 오후 2시 ~ 4시
장소 : 성균관대학교 자연과학캠퍼스 제 1공학과 21515호 (1호선 성균관대역)
연락 : nemoux00@gmail.com (페이스북 그룹 : https://www.facebook.com/groups/uxcoding/)

[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 쪽에서도 이런 흐름에 잘 편승했으면 하는 바램을 가져봅니다.