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 드라이버 개발 핵심을 다룹니다.

전제 조건: 디바이스 드라이버DMA 문서를 먼저 읽으세요. 멀티미디어/가속기 경로는 대용량 버퍼 이동과 동기화가 성능의 핵심이므로, 메모리 경로와 큐 모델을 먼저 파악해야 합니다.
일상 비유: GPU 서브시스템은 공유 작업장을 예약제로 운영하는 설계 사무실과 비슷합니다. 여러 프로그램이 같은 가속기를 쓰므로 GEM/TTM 메모리, dma-buf 공유, DRM 스케줄러가 작업 공간과 순서를 조율해야 합니다.

핵심 요약

  • 노드 분리 — 화면 제어는 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 타임아웃, 엔진 리셋, 전원 재기동이 운영 안정성을 좌우합니다.

단계별 이해

  1. 어느 노드를 여는지부터 구분
    compositor는 primary node에서 KMS를 제어하고, 일반 앱은 render node에서 커맨드 제출을 시작합니다.
  2. 버퍼를 어떤 백엔드에 둘지 결정
    scanout 전용이면 dumb buffer, 일반 렌더링이면 드라이버 전용 BO, 장치 간 공유면 DMA-BUF까지 함께 봅니다.
  3. atomic 상태를 조립
    plane/CRTC/connector 속성을 새 상태 객체에 채운 뒤 atomic_check로 하드웨어 제약을 검증합니다.
  4. 렌더링과 표시를 동기화
    dma_resv, syncobj, IN_FENCE_FD/OUT_FENCE_PTR로 렌더 완료 시점을 맞춥니다.
  5. 운영 중 고장 경로를 준비
    GPU hang, hotplug, runtime suspend, reset recovery를 debugfs·tracepoint·drm_sched 타임아웃으로 추적합니다.
관련 표준: DisplayPort 2.1 (디스플레이 인터페이스), HDMI 2.1 (멀티미디어 인터페이스), E-EDID (디스플레이 정보 교환), PCIe 6.0 (GPU 인터커넥트) — DRM/KMS 서브시스템이 구현하는 디스플레이 및 GPU 규격입니다. 종합 목록은 참고자료 — 표준 & 규격 섹션을 참고하세요.

세부 문서 안내

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 메모리 관리 및 스케줄러(Scheduler) GEM 메모리 관리, TTM, DMA-BUF 버퍼 공유, GPU 커맨드 서브미션, drm_sched 스케줄러, GPUVM 가상 메모리(Virtual Memory), GPU 전원 관리(Power Management), GPU 리셋 및 복구, 커널 설정, DRM 디버깅(Debugging) 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 구조체(Struct), DRM master 개념 등은 DRM 코어 및 디스플레이 — 디바이스 노드와 권한 모델 섹션을 참고하세요.

DRM 아키텍처

User Space Mesa / Vulkan libdrm Wayland / X11 GPGPU (OpenCL) V4L2 / GBM ioctl / mmap DRM Core /dev/dri/card0 (Primary) & /dev/dri/renderD128 (Render) KMS (Mode Setting) CRTC · Encoder · Connector · Plane GEM / TTM 메모리 관리 GPU Scheduler Job Queue · Fence · Timeout DMA-BUF DRM Driver (i915 / amdgpu / nouveau / panfrost / virtio-gpu ...) 드라이버별 HW 초기화, 커맨드 서브미션, IRQ, 전원 관리 MMIO / DMA GPU Hardware

각 계층의 상세 내용은 다음 문서에서 확인할 수 있습니다:

DRM Accel 서브시스템 (비그래픽 가속기)

전통적으로 DRM(Direct Rendering Manager)은 그래픽 출력을 담당하는 GPU만을 관리했으나, 현대 SoC와 x86 플랫폼에는 그래픽 파이프라인 없이 연산만 수행하는 가속기(Accelerator)가 늘어나면서 커널 6.2에서 drivers/accel/ 트리와 /dev/accel/accel* 노드가 도입되었습니다. DRM의 버퍼·fence·스케줄러 인프라를 재사용하되, 디스플레이와 관련된 KMS 경로를 완전히 제거한 경량 경로입니다.

