1. DRM
DRM (Direct Rendering Manager)은 Linux Kernel에서 디스플레이 및 그래픽 장치를 관리하는 서브 시스템으로 유저 공간 애플리케이션과 GPU/디스플레이 하드웨어 사이의 인터페이스 역할을 합니다.
Linux Kernel에는 이미 그래픽 어댑터의 프레임버퍼를 관리하는 데 사용되는 fbdev 드라이버 및 API가 있었지만 최신 3D 가속 GPU 기반 비디오 하드웨어의 요구 사항을 처리하는 데는 어려움이 있었습니다.
이러한 장치는 일반적으로 자체 메모리(VRAM 및 CMA)에서 명령 대기열을 설정하고 관리하여 GPU에 명령을 전송해야 하며 해당 메모리 내의 버퍼와 여유 공간을 관리해야 합니다.
처음에는 사용자 공간 프로그램(X Server)이 이러한 리소스를 직접 관리했지만 일반적으로 자신만이 액세스할 수 있는 것처럼 작동했습니다. 두 개 이상의 프로그램이 동시에 같은 하드웨어를 제어하고 각기 다른 방식으로 리소스를 설정하려고 하면 대부분의 상황에서 문제가 발생하였습니다.
Direct Rendering Manager는 여러 프로그램이 비디오 하드웨어 리소스를 공동으로 사용할 수 있도록 만들어졌습니다. DRM은 GPU에 독점적으로 접근하며 명령 대기열, 메모리 및 기타 하드웨어 리소스를 초기화하고 유지 관리합니다.
GPU를 사용하려는 프로그램은 DRM에 요청을 보내면 DRM은 중재자 역할을 하며 충돌 가능성을 방지합니다.
위의 주된 이유로 인하여 DRM 형태로 전환하여 Linux Kernel이 발전하였으며 모드 설정, 메모리 공유 개체 및 동기화와 같이 이전에 사용자 공간에서 처리해야 했던 더 많은 기능을 포함하도록 확장되어 왔습니다.
- 사용자 공간으로부터의 디스플레이 제어 요청 처리
- 프레임버퍼 관리
- 페이지 플립(Page Flip), VBlank 이벤트 등 스케줄링
- 멀티 디스플레이 환경 지원
- GPU 메모리 관리 및 버퍼 공유 (GEM, DMA-BUF)
주 목적은 렌더링 버퍼 관리, 화면 출력, VBlank 이벤트, atomic state 변경, 그리고 플러그 앤 플레이 디스플레이 제어입니다.
DRM 구성 요소 요약
구성 요소
설명
| DRM Core | /drivers/gpu/drm/drm*.c 등에서 구현. 공통 로직을 담당 |
| DRM (Platform) Driver | 각 하드웨어에 특화된 드라이버 (예: i915, amdgpu, rockchip, exynos 등) |
| DRM Helper | 공통된 코드 재사용을 위한 helper 함수 (예: drm_gem_cma_helper) |
| DRM KMS (Kernel Mode Setting) | 해상도, 모니터 제어, 플립 등을 위한 인터페이스 |
2. DRM Software Archtecture
DRM은 Kernel Space에 존재하므로 유저 공간 프로그램은 Kernel의 System Call을 통해 DRM에 필요한 서비스를 요청해야 합니다.
DRM에서 감지한 각 GPU는 DRM 장치로 인식되며 디바이스 노드(/dev/dri/cardX)가 생성되어 이와 상호 작용 합니다. GPU와 통신하려는 유저 공간 프로그램은 디바이스 장치 파일을 열어 ioctl 호출을 사용하여 DRM과 통신해야 합니다.
libdrm은 Kernel의 DRM드라이버를 사용하기 위한 user space 라이브러리(wrapper) 입니다. libdrm을 사용하면 커널 인터페이스가 사용자 공간에 직접 노출되는 것을 피할 수 있을 뿐만 아니라 프로그램 간에 코드를 재사용하고 공유할 수 있는 이점이 있습니다.
위의 그림과 같이 DRM은 크게 두 부분으로 구성됩니다. 일반적인 Kernel의 DRM Core 와 각 유형의 지원 하드웨어에 대한 DRM (Platform) Driver 입니다. DRM Core는 다양한 DRM Driver가 등록할 수 있는 기본 프레임워크를 제공하고 사용자 공간에 공통적인 하드웨어 독립적인 기능을 갖춘 최소한의 ioctl 기능을 제공합니다.
반면 DRM 드라이버는 지원하는 GPU 유형에 따라 특정 API의 하드웨어 종속 부분을 구현합니다. DRM 코어에서 다루지 않는 나머지 ioctl 구현을 제공해야 하지만 API를 확장하여 해당 하드웨어에서만 사용할 수 있는 추가 기능을 갖춘 추가 ioctl을 제공할 수도 있습니다.
특정 DRM 드라이버가 향상된 API를 제공하는 경우 사용자 공간 libdrm도 추가 ioctl과 인터페이스 하기 위해 사용자 공간에서 사용할 수 있는 추가 라이브러리 libdrm-specific_driver 형태로 확장됩니다.
DRM Core는 사용자 공간 애플리케이션에 여러 인터페이스를 내보내며, 일반적으로 해당 래퍼 함수를 통해 사용됩니다. 또한 드라이버는 ioctls 및 sysfs 파일을 통해 사용자 공간 드라이버 및 장치 인식 애플리케이션에서 사용할 수 있도록 장치별 인터페이스를 내보냅니다.
외부 인터페이스에는 메모리 매핑, 컨텍스트 관리, DMA 작업, AGP 관리, vblank 제어, fence 관리, 메모리 관리 및 출력 관리가 포함됩니다.
3. Kernel Mode Setting (KMS)
리눅스 그래픽 스택에서 KMS (Kernel Mode Setting) 는 디스플레이 장치의 출력 모드를 설정하고 제어하는 핵심 기능입니다.
여기서 모드(mode) 란 해상도(Resolution), 컬러 포맷(Color Format), 주사율(Refresh Rate) 등 디스플레이가 출력할 수 있는 상태를 의미합니다.
즉, KMS는 GPU 장치가 연결된 디스플레이가 지원하는 값 범위 내에서 올바른 모드를 선택하고, 이를 하드웨어 레벨에서 설정하는 역할을 합니다.
과거에는 X.Org Server 또는 특정 그래픽 애플리케이션이 직접 하드웨어에 접근하여 모드를 설정했습니다.
이 방식에는 두 가지 문제가 있었습니다:
- 보안 문제
- 사용자 공간 프로그램이 직접 하드웨어를 제어하기 위해 루트 권한으로 실행되어야 했습니다.
- 이는 안정성과 보안 측면에서 위험 요소가 많았습니다.
- 일관성 부족
- 여러 애플리케이션이 각각 하드웨어를 제어하려고 하면 충돌이나 비정상적인 동작이 발생할 수 있었습니다.
이러한 문제를 해결하기 위해 커널이 모드 설정을 담당(Kernel Mode Setting) 하도록 변경되었고,
사용자 공간에서는 안전하게 DRM(Direct Rendering Manager) 인터페이스를 통해 제어 명령을 전달하는 구조로 발전했습니다.
KMS의 주요 구성 요소
KMS는 단일 하드웨어 블록이 아니라, 디스플레이 파이프라인을 구성하는 여러 요소의 조합으로 동작합니다. DRM 드라이버는 일반적으로 다음 세 가지 주요 객체를 관리합니다:
- CRTC
- 프레임 버퍼 메모리에서 픽셀 데이터를 읽어와 화면에 출력하는 역할
- 스캔아웃(scanout) 동작을 담당하며, vsync와 같은 타이밍 제어를 관리
- Encoder
- CRTC에서 출력된 데이터를 특정 디스플레이 신호 형식(HDMI, DisplayPort, DVI 등)으로 변환
- 하나의 CRTC는 여러 Encoder와 연결될 수 있음
- Connector
- 실제 물리적인 디스플레이 장치(모니터, 패널 등)에 연결되는 지점
- EDID(Extended Display Identification Data)를 읽어 디스플레이가 지원하는 모드를 파악
이 세 가지 객체를 조합하여 커널은 '어떤 프레임 버퍼를 어떤 방식으로 어떤 출력 장치에 보여줄 것인가'를 결정하게 됩니다.
이번 글에서는 DRM과 KMS의 기본 개념과 필요성, 그리고 주요 객체(CRTC/Encoder/Connector)의 역할을 살펴보았습니다.
다음 글에서는 이 추상화 구조가 실제 SoC에서 어떻게 매핑 되는지, 그리고 Simple Pipe와 전통적인 구현 방식이 어떻게 다른지 구체적으로 다루어 보겠습니다.
'System Programming > Linux Device Driver' 카테고리의 다른 글
| 입력 디바이스 드라이버(Input Device Driver) (0) | 2016.06.22 |
|---|