[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 를 동시에 지원하고 있다.

Advertisements

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

%s에 연결하는 중