분리 이유: NPU(Neural Processing Unit)와 AI 가속기는 화면 출력이 없으므로 connector/CRTC/plane을 가질 수 없고, /dev/dri/cardN의 master 권한 모델도 맞지 않습니다. Accel 노드는 render node와 유사한 비특권 접근을 기본으로 삼아 사용자 공간(User Space) 컨테이너(Container)·세션 관리자와 잘 어울립니다.

커널 트리에 상주하는 주요 Accel 드라이버

드라이버하드웨어머지 커널특징
drivers/accel/habanalabs Intel(구 Habana) Gaudi / Gaudi2 / Gaudi3 5.18 이전(이전은 misc) 데이터센터 AI 학습 가속기. Accel 서브시스템 1호 드라이버
drivers/accel/ivpu Intel Core Ultra 내장 NPU (Meteor Lake 이후) 6.3 저전력 클라이언트 NPU. MTL/ARL/LNL/PTL 순차 확장
drivers/accel/qaic Qualcomm Cloud AI 100 6.5 AI Core(AIC) PCIe 카드. 데이터센터 추론 가속
drivers/accel/amdxdna AMD Ryzen AI NPU (XDNA/Phoenix 이후) 6.14 2025년 3월 머지. Ryzen 7040/8040 Phoenix·Hawk·Strix
drivers/accel/rocket Rockchip RK3588 NPU (RKNN) 6.15 (리버스 엔지니어링) 2025년 5월 머지. 벤더 의존 없는 오픈 드라이버

각 Accel 드라이버의 상세 아키텍처, 컴파일러 스택, DMA-BUF 연계는 NPU 문서에서 다룹니다. 최근 몇 년간 Accel 드라이버가 꾸준히 추가되면서, NPU 하드웨어 다변화가 본격화되고 있습니다. 다만 개별 드라이버의 정확한 공개 시점과 머지 여부는 메인라인 릴리스 노트를 다시 확인하는 편이 안전합니다.

Accel UAPI와 일반 DRM UAPI의 공통·차이점

항목DRM (GPU)Accel (NPU 등)
노드/dev/dri/card*, /dev/dri/renderD*/dev/accel/accel*
KMS 객체CRTC/plane/encoder/connector 있음없음 (디스플레이 경로 제거)
Master/권한primary는 capability 기반 master 필요기본이 비특권 render 모델
BO(Buffer Object)GEM shmem / TTM / VRAM helperGEM shmem 또는 드라이버 고유 BO
스케줄러drm_sched 또는 펌웨어(Firmware) 스케줄러(GuC 등)드라이버 자체 워크 큐 또는 drm_sched 재사용
공유 UAPIDMA-BUF, dma_fence, sync_file, syncobj(Sync Object)

Rust GPU 드라이버 생태계

2025년은 Rust 언어가 리눅스 커널 GPU 서브시스템에 본격 도입된 분기점입니다. 메모리 안전 언어로 GPU 드라이버를 작성하려는 흐름은 Apple Silicon에서 시작되어, NVIDIA GSP 드라이버(Nova)가 메인라인에 합류하면서 가속됐습니다. 기존 C 기반 DRM 인프라는 그대로 유지하면서, 새 드라이버가 DRM 바인딩을 Rust로 감싸는 방식으로 확장됩니다.

Nova — NVIDIA GSP 기반 Rust DRM 드라이버 (커널 6.15+)

Nova는 NVIDIA GeForce RTX 20(Turing) 이후 세대의 GPU System Processor(GSP) 기반 GPU를 위한 새 드라이버로, Red Hat의 Danilo Krummrich가 주도하여 2025년 5월 커널 6.15에 drivers/gpu/drm/nova/가 머지됐습니다. 기존 Nouveau를 대체하는 후속 드라이버를 목표로 하며, 현재는 초기 코어 컴포넌트와 프로젝트 문서만 머지된 실험 단계입니다. 2025년 하반기에는 NVIDIA 소속 엔지니어가 공동 메인테이너로 합류했습니다.

