월간 보관물: 2014 10월

[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, 스마트카 등 크기와 모양이 다양해지는 점을 감안해보면, 클라이언트 측에서 처리해야했던 레이아웃에 대한 부담을 서버가 적절히 가져갈 수 있을 것으로 기대된다.

Advertisements

[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/)

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

[WAYLAND] DRM 장치 관리 (LEGACY vs RENDER+CONTROL)

오늘은 DRM 장치 관리 방식에 대해 소개하려고 한다. 우선, GPU 가 제공 하는 기능은 크게 두 가지로 나뉜다. 우리가 일반적으로 하드웨어 가속이라고 표현하는 렌더링과 GPGPU 에 사용되는 기능과 PAGE_FLIP 이나 CRTC/PLANE 을 다루는 디스플레이 관련 기능이다. ARM 의 경우에는 이 두 가지가 서로 다른 장치로 분리되어있지만, 데스크탑의 경우는 보통 하나의 그래픽 카드가 두 가지 기능 모두를 제공한다. 그래서 현재 DRM 은 이 두 가지 기능을 하나의 DRM 장치 파일에서 제공하게 되었고, 이로 인해 여러 가지 문제가 발생하고 있다. 이를 해결하기 위해 나온 것이 바로 하드웨어 가속 관련 기능을 담당하는 장치 파일과 디스플레이 관련 기능을 담당하는 장치 파일로 나누는 것이다. 다행히 기존의 DRM 아키텍처에 대한 큰 수정없이 작업이 진행 중이고, 앞으로는 다양한 어플리케이션이 편리하게 GPU 를 사용할 수 있게 될 것이다.

legacy

위의 그림은 전통적인 방식의 DRM 장치 접근 과정이다. 우선, GPU 를 사용하기 위해서는 윈도우 매니저가 마스터가 되어 DRM 을 관리해야 한다. 마스터는 말그대로 DRM 을 통해 GPU 의 모든 기능을 관리할 수 있는 권한이라고 보면 된다. 그래서 하나의 마스터만이 존재할 수 있고, 마스터 권한을 얻기 위해서는 ADMIN 권한이 필요하다. 그리고 클라이언트는 윈도우 매니저와 마찬가지로 LEGACY NODE(card0) 를 사용하지만, 매직 코드를 할당받아서 이를 마스터인 윈도우 매니저에게 인증을 받아야만 DRM 을 통해 GPU 의 자원을 사용할 수 있게 된다. 즉, 마스터인 윈도우 매니저가 없으면 어떤 어플리케이션도 GPU 를 사용할 수 없다는 얘기다. 그렇다면 윈도우 매니저가 없는 서버 환경에서는 GPGPU 를 위해 어떻게 GPU 를 사용할까? 강제로 누군가가 마스터가 되어 GPGPU 를 사용하고자 하는 어플리케이션을 인증해주던가 뭔가 다른 방법을 찾아야 할 것이다. 그래서 이를 해결하기 위해 나온 것이 하드웨어 가속 관련 기능과 디스플레이 관련 기능을 서로 다른 장치 파일로 나누는 것이다.

우선 왜 이런 접근 방식을 사용하는지에 대해 간단히 생각해보자. 기본 컨셉은 이렇다. 하드웨어 가속 기능은 공유가 가능하기 때문에 굳이 루트 권한이 없더라도 누구든지 적당히(!) 쓸 수 있게 하겠다는 것이다. 이유는 여러 어플리케이션이 동시에 하드웨어 가속을 이용한다고 하더라도 경쟁에 의한 오버헤드로 결과가 조금 더 느리게 나올 뿐이지 결과 자체에는 영향을 주지 않기 때문이다. 하지만 디스플레이 관련 기능은 공유가 불가능하기 때문에 좀 더 신경써서 관리해야 한다. (두 개의 어플리케이션이 동시에 디스플레이를 갱신한다고 생각해보자. 화면이 왔다갔다 난리가 날 것이다.)

render+control

위의 그림을 보면 알겠지만 기존보다 훨씬 단순해졌다. 우선, 하나의 장치 파일(LEGACY NODE)로 관리되던 DRM 이 하드웨어 가속 관련된 기능을 제공하는 RENDER NODE 와 디스플레이 관련된 기능을 제공하는 CONTROL(or MODESET) NODE 로 나누어졌다. 그래서 디스플레이를 관리하는 윈도우 매니저는 CONTROL NODE 와 RENDER NODE 를 동시에 사용하고, 일반적인 윈도우 클라이언트와 GPGPU 를 사용하는 어플리케이션은 RENDER NODE 만을 사용하면 된다. 윈도우 클라이언트는 기본적인 렌더링 기능과 PRIME/DMA-BUF 관련된 기능까지 사용할 수 있기 때문에 필요한 것을 하드웨어 가속을 이용하여 렌더링한 다음, PRIME 기능을 이용하여 결과물을 윈도우 매니저에 전달할 수 있다. 또한 윈도우 매니저가 없더라도 RENDER NODE 를 사용하는데는 아무런 제약 사항이 없기 때문에 GPGPU 를 사용하는 것이 한결 수월해졌다.

그리고 이 외에도 기대되는 기능이 몇 가지가 있는데, 그 중에 하나는 하나의 GPU 에서 여러 개의 CONTROL NODE 를 동시에 지원하는 것이다. 이게 뭐냐하면 일반적으로 GPU 는 두 개 이상의 디스플레이를 지원한다. 하지만 지금까지는 하나의 마스터만 존재할 수 있기 때문에 하나의 윈도우 매니저가 모든 디스플레이를 관리해야 했다. 이를 해결하기 위해 CONTROL NODE 를 단순히 GPU 별로 생성하지 말고, GPU 의 CRTC 별로도 생성할 수 있게 하자는 얘기가 나오고 있다. 이렇게 되면 두 개의 윈도우 매니저를 띄워서 하나의 GPU 에 연결된 두 개의 CRTC 를 각자 관리할 수 있게 되는 것이다. 사실, 꼭 필요한 기능은 아니어서 작업이 진행되고 있는 것 같진 않은데, 어찌됐던 이렇게까지 DRM 을 유연하게 사용할 수 있는 방법에 대한 얘기가 오고가고 있다는 것이다.

마지막으로 해당 기능은 올해 초에 리눅스 커널에 정식으로 반영이 되었다. 하지만, 아직은 대부분의 소프트웨어가 기존의 방식을 그대로 사용하고 있기 때문에 LEGACY NODE 와 RENDER/CONTROL NODE 를 동시에 지원하고 있다.