GPU 서브시스템 (DRM/KMS)
Linux GPU 서브시스템(DRM/KMS)을 디스플레이 파이프라인(Pipeline)과 연산 가속 경로를 함께 보는 관점에서 심층 분석합니다. DRM core와 KMS 객체 모델(CRTC/plane/encoder/connector), GEM/TTM 메모리 관리(Memory Management)자, DMA-BUF 기반 장치 간 버퍼(Buffer) 공유, atomic modesetting과 vblank 동기화, fence 기반 GPU 작업 순서 제어, 전원·클럭·열 관리(Thermal Management), userspace(Mesa/Wayland)와의 ioctl 계약, debugfs/tracepoint로 프레임 드롭과 hang을 진단하는 방법까지 GPU 드라이버 개발 핵심을 다룹니다.
핵심 요약
- 노드 분리 — 화면 제어는 primary node, 비특권 렌더링은 render node, 비그래픽 연산은 accel node가 담당합니다.
- 상태 모델 — KMS는 CRTC/plane/connector를 atomic state로 묶어 한 번에 검증하고 적용합니다.
- 버퍼 수명주기 — BO 생성, 핸들 배정, mmap, DMA-BUF 공유, fence 동기화가 한 세트로 움직입니다.
- 메모리 계층 — 단순 SoC GPU는 GEM shmem, 전용 VRAM GPU는 TTM/VRAM helper/자체 GPUVM을 주로 사용합니다.
- 복구 설계 — hang 감지, fence 타임아웃, 엔진 리셋, 전원 재기동이 운영 안정성을 좌우합니다.
단계별 이해
- 어느 노드를 여는지부터 구분
compositor는 primary node에서 KMS를 제어하고, 일반 앱은 render node에서 커맨드 제출을 시작합니다. - 버퍼를 어떤 백엔드에 둘지 결정
scanout 전용이면 dumb buffer, 일반 렌더링이면 드라이버 전용 BO, 장치 간 공유면 DMA-BUF까지 함께 봅니다. - atomic 상태를 조립
plane/CRTC/connector 속성을 새 상태 객체에 채운 뒤atomic_check로 하드웨어 제약을 검증합니다. - 렌더링과 표시를 동기화
dma_resv,syncobj,IN_FENCE_FD/OUT_FENCE_PTR로 렌더 완료 시점을 맞춥니다. - 운영 중 고장 경로를 준비
GPU hang, hotplug, runtime suspend, reset recovery를 debugfs·tracepoint·drm_sched 타임아웃으로 추적합니다.
세부 문서 안내
GPU 서브시스템 문서는 주제별로 3개의 세부 문서로 나뉘어 있습니다. 각 문서에서 해당 영역을 심층적으로 다룹니다.
| 문서 | 주요 내용 | 핵심 키워드 |
|---|---|---|
| DRM 코어 및 디스플레이 (KMS) | DRM 코어 아키텍처, 디바이스 노드, KMS 객체 모델, atomic modesetting, DRM properties, VRR, format modifier, DRM bridge/panel, 디스플레이 프로토콜, HDCP, DRM lease, fbdev 에뮬레이션, 드라이버 골격, 주요 DRM 드라이버, ioctl 요약 | DRM, KMS, CRTC, encoder, connector, plane, atomic, VRR, HDCP |
| GPU 메모리 관리 및 스케줄러 | GEM 메모리 관리, TTM, DMA-BUF 버퍼 공유, GPU 커맨드 서브미션, drm_sched 스케줄러, GPUVM 가상 메모리, GPU 전원 관리, GPU 리셋 및 복구, 커널 설정, DRM 디버깅 | GEM, TTM, DMA-BUF, dma_fence, drm_sched, GPUVM, GPU PM, GPU reset |
| GPU 컴퓨팅 (GPGPU) | GPU 컴퓨트 개요, CUDA/NVIDIA 아키텍처, OpenCL 크로스 플랫폼 컴퓨트, Vulkan Compute 파이프라인, ROCm/HIP AMD 컴퓨트, Intel oneAPI/Level Zero | GPGPU, CUDA, OpenCL, Vulkan Compute, ROCm, HIP, oneAPI |
DRM 서브시스템 구조 개요
DRM은 Linux 커널의 GPU 접근을 관리하는 서브시스템입니다. 원래 3D 그래픽 가속을 위해 도입되었으나, 현재는 디스플레이 출력(KMS), GPU 메모리 관리(GEM/TTM), GPU 작업 스케줄링까지 포괄하는 핵심 프레임워크로 발전했습니다.
| 구성 요소 | 역할 | 상세 문서 |
|---|---|---|
| DRM Core | 드라이버 등록(Driver Registration), ioctl 디스패치(Dispatch), 파일 오퍼레이션 | DRM 코어 및 디스플레이 |
| KMS (Kernel Mode Setting) | 디스플레이 모드 설정, CRTC/Encoder/Connector/Plane | KMS 섹션 |
| GEM / TTM | GPU 메모리 버퍼 할당/관리, VRAM/시스템 메모리 간 이동 | GEM 섹션 |
| DMA-BUF | 디바이스 간 버퍼 공유 (GPU↔카메라↔디스플레이) | DMA-BUF 섹션 |
| GPU Scheduler | GPU 작업 큐(Workqueue) 관리, 우선순위(Priority), 타임아웃 처리 | GPU 스케줄러 섹션 |
| GPU 컴퓨트 | CUDA, OpenCL, Vulkan Compute, ROCm/HIP, oneAPI | GPU 컴퓨팅 |
디바이스 노드와 권한 모델 요약
현대 DRM UAPI는 GPU 하나를 단일 문자 디바이스로만 노출하지 않습니다. 같은 하드웨어라도 화면 제어, 비특권 렌더링, 비그래픽 연산을 서로 다른 노드로 나누어 권한 경계와 사용자 공간(User Space) 스택을 분리합니다.
| 노드 종류 | 대표 경로 | 주 용도 |
|---|---|---|
| Primary | /dev/dri/card0 |
KMS modeset, connector/plane/lease 제어 |
| Render | /dev/dri/renderD128 |
OpenGL/Vulkan/VA-API/OpenCL 등 비특권 렌더링과 GPGPU |
| Accel | /dev/accel/accel0 |
NPU/AI/신호 처리 같은 비그래픽 compute |
디바이스 노드의 상세 구조와 권한 모델, drm_file 구조체, DRM master 개념 등은
DRM 코어 및 디스플레이 — 디바이스 노드와 권한 모델 섹션을 참고하세요.
DRM 아키텍처
각 계층의 상세 내용은 다음 문서에서 확인할 수 있습니다:
- KMS (Mode Setting) → DRM 코어 및 디스플레이 — KMS
- GEM / TTM / DMA-BUF → GPU 메모리 관리 및 스케줄러
- GPU Scheduler → GPU 스케줄러 (drm_sched)
- GPU 컴퓨트 (GPGPU) → GPU 컴퓨팅
참고 사항
drivers/gpu/drm/— DRM 코어 + 모든 GPU 드라이버drivers/accel/— compute accelerator 드라이버include/drm/— DRM 헤더 파일include/uapi/drm/— 유저 공간 API (ioctl, 구조체)drivers/dma-buf/— DMA-BUF 프레임워크Documentation/gpu/— 커널 공식 GPU 문서Documentation/accel/— 커널 공식 accelerator 문서
- DRM UAPI — primary/render node, client capability, dumb buffer 제약
- DRM KMS — atomic modesetting, plane/connector/CRTC helper 계약
- DRM Memory Management — GEM, PRIME, VRAM helper, TTM, GPUVA
- Compute Accelerators — accel 디바이스 노드와 드라이버 모델
- GPU Driver Documentation — 드라이버별 하위 문서 색인
관련 문서
이 주제와 관련된 다른 문서를 더 깊이 이해하고 싶다면 다음을 참고하세요.