Nova 설계 원칙:
  • GSP 우선 — GPU 내부 RISC-V 기반 마이크로컨트롤러에 펌웨어(Firmware)로 초기화·스케줄링을 위임하므로, 드라이버는 주로 RPC 래퍼가 됩니다.
  • Rust 추상화kernel::drm 크레이트로 device/file/gem 래퍼를 제공하며, unsafe 경계는 최소화합니다.
  • Nouveau와 공존 — 당분간 Nouveau가 실사용 드라이버로 남고, Nova는 대체 준비가 완료될 때까지 개발 브랜치로 병행합니다.
  • 문서 경로Documentation/gpu/nova/https://docs.kernel.org/gpu/nova/에 공식 설명이 존재합니다.

Asahi AGX — Apple Silicon GPU 드라이버

Apple M1/M2/M3/M4 시리즈의 내장 GPU인 AGX는 Asahi Linux 프로젝트에서 Rust로 작성한 드라이버로 리눅스에서 구동됩니다. AGX 드라이버는 DRM 서브시스템용 Rust 바인딩을 실제 production-level로 처음 도입한 사례로, Mesa의 Honeykrisp(Vulkan) / Gallium AGX(OpenGL 4.6, ES 3.2) 드라이버와 짝을 이룹니다. 현재 업스트림 머지 목표로 AsahiLinux/linuxgpu/rust-wip 브랜치에서 재작성이 진행 중입니다.

Rust DRM 바인딩의 공통 기반

두 드라이버는 공통으로 다음 Rust 추상화에 의존합니다:

이들 크레이트는 기존 C API를 그대로 호출하므로 ABI 변경 없이 공존하며, unsafe 블록은 FFI 경계에만 남겨 안전성을 확보합니다.

drm_panic — 커널 패닉(Kernel Panic) 화면 인프라

드라이버가 Wayland·compositor 없이 DRM 프레임버퍼만 보유한 상태에서도 커널 패닉(Kernel Panic) 시 사용자에게 읽을 수 있는 메시지를 남기는 구조가 2024년 커널 6.10에서 추가되었습니다. fbcon(Frame Buffer Console)이 없거나 VT가 꺼진 환경에서도 화면에 패닉 내용을 그려주며, Fedora와 Arch 계열처럼 이를 적극 도입한 배포판이 있습니다. 다만 2026년 4월 기준으로 배포판별 기본 활성 범위와 사용자 노출 방식은 릴리스별로 다를 수 있으므로 해당 배포판 문서를 함께 확인하는 편이 안전합니다.

동작 원리

패닉 시 드라이버가 등록한 drm_panic 콜백(Callback)이 호출되어, fence·mutex 없이 MMIO만으로 프레임버퍼를 직접 갱신합니다. 따라서 패닉 루틴은 일반 드라이버 경로와 완전히 분리된 lock-free·interrupt-safe 구현이어야 합니다.

/* include/drm/drm_panic.h */
struct drm_panic_scanout {
    void        *vaddr;      /* 직접 접근 가능한 프레임버퍼 포인터 */
    unsigned int pitch;      /* 라인 당 바이트 */
    unsigned int width, height;
    u32          format;     /* DRM_FORMAT_* */
};

struct drm_plane_helper_funcs {
    ...
    int (*get_scanout_buffer)(struct drm_plane *, struct drm_panic_scanout *);
    void (*panic_flush)(struct drm_plane *);
};

지원 드라이버 현황 (2026년 기준)

드라이버지원 시작 커널비고
simpledrm, mgag200, ast6.10최초 지원. 간단한 라이너 프레임버퍼 드라이버
i915, xe6.12~6.14Intel 클라이언트 GPU 지원. Panic 시 Intel CSE와 협조
amdgpu6.14DCN 기반 디스플레이에서 panic 플러시(Flush) 지원
nouveau진행 중Jocelyn Falempe가 작업 중
주의: 드라이버가 get_scanout_buffer를 구현하지 않으면 패닉 화면이 뜨지 않고 이전 화면이 얼어붙은 상태로 남습니다. 또한 일부 AMD GPU에서는 DCN 상태에 따라 panic 화면이 깨져 보일 수 있는 이슈가 보고되어 지속 개선 중입니다.

2025년부터 2026년 상반기까지 GPU·가속기 서브시스템에 머지된 주요 기능을 커널 버전별로 요약합니다. 배포판 선택·드라이버 포팅 계획에 참고할 수 있습니다.

관련 연혁: GPU / DRM 변경 이력

3대 하이라이트

  1. Rust의 본격 도입 — Nova(NVIDIA)·Asahi AGX(Apple)·Tyr(Arm) 등 Rust 기반 DRM 드라이버가 잇따라 제안되고, kernel::drm 바인딩이 안정화 경로에 들어섰습니다.
  2. 가속기 생태계 확장 — AMDXDNA(Ryzen AI)·Rockchip Rocket(RK3588)에 이어, 2026년에도 최소 2종의 새 NPU 드라이버가 예정되어 Accel 서브시스템이 GPU 못지 않은 규모로 성장 중입니다.
  3. 색 파이프라인·동기화 현대화 — KMS Color Pipeline API(HDR), linux_drm_syncobj_v1(Wayland explicit sync), DMEM cgroup(VRAM 제한), Fair DRM Scheduler 등으로 게임·HDR·컨테이너 워크로드에서의 체감 품질이 크게 개선됐습니다.

커널 버전별 주요 변경사항 (2025~2026)

커널 버전출시 시기주요 변경사항
6.15 2025년 3~4월
  • Intel Xe SVM — Shared Virtual Memory 메인라인 지원. CPU-GPU 메모리 공유 성능 향상
  • NOVA 초기 코드 — Rust 기반 NVIDIA 오픈소스 커널 드라이버 초기 코드 머지
  • Intel Xe EU Stall Sampling — EU 스톨 샘플링 지원
  • appletbdrm — Apple Touch Bar 지원 (M1/M2 MacBook)
  • survivability mode — Intel Xe GPU 생존 모드 도입
  • Intel Battlemage/Arc GPU 온도/hwmon 지원
6.16 2025년 5~6월
  • NVIDIA Blackwell/Hopper Nouveau — 초기 GSP 펌웨어 기반 지원
  • Asahi UAPI 헤더 — Apple Silicon 드라이버 UAPI 헤더 커널 트리 추가
  • Rust 추상화 확장 — nova, Asahi 등 Rust 기반 드라이버를 위한 DRM 추상화 추가
  • Intel Xe Fan Speed 지원, Panther Lake Xe3 준비
6.17 2025년 8~9월
  • Intel Xe DP MST DSC — DisplayPort Multi-Stream Transport fractional link BPP 지원
  • Panel Replay + Adaptive Sync — 동시 지원
  • Double-buffered LUT — Panther Lake용 레지스터 지원
  • Flip-queue 준비 — 플립 큐 지원 준비
  • xe_migrate_access_memory 수정 — 메모리 접근 수정
  • amdgpu VRAM 예약 수정, SRIOV-PF VF LMEM BAR 크기 설정
7.1 2026년 4월
  • Intel Xe3 대규모 준비 — Xe3 (Crescent Island, Nova Lake), Xe3P 지원
  • SR-IOV 변경 — Xe SR-IOV 개선
  • TLB 무효화 — context 기반 TLB 무효화
  • Panther Lake / Wildcat Lake PCI 디바이스 ID 추가

참고자료

커널 소스 참고 경로:
  • 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 문서
우선적으로 볼 1차 문서:

이 주제와 관련된 다른 문서를 더 깊이 이해하고 싶다면 다음을 참고하세요.