다이렉트 렌더링 매니저

Direct Rendering Manager
디지털 권리 관리와 혼동하지 말 것.
다이렉트 렌더링 매니저
원저작자kernel.org 및 freedesktop.org
개발자kernel.org 및 freedesktop.org
기입처C
유형
면허증.
웹 사이트dri.freedesktop.org/wiki/DRM

Direct Rendering Manager(DRM; 다이렉트 렌더링 매니저)는 Linux 커널의 서브시스템으로, 최신 비디오 카드의 GPU와의 인터페이스를 담당합니다.DRM은 사용자 공간 프로그램이 GPU에 명령어와 데이터를 전송하고 디스플레이 모드 설정 등의 작업을 수행하기 위해 사용할 수 있는 API를 제공합니다.DRM은 처음에 X Server Direct Rendering [1]Infrastructure의 커널 공간 컴포넌트로 개발되었지만, 그 이후 Wayland와 같은 다른 그래픽 스택에서 사용되고 있습니다.

사용자 공간 프로그램은 DRM API를 사용하여 GPU에 하드웨어 가속 3D 렌더링 및 비디오 디코딩 및 GPGPU 컴퓨팅을 명령할 수 있습니다.

개요

Linux 커널에는 이미 fbdev라는 API가 있어 그래픽 [2]어댑터의 프레임 버퍼를 관리하기 위해 사용되었지만 최신 3D 가속 GPU 기반 비디오 하드웨어의 요구를 처리하기 위해 사용할 수 없었습니다.이러한 디바이스에서는 보통 GPU에 명령어를 디스패치하기 위해 메모리 내의 명령어큐를 설정하고 관리해야 합니다.또한 버퍼 관리와 메모리 [3]내의 빈 영역이 필요합니다.처음에는 사용자 공간 프로그램(예: X Server)이 이러한 리소스를 직접 관리했지만, 대개 이러한 리소스는 자신만 액세스할 수 있는 것처럼 작동했습니다.두 개 이상의 프로그램이 동시에 동일한 하드웨어를 제어하고 각각 고유한 방식으로 리소스를 설정하려고 하면 대부분의 경우 실패로 [3]끝납니다.

Access to video card without DRM
DRM 미포함
Access to video card with DRM
DRM 사용 시
DRM을 통해 여러 프로그램이 3D 비디오 카드에 동시에 액세스할 수 있어 충돌을 방지합니다.

Direct Rendering Manager는 여러 프로그램이 비디오 하드웨어 리소스를 [4]공동으로 사용할 수 있도록 작성되었습니다.DRM은 GPU에 대한 배타적 접근권을 가지며 명령어큐, 메모리 및 기타 하드웨어 자원의 초기화 및 유지보수를 담당합니다.GPU를 사용하고자 하는 프로그램은 DRM에 요청을 보냅니다. DRM은 중재자 역할을 하며 발생할 수 있는 충돌을 피합니다.

DRM의 범위는 프레임 버퍼 관리 및 모드 설정, 메모리 공유 객체 및 메모리 동기화 [5][6]등 사용자 공간 프로그램에서 이전에 처리했던 더 많은 기능을 포함하도록 수년간 확장되어 왔습니다.이러한 확장 중 일부는 Graphics Execution Manager(GEM) 또는 커널 모드 설정(KMS)과 같은 특정 이름으로 지정되었으며, 이러한 확장에서 제공되는 기능이 구체적으로 언급될 경우 이 용어는 널리 사용됩니다.그러나 실제로는 커널 DRM 서브시스템 전체의 일부입니다.

컴퓨터에 2개의 GPU(개별 GPU와 통합 GPU)를 탑재하는 경향은 GPU 스위칭 등의 새로운 문제로 이어졌습니다.GPU 스위칭은 DRM 레이어에서도 해결할 필요가 있었습니다.Nvidia Optimus 테크놀로지에 대응하기 위해 DRM에는 [7]PRIME이라고 불리는 GPU 오프로드 기능이 제공되었습니다.

소프트웨어 아키텍처

Linux 커널의 Direct Rendering Manager를 사용하여 3D 가속 그래픽 카드에 액세스하는 프로세스

Direct Rendering Manager는 커널 공간에 상주하므로 사용자 공간 프로그램은 커널 시스템 호출을 사용하여 서비스를 요청해야 합니다.단, DRM은 자체 맞춤형 시스템콜을 정의하지 않습니다.대신 Unix의 "everything is a file" 원칙에 따라 파일 시스템 네임스페이스를 통해 GPU를 공개합니다./dev계층.DRM에 의해 검출된 각 GPU를 DRM 디바이스 및 디바이스 파일이라고 부릅니다./dev/dri/cardX([8][9]X는 시퀀셜 번호)와 인터페이스하기 위해 작성됩니다.GPU와 통신하는 사용자 공간 프로그램은 이 파일을 열고 ioctl 호출을 사용하여 DRM과 통신해야 합니다.다른 ioctls는 DRM API의 다른 기능에 대응합니다.

Libdrm이라고 하는 라이브러리는 DRM 서브시스템과의 사용자 공간 프로그램 인터페이스를 용이하게 하기 위해 작성되었습니다.이 라이브러리는 DRM API의 모든 ioctl과 상수, 구조 및 기타 도우미 [10]요소에 대해 C로 작성된 함수를 제공하는 래퍼에 불과합니다.libdrm을 사용하면 커널 인터페이스가 애플리케이션에 직접 노출되는 것을 피할 수 있을 뿐만 아니라 프로그램 간에 코드를 재사용하고 공유하는 일반적인 이점이 있습니다.

Direct Rendering Manager 아키텍처 상세: libdrm으로 인터페이스되는 DRM 코어 및 DRM 드라이버(GEM 및 KMS 포함)

DRM은 지원되는 하드웨어 유형별로 범용 [11]"DRM 코어"와 특정 "DRM 드라이버"의 두 부분으로 구성됩니다.DRM 코어는 다양한 DRM 드라이버를 등록할 수 있는 기본 프레임워크를 제공하며 하드웨어에 의존하지 않는 공통 기능을 갖춘 최소한의 [8]ioctl 세트를 사용자 공간에 제공합니다.한편, DRM 드라이버는, 서포트되고 있는 GPU 타입에 특유의 하드웨어 의존적인 부분을 실장합니다.DRM 코어가 커버하지 않는 나머지 ioctls를 실장할 수도 있지만,[8] 이러한 하드웨어에서만 이용할 수 있는 추가 기능을 갖춘 ioctls를 추가해 API를 확장할 수도 있습니다.특정 DRM 드라이버가 확장 API를 제공하는 경우 user-space libdrm도 추가 라이브러리 libdrm-driver에 의해 확장됩니다.이러한 libdrm 드라이버는 사용자 공간에서 추가 ioctls와 인터페이스하기 위해 사용할 수 있습니다.

API

DRM 코어는, 유저 스페이스의 애플리케이션에 복수의 인터페이스를 export 합니다.일반적으로, 대응하는 것을 통해서 사용하는 것을 목적으로 하고 있습니다.libdrm래퍼 기능또한 드라이버는 ioctls 및 sysfs 파일을 통해 사용자 공간 드라이버 및 장치 인식 응용 프로그램에서 사용할 수 있도록 장치별 인터페이스를 내보냅니다.외부 인터페이스에는 메모리 매핑, 컨텍스트 관리, DMA 조작, AGP 관리, vblank 제어, 펜스 관리, 메모리 관리 및 출력 관리가 포함됩니다.

DRM-Master 및 DRM-Auth

DRM API에는 보안상의 목적 또는 동시성 [8]문제 중 하나를 디바이스별로 1개의 사용자 공간 프로세스로 사용하도록 제한해야 하는 몇 가지 조작(ictls)이 있습니다.이 제한을 실장하기 위해서, DRM은, 이러한 ioctls가 통상 DRM-Master라고 불리는 DRM 디바이스의 「마스터」라고 간주되는 프로세스에서만 호출되도록 제한합니다.디바이스 노드가 있는 모든 프로세스 중1개만/dev/dri/cardX오픈된 파일핸들은 마스터로서 마크가 붙습니다.특히 첫 번째 호출은SET_MASTER ioctl.이러한 제한된 ioctl 중 하나를 DRM-Master가 아닌 상태에서 사용하려고 하면 오류가 반환됩니다.또한 DROP_MASTER ioctl을 호출함으로써 프로세스가 마스터 역할을 포기하고 다른 프로세스가 마스터 역할을 획득할 수도 있습니다.

X 서버(또는 다른 표시 서버)는 일반적으로 관리하는 모든 DRM 디바이스에서 DRM-Master 상태를 취득하는 프로세스입니다.보통 부팅 중에 대응하는 디바이스 노드를 열 때 X 서버가 종료하거나 정지할 때까지 이러한 권한을 그래피컬세션 전체에서 유지합니다.

나머지 사용자 공간 프로세스에서는 DRM-Auth라고 불리는 DRM 디바이스에서 제한된 조작을 호출하는 특권을 얻을 수 있는 다른 방법이 있습니다.이는 기본적으로 프로세스가 DRM-Master의 승인을 받은 것을 증명하기 위한 DRM 디바이스에 대한 인증 방식입니다.순서는 다음과 같습니다.[12]: 13

  • 클라이언트는 GET_MAGIC ioctl을 사용하여 DRM 디바이스로부터 하나의 토큰(32비트 정수)을 취득하고, 어떠한 수단을 통해서도 DRM-Master 프로세스에 전달합니다(통상은 IPC의 일종입니다.예를 들어 DR2에서는 X 클라이언트가 X 서버에 송신할 수 있는 DRI2 Authenticate 요구가 있습니다).[13]
  • 다음으로 DRM-Master 프로세스는 AUTH_MAGIC ioctl을 호출하여 토큰을 DRM 디바이스에 반환합니다.
  • 디바이스는 인증 토큰이 DRM-Master로부터 수신한 토큰과 일치하는 프로세스파일 핸들에 특별한 권한을 부여합니다.

그래픽스 실행 매니저

비디오 메모리의 사이즈의 증가와 OpenGL 등의 그래픽스 API의 복잡성의 증가로 인해 각 컨텍스트 스위치에서 그래픽 카드 상태를 재초기화하는 전략은 너무 비싸고 퍼포먼스 면에서 문제가 있었습니다.또한 최신 Linux 데스크톱에서는 컴포지팅 매니저와 오프스크린 버퍼를 공유할 수 있는 최적의 방법이 필요했습니다.이러한 요건에 의해, 커널내의 그래픽 버퍼를 관리하는 새로운 방법이 개발되었습니다.그래픽스 실행 매니저(GEM)는 이러한 방법 [6]중 하나로 등장했습니다.

GEM은 명시적인 메모리 관리 프리미티브를 [6]가진 API를 제공합니다.GEM을 통해 사용자 공간 프로그램은 GPU 비디오 메모리에 존재하는 메모리 개체를 생성, 처리 및 파괴할 수 있습니다.때user-space 프로그램(한 framebuffer, 질감 또는 기타 데이터 GPU[15]가 요구한 저장할)비디오 메모리 덩어리 필요한 이러한 물체들,"GEM개체"[14]은user-space 프로그램의 관점에서 끈질기시군과 프로그램이 그래픽 처리 장치의 통제권을 회복할 때마다 다시 로드할 필요 없다, 그것은 DRM에 할당을 요청하다. 운전자GEM API를 사용합니다.DRM 드라이버는, 사용중의 비디오 메모리를 추적해, 사용 가능한 메모리가 있는 경우는 요구에 응할 수 있습니다.이 경우, 「핸들」을 유저 스페이스에 되돌려, 향후의 [6][14]조작에 할당이 끝난 메모리를 한층 더 참조할 수 있습니다.GEM API는 버퍼를 채우고 더 이상 필요하지 않을 때 버퍼를 해제하는 조작도 제공합니다.릴리스되지 않은 GEM 핸들의 메모리는 사용자 공간 프로세스가 DRM 디바이스 파일 기술자를 의도적으로 닫았을 때 또는 [16]종료되었기 때문에 복구됩니다.

또, GEM 에서는, 같은 DRM 디바이스(즉, 같은 DRM 드라이버)를 사용하는 복수의 유저 스페이스프로세스가 GEM [16]오브젝트를 공유할 수도 있습니다.GEM 핸들은 프로세스에 고유하지만 다른 프로세스에서도 반복 가능한 로컬 32비트 정수이므로 공유에는 적합하지 않습니다.필요한 것은 글로벌 네임스페이스이며 GEM은 GEM 이름이라는 글로벌핸들을 사용하여 네임스페이스를 제공합니다.GEM 이름은 하나의 32비트 정수를 사용하여 동일한 DRM 드라이버에 의해 동일한 DRM 디바이스 내에 작성된1개의 GEM 오브젝트를 말합니다.GEM은 GEM [16][12]: 16 핸들에서 GEM 이름을 얻기 위한 조작 플랭크를 제공합니다.이 프로세스에서는 사용 [12]: 15 가능한 임의의 IPC 메커니즘을 사용하여 이 GEM 이름(32비트 정수)을 다른 프로세스에 전달할 수 있습니다.GEM 이름은 원래 GEM 개체를 가리키는 로컬 GEM 핸들을 얻기 위해 수신자 프로세스에서 사용할 수 있습니다.

유감스럽게도 버퍼 공유에 GEM 이름을 사용하는 것은 [12]: 16 [17][18]안전하지 않습니다.같은 DRM 디바이스에 액세스 하는 악의적인 서드파티 프로세스는 32비트 정수를 조사하는 [19][18]것만으로 다른 2개의 프로세스가 공유하는 버퍼의 GEM 이름을 추측하려고 할 수 있습니다.GEM 이름이 발견되면 그 내용에 접근하여 변경할 수 있으며 버퍼 정보의 기밀성과 무결성을 침해할 수 있습니다.이 단점은 나중에 DMA-BUF 지원이 DRM에 도입됨으로써 극복되었습니다.DMA-BUF는 파일 기술자로서 사용자 공간의 버퍼를 나타내며, 이 버퍼는 안전하게 공유될 수 있기 때문입니다.

비디오 메모리 관리 시스템에서 비디오 메모리 공간 관리 외에 중요한 작업은 GPU와 CPU 간의 메모리 동기화를 처리하는 것입니다.현재의 메모리 아키텍처는 매우 복잡하며 일반적으로 시스템 메모리와 비디오 메모리의 캐시 수준이 다양합니다.따라서 비디오 메모리 매니저는 CPU와 GPU 간에 공유되는 데이터의 [20]일관성을 확보하기 위해 캐시 일관성도 처리해야 합니다.즉, 비디오 메모리 관리 기능은 GPU 및 메모리 아키텍처의 하드웨어 세부 사항에 크게 의존하고 있기 때문에 드라이버에 [21]따라 다릅니다.

GEM은 처음에 인텔 엔지니어에 의해 i915 [20]드라이버용 비디오 메모리 매니저를 제공하기 위해 개발되었습니다.그 인텔 GMA9xx 가족이 GPU와 CPU가 물리적 메모리 공유한 메모리 구조(일정외 정비 활동),. 그런데 전용 VRAM지 않다 GPUs 융화되었다.[22]척도, 그리고 이러한 암기 영역이 있GPU-independent,[6]그들은 구체적으로는 일정외 정비 활동 메모리 구조와분 만에 디자인된 메모리 동기화를 위해"기억 영역"을 정의합니다.d, 별도의 VRAM이 있는 경우와 같은 다른 메모리 아키텍처에는 적합하지 않습니다.이러한 이유로 다른 DRM 드라이버는 GEM API를 사용자 공간 프로그램에 공개하기로 결정했지만 내부적으로는 특정 하드웨어 및 메모리 [23]아키텍처에 적합한 다른 메모리 매니저를 구현했습니다.

GEM API는 실행 흐름(명령어 버퍼)을 제어하기 위한 ioctls도 제공하지만 인텔 i915 이후의 [6]GPU에서 사용하기 위해 인텔 고유의 것입니다.메모리 관리 고유의 ioctls 이외의 GEM API의 일부를 실장하려고 한 DRM 드라이버는 없습니다.

변환 테이블 맵

Translation Table Maps(TTM; 변환 테이블 맵)는 [5][14]GEM 이전에 개발된 GPU의 범용 메모리 매니저 이름입니다.전용 비디오 RAM(일반적으로 비디오 카드에 장착됨) 및 그래픽스 주소 재매핑 테이블([5]GART)이라고 불리는 I/O 메모리 관리 유닛을 통해 액세스할 수 있는 시스템 메모리 등 GPU가 액세스할 수 있는 다양한 유형의 메모리를 관리하기 위해 특별히 설계되었습니다.또, 유저 스페이스의 그래픽스 애플리케이션은 통상, 대량의 비디오 데이터에 대응하고 있기 때문에, TTM 는, CPU 로 직접 행선지 지정할 수 없는 비디오 RAM 의 부분을 처리해, 최대한의 퍼포먼스로 실행할 필요가 있습니다.또 다른 중요한 문제는 관련된 여러 메모리와 캐시 간의 일관성을 유지하는 것이었습니다.

TTM의 주요 개념은 "버퍼 객체"로,[5] GPU에 의해 주소 지정이 가능해야 하는 비디오 메모리의 영역입니다.사용자 공간 그래픽스 애플리케이션이 특정 버퍼 객체에 대한 액세스(통상은 컨텐츠로 채워짐)를 원하는 경우 TTM은 CPU에 의해 주소 지정 가능한 메모리 유형으로 재배치해야 할 수 있습니다.GPU가 버퍼 개체에 액세스해야 하지만 GPU의 주소 공간에 있지 않은 경우 추가 재배치(GART 매핑 작업)가 발생할 수 있습니다.이러한 재배치 작업은 각각 관련된 데이터 및 캐시 일관성 [5]문제를 처리해야 합니다.

또 하나의 중요한 TTM 개념은 펜스입니다.펜스는 기본적으로 CPU와 [24]GPU 간의 동시성을 관리하기 위한 메커니즘입니다.펜스는 버퍼 오브젝트가 GPU에 의해 사용되지 않게 된 시점을 추적합니다.일반적으로 액세스 권한이 [5]있는 사용자 공간 프로세스에 통지하기 위해 사용됩니다.

TTM은 전용 VRAM을 포함하거나 사용하지 않는 모든 종류의 메모리 아키텍처를 적절한 방법으로 관리하려고 했고, 메모리 매니저에서 생각할 수 있는 모든 기능을 모든 유형의 하드웨어에서 사용하기 위해 제공하려고 했기 때문에 API가 [24][14]필요한 것보다 훨씬 더 큰 솔루션을 제공하게 되었습니다.일부 DRM 개발자들은 특정 드라이버, 특히 API와 잘 맞지 않는다고 생각했습니다.GEM이 보다 단순한 메모리 매니저로 등장했을 때, GEM의 API는 TTM의 API보다 선호되었습니다.그러나 일부 드라이버 개발자는 TTM이 채택한 접근방식이 전용 비디오 메모리와 IOMMU를 갖춘 개별 비디오 카드에 더 적합하다고 생각했기 때문에 내부적으로 TTM을 사용하기로 결정하고 버퍼 객체를 GEM 개체로 공개하여 GEM API를 [23]지원하기로 했습니다.내장 메모리 매니저로서 TTM 를 사용하고 있지만, GEM API 를 제공하는 현재의 드라이버의 예로는 AMD 비디오 카드용 Radeon 드라이버와 NVIDIA 비디오 카드용 nouveau 드라이버가 있습니다.

DMA 버퍼 공유 및 PRIME

DMA 버퍼 공유 API(종종 DMA-BUF)는 Linux 커널 내부 API로 여러 디바이스 간에 DMA 버퍼를 공유하기 위한 범용 메커니즘을 제공하도록 설계되어 있습니다.아마도 다른 유형의 디바이스 [25][26]드라이버에 의해 관리될 수 있습니다.예를 들어 Video4Linux 디바이스와 그래픽 어댑터 디바이스는 DMA-BUF를 통해 버퍼를 공유하여 첫 번째 비디오 스트림에 의해 생성되어 후자에 의해 소비되는 비디오 스트림의 데이터를 제로 카피할 수 있습니다.모든 Linux 디바이스 드라이버는 이 API를 내보내기, 사용자(컨슈머) 또는 둘 다로 구현할 수 있습니다.

이 기능은 DRM에서 최초로 이용되어 DMA-BUF를 사용하여 디스크리트 GPU의 DRM 드라이버와 통합 [27]: 13 GPU 간에 프레임 버퍼를 공유하는 GPU 오프로드 솔루션인 PRIME을 구현했습니다.DMA-BUF의 중요한 특징은 공유 버퍼가 파일 [14][12]: 17 기술자로 사용자 공간에 제공된다는 것입니다.PRIME의 개발을 위해 로컬 GEM 핸들을 DMA-BUF 파일 기술자로 변환하는 ioctls와 정반대 동작을 위한 ioctls 두 개가 DRM API에 추가되었습니다.

이들 2개의 새로운 ioctl은 나중에 GEM 버퍼 [12]: 17 공유의 본질적인 안전하지 않은 부분을 수정하는 방법으로 재사용되었습니다.GEM 이름과는 달리 파일 기술자는 추측할 수 없습니다(글로벌 네임스페이스가 아닙니다).유닉스 운영체제는 SCM_RIGHTS [14][28]: 11 시멘틱스를 사용하여 UNIX 도메인소켓에 안전하게 전달할 수 있습니다.GEM 객체를 다른 프로세스와 공유하는 프로세스는 로컬 GEM 핸들을 DMA-BUF 파일 기술자로 변환하여 수신자에게 전달할 수 있습니다.이것에 의해, 수신한 파일 [12]: 16 기술자로부터 독자적인 GEM 핸들을 취득할 수 있습니다.이 메서드는 클라이언트와 X 서버[29] 간에 버퍼를 공유하기 위해 DRI3에서 사용되며 Wayland에서도 사용됩니다.

커널 모드 설정

사용자 공간에 "DRM 마스터"가 있어야 합니다. 이 프로그램은 KMS에 독점적으로 액세스할 수 있습니다.

비디오 카드 또는 그래픽 어댑터가 올바르게 동작하려면 , 비디오 카드 또는 그래픽 어댑터의 해상도, 색심도, 및 리프레쉬 레이트의 조합으로, 그 모드와 접속되어 있는 디스플레이 화면에서 서포트되고 있는 값의 범위내에 있는 모드를 설정할 필요가 있습니다.이 조작은 모드 [30]설정이라고 불리며, 보통 그래픽 하드웨어에 대한 원시 액세스, 즉 비디오 [31][32]카드의 특정 레지스터에 쓰는 기능이 필요합니다.모드 설정 조작은 프레임버퍼 사용을 시작하기 전에 실행해야 합니다.또, 애플리케이션 또는 유저가 모드를 변경할 필요가 있는 경우에도 실행할 필요가 있습니다.

초기에는 그래피컬 프레임 버퍼를 사용하고자 하는 사용자 공간 프로그램도 [3]모드 설정 작업을 담당했기 때문에 비디오 하드웨어에 대한 권한 있는 액세스로 실행할 필요가 있었습니다.Unix 타입의 operating system에서는, X Server 가 가장 현저한 예이며, 모드 설정 실장은, 특정의 비디오 [33]카드의 타입 마다 DDX 드라이버에 포함되어 있습니다.나중에 User space Mode-Setting(UMS;[34][35] 사용자 공간 모드 설정)이라고 불리는 이 접근법은 몇 가지 [36][30]문제를 일으킵니다.이로 인해 운영체제가 프로그램과 하드웨어 간에 제공해야 하는 분리 기능이 손상되어 안정성과 보안에 대한 우려가 높아집니다.또, 복수의 유저 스페이스 프로그램이 동시에 모드 설정을 실시하려고 하면, 그래픽 하드웨어가 일관성이 없는 상태가 되는 일이 있습니다.이러한 경합을 피하기 위해 X Server는 실제로 모드 설정 작업을 수행한 유일한 사용자 공간 프로그램이 되었습니다.나머지 사용자 공간 프로그램은 X Server에 의존하여 적절한 모드를 설정하고 모드 설정을 포함한 기타 작업을 처리했습니다.처음에는 X 서버 시작 프로세스 중에 모드 설정이 단독으로 수행되었지만 나중에 X 서버가 실행 중에 [37]모드 설정을 수행할 수 있게 되었습니다.XFree86-VidModeExtension 확장은 XFree86 3.1.2에서 도입되어 X서버에 [38][39]대한 모델라인(해상도) 변경을 요청할 수 있게 되었습니다.VidMode 확장은 나중에 보다 일반적인 XRandR 확장으로 대체되었습니다.

그러나 Linux 시스템에서 모드 설정을 수행하는 코드는 이뿐만이 아닙니다.시스템 부팅 프로세스 중에 Linux 커널은 가상 콘솔에 최소 텍스트 모드를 설정해야 합니다(VESA BIOS [40]확장에 의해 정의된 표준 모드에 기반).또, Linux 커널 프레임 버퍼 드라이버에는, 프레임 [2]버퍼 디바이스를 설정하기 위한 모드 설정 코드가 포함되어 있습니다.모드 설정 충돌을 피하기 위해 XFree86 서버(나중에 X)를 사용합니다.[Org Server] : 사용자가 그래픽 환경에서 텍스트 가상 콘솔로 전환했을 때 모드 설정 상태를 저장하고 사용자가 [41]X로 전환했을 때 복원하여 처리했습니다.이 프로세스로 인해 이행 중에 성가신 깜박임이 발생하고 오류가 발생하여 출력 디스플레이가 [42]파손되거나 사용할 수 없게 될 수 있습니다.

사용자 공간 모드 설정 접근법에서도 다음과 [43][42]같은 문제가 발생했습니다.

  • 일시정지/재개 프로세스는 이전 모드를 복원하기 위해 사용자 공간 도구를 사용해야 합니다.이러한 프로그램 중 하나의 장애 또는 크래시가 발생하면 모드 세트의 잘못된 설정으로 인해 디스플레이가 작동하지 않아 시스템을 사용할 수 없게 될 수 있습니다.
  • 또한 커널이 알고 있는 모드는 VESA BIOS 표준 텍스트모드뿐이었기 때문에 X가 실행 중일 때 등 화면이 그래픽 모드일 때 커널에서 오류 또는 디버깅메시지를 표시할 수 없었습니다.
  • 더욱 시급한 문제는 X 서버를 우회하는 그래픽 애플리케이션의 증가와 X를 대체하는 다른 그래픽 스택의 출현으로 시스템 전체에서 모드 설정 코드의 복제가 더욱 확대되었다는 것입니다.

이러한 문제에 대처하기 위해 모드 설정 코드를 커널 내의 단일 장소, 특히 기존 DRM [36][37][44][42][43]모듈로 이동했습니다.그러면 X Server를 포함한 모든 프로세스가 커널에 모드 설정 조작을 실행하도록 명령할 수 있어야 하며, 커널은 동시 조작으로 일관성이 없는 상태가 되지 않도록 합니다.이러한 모드 설정 작업을 수행하기 위해 DRM 모듈에 추가된 새로운 커널 API와 코드를 KMS(Kernel [30]Mode-Setting)라고 부릅니다.

커널 모드 설정에는 몇 가지 이점이 있습니다.가장 빠른 것은 물론 커널(Linux 콘솔, fbdev)과 사용자 공간(X Server DDX 드라이버) 모두에서 중복 모드 설정 코드를 제거하는 것입니다.또한 KMS는 대체 그래픽 시스템을 쉽게 기술할 수 있도록 지원하므로 이제 자체 모드 설정 [42][43]코드를 구현할 필요가 없습니다.중앙 집중식 모드 관리를 제공함으로써 KMS는 콘솔과 X를 바꾸면서 깜박임 문제를 해결하고 X의 다른 인스턴스(고속 사용자 전환)[41][44]도 해결합니다.커널에서 사용할 수 있기 때문에 부팅 프로세스 시작 시에도 사용할 수 있으므로 초기 단계에서 모드 변경으로 인한 깜박임을 방지할 수 있습니다.

KMS는 커널의 일부이기 때문에 인터럽트 [45]등의 커널 공간에서만 사용 가능한 리소스를 사용할 수 있습니다.예를 들어 일시정지/재개 프로세스 후의 모드 복구는 커널 자체에 의해 관리되므로 많은 것을 단순화하고 부수적으로 보안을 향상시킵니다(루트 권한이 필요한 사용자 공간 툴은 더 이상 필요 없음).또한 커널을 통해 새로운 디스플레이 장치를 쉽게 핫 플러그할 수 있어 오랜 문제를 [45]해결할 수 있습니다.모드 설정도 메모리 관리와 밀접하게 관련되어 있습니다.프레임 버퍼는 기본적으로 메모리버퍼이기 때문에 그래픽스 메모리 매니저와의 긴밀한 통합을 강력히 권장합니다.이것이 커널 모드 설정 코드가 별도의 [44]서브시스템이 아닌 DRM에 통합된 주된 이유입니다.

DRM API의 하위 호환성을 유지하기 위해 특정 DRM [46]드라이버의 추가 드라이버 기능으로 커널 모드 설정이 제공됩니다.DRM 드라이버는 DRM 코어에 등록할 때 DRIVER_MODESET 플래그를 제공하여 가 KMS [8]API를 지원함을 나타낼 수 있습니다.커널 모드 설정을 실장하는 드라이버는, KMS 드라이버가 없는 레거시 DRM 드라이버와 구별하기 위해서, KMS 드라이버라고 불리는 경우가 많습니다.

KMS는 3D 액셀러레이션이 부족한 드라이버(또는 하드웨어 벤더가 이를 공개하거나 구현하고 싶지 않은 드라이버)는 나머지 DRM API 없이 KMS API를 구현할 수 있도록 채택되었습니다.

KMS 디바이스 모델

KMS는 디스플레이 컨트롤러의 디스플레이 출력 파이프라인에서 공통적으로 볼 수 있는 일련의 추상 하드웨어 블록으로서 출력 디바이스를 모델링 및 관리한다.블록은 다음과 같습니다.[47]

  • CRTC: (CRT 컨트롤러에서[48][33]) 각 CRTC는 디스플레이 컨트롤러의 스캔아웃 엔진을 나타내며, 스캔아웃 버퍼(프레임 버퍼)[47]를 가리킵니다.CRTC의 목적은 현재 스캔아웃 버퍼에 있는 픽셀 데이터를 읽고 PLL [49]회로의 도움을 받아 이 데이터로부터 비디오 모드 타이밍 신호를 생성하는 것입니다.사용 가능한 CRTC의 수에 따라 하드웨어가 동시에 처리할 수 있는 독립된 출력 디바이스의 수가 결정됩니다.따라서 멀티헤드 구성을 사용하려면 디스플레이 디바이스당 적어도1개의 CRTC가 필요합니다.[47]2개 이상의 CRTC가 같은 프레임버퍼에서 스캔하여 같은 이미지를 여러 출력 디바이스에 [49][48]송신하는 경우에도 클론모드로 동작할 수 있습니다.
  • 커넥터: 커넥터는 디스플레이 컨트롤러가 표시할 스캔아웃 동작에서 비디오 신호를 전송하는 위치를 나타냅니다.일반적으로 커넥터의 KMS 개념은 출력 디바이스(모니터, 노트북 패널 등)를 영속적으로 또는 일시적으로 접속할 수 있는 하드웨어의 물리 커넥터(VGA, DVI, FPD-Link, HDMI, DisplayPort, S-Video 등)에 대응합니다.접속 상태, EDID 데이터, DPMS 상태, 지원되는 비디오모드 등 현재 물리적으로 접속되어 있는 출력 디바이스와 관련된 정보도 [47]커넥터 내에 저장됩니다.
  • 인코더: 디스플레이 컨트롤러는 목적의 [47]커넥터에 적합한 포맷을 사용하여 CRTC로부터의 비디오 모드 타이밍 신호를 부호화해야 합니다.인코더는 이러한 부호화 중 하나를 실행할 수 있는 하드웨어 블록을 나타냅니다.디지털 출력의 경우 인코딩의 예로는 TMDS 및 LVDS가 있습니다.VGA 및 TV 출력 등의 아날로그 출력에서는 일반적으로 특정 DAC 블록이 사용됩니다.커넥터는 한 번에 [47]1개의 인코더로부터 신호를 수신할 수 있으며, 각 유형의 커넥터는 일부 인코딩만 지원합니다.또한 모든 CRTC가 사용 가능한 모든 인코더에 접속되어 있지 않기 때문에 CRTC-인코더 커넥터의 조합이 제한될 수 있습니다.
  • 플레인: 플레인은 하드웨어 블록이 아니라 스캔아웃엔진(CRTC)이 공급되는 버퍼를 포함하는 메모리 객체입니다.프레임 버퍼를 유지하는 플레인은 프라이머리 플레인이라고 불리며, CRTC가 비디오 모드(화면 해상도(폭과 높이), 픽셀 크기, 픽셀 형식, 리프레시 레이트 등)를 결정하는 소스이기 때문에 각 CRTC에는 [47]1개가 관련되어 있어야 합니다.디스플레이 컨트롤러가 하드웨어 커서 오버레이를 지원하는 경우 CRTC에 커서 평면이 연결되거나 추가 하드웨어 오버레이에서 스캔하여 출력 장치로 [33]전송된 최종 이미지를 "온 더 플라이"로 구성 또는 블렌딩할 수 있는 경우 보조 평면이 연결되었을 수도 있습니다.

아토믹 디스플레이

최근 몇 년 동안 특히 모드 설정 및 페이지 플립 [33][50]조작과 관련하여 KMS API와 관련된 일부 정기 조작에 원자성을 가져오려는 지속적인 노력이 있었습니다.이 확장 KMS API는 Atomic Display(이전에는 Atomic 모드 설정 및 Atomic 또는 nuclear 페이지 플립)라고 불립니다.

아토믹 모드 설정의 목적은, 복수의 제약이 있는 복잡한 설정에서는, 일관성이 없거나 무효인 비디오 [50]상태를 초래할 가능성이 있는 중간 순서를 회피하는 것입니다.또, 실패한 모드 설정 프로세스를 원래대로 되돌릴 필요가 있는(「롤백」)[51]: 9 위험한 비디오 상태를 회피하는 것입니다.아토믹 모드 설정에서는 모드테스트 [50]기능을 제공함으로써 특정 특정 모드 설정이 적절한지 여부를 사전에 알 수 있습니다.아토믹 모드가 테스트되어 그 유효성이 확인되면, 1개의 분할할 수 없는(아토믹) 커밋 조작으로 적용할 수 있습니다.테스트 조작과 커밋 조작 모두 플래그가 다른 동일한 새로운 ioctl에서 제공됩니다.

한편, 원자 페이지 플립에서는, 같은 출력의 복수의 플레인(프라이머리 플레인, 커서 플레인, 및 일부의 오버레이 또는 세컨더리 플레인 등)을 모두 같은 VBLANK 간격내에서 동기 해, 찢기지 않고 올바르게 표시할 [51]: 9,14 [50]수 있습니다.이 요건은 특히 전력을 절약하기 위해 여러 평면/오버레이를 사용하는 경향이 있는 이동식 및 임베디드 디스플레이 컨트롤러와 관련이 있습니다.

새로운 atomic API는 오래된 KMS API를 기반으로 구축되었습니다.동일한 모델 및 객체(CRTC, 인코더, 커넥터, 평면 등)를 사용하지만 [50]변경할 수 있는 객체 속성이 증가합니다.원자적 순서는 테스트 또는 커밋할 상태를 구축하기 위해 관련 속성을 변경하는 것을 기반으로 합니다.변경하는 속성은 모드 설정(대부분 CRTC, 인코더 및 커넥터 속성) 또는 페이지 플립(일반적으로 플레인 속성) 중 어느 쪽을 실행할지에 따라 달라집니다.ioctl은 두 경우 모두 동일하지만 각각에 [52]전달된 속성 목록이 다릅니다.

렌더 노드

원래의 DRM API에서는 DRM 디바이스는/dev/dri/cardX는 특권([9]모드 설정, 기타 디스플레이 제어) 및 비특권(렌더링, GPGPU 컴퓨팅) 조작에 모두 사용됩니다.보안상의 이유로 연관된 DRM 디바이스 파일을 열려면 "root-privilege"[53]와 동등한 특권이 필요합니다.이것에 의해, 신뢰할 수 있는 유저 스페이스 프로그램(X 서버, 그래피컬·컴포지터 등)만이, 모드 세트 API등의 특권 부분을 포함한 DRM API 에 완전하게 액세스 할 수 있는 아키텍처가 됩니다.GPGPU 계산을 렌더링 또는 실행하는 나머지 사용자 공간 애플리케이션은 DRM 디바이스 소유자('DRM 마스터')가 특별한 [54]인증 인터페이스를 사용하여 부여해야 합니다.그러면 인증된 응용 프로그램은 권한 있는 조작 없이 제한된 버전의 DRM API를 사용하여 렌더링하거나 계산을 수행할 수 있습니다.이 설계에는 엄격한 제약이 따릅니다.[53][54]GPGPU 계산과 같은 그래픽 디스플레이가 필요 없는 경우에도 다른 사용자 공간 프로그램에서 디바이스를 사용할 수 있도록 DRM 디바이스의 DRM 마스터로서 동작하는 그래픽 서버(X 서버, Wayland 컴포지터 등)가 항상 존재해야 합니다.

「렌더 노드」의 개념은, DRM 유저 스페이스 API를 2개의 인터페이스(특권 인터페이스와 비특권 인터페이스)로 분할해,[9] 각각 다른 디바이스 파일(또는 「노드」)을 사용하는 것으로, 이러한 시나리오를 해결하려고 합니다.검출된 모든 GPU에 대응하는 DRM 드라이버(렌더 노드 기능을 서포트하고 있는 경우)에 의해 디바이스 파일이 작성됩니다./dev/dri/renderDX프라이머리 노드 외에 렌더 노드라고 불립니다./dev/dri/cardX한 GPU의 컴퓨팅 시설의 활용을 원하는 직접적인 렌더링 모델과 어플리케이션을 이용하고 .[54][9]고객들은 추가적인 특권을 요구하지 않고 간단히 그리고 GPU사업은 DRMAPI의 제한된 부분 집합들 nodes—provided 그들이 가진 파일 sys의 지원을 사용하여 파견 기존 기반해 노드를 열고 할 수 있다.당에 따르면디바이스 파일을 여는 미션입니다.디스플레이 서버, 컴포지터 및 기타 modeset API 또는 기타 특권 조작이 필요한 프로그램은 완전한 DRM API에 대한 접근을 허용하는 표준 프라이머리 노드를 열어 평소대로 사용해야 합니다.렌더 노드에서는 안전하지 않은 GEM 글로벌 이름을 사용한 버퍼 공유를 방지하기 위해 GEM 플링크 조작을 명시적으로 허용하지 않습니다.그래픽 [9][54]서버를 포함한 다른 클라이언트와 버퍼를 공유할 수 있는 것은 PRIME(DMA-BUF) 파일 기술자뿐입니다.

하드웨어 지원

주요 기사:프리 오픈 소스 그래픽스 디바이스 드라이버
DRM은 다음과 같은 사용자 모드 그래픽 디바이스 드라이버에서 사용됩니다.AMD Catalyst 또는 Mesa 3D.사용자 공간 프로그램은 Linux System Call Interface를 사용하여 DRM에 액세스합니다.DRM은 Linux System Call Interface를 자체 시스템 [55]호출로 확장합니다.

Linux DRM 서브시스템에는 데스크톱 컴퓨터용 GPU의 3대 주요 제조업체(AMD, NVIDIA 및 인텔) 및 모바일 GPU 및 System on a Chip(SoC) 인테그레이터의 하드웨어를 지원하는 무료 오픈 소스 드라이버가 포함되어 있습니다.각 드라이버의 품질은 제조사의 협력 정도 등에 따라 크게 다릅니다.

DRM 드라이버
드라이버 커널 이후 지원되는 하드웨어 벤더 지원 상태/주의
라데온 2.4.1 TeraScale 및 GCN 1세대 및 2세대 아키텍처를 탑재한 AMD(구 ATi) Radeon GPU 시리즈.R100/200/300/400, Radeon X1000, HD 2000/4000/5000/6000/7000/8000, R5/R7/R9 200/300 시리즈 및 Kaveri APU 모델 포함. 네. 활동적인
i915 2.6.9 인텔 GMA 830M, 845G, 852GM, 855GM, 865G, 915G, 945G, 965G, G35, G41, G43, G45 칩셋.인텔 HD 및 Iris 그래픽스 HD 그래픽스 2000/3000/2500/4000/4200/4600/4600/4600/4600/4600/5000, Iris 그래픽스 5100, Iris Pro 그래픽스 5200 내장 GPU. 네. 활동적인
누보 2.6.33[56][57] NVIDIA Tesla, Fermi, Kepler, Maxwell 기반의 GeForce GPU, Tegra K1, X1 SoC 부분적 활동적인
외부 3.2[58] 삼성 ARM 기반의 Exynos SoC
vmwgfx 3.2 (스테이지에서)[59] VMware SVGA2용 가상 GPU 가상 드라이버
gma500 3.3 (스테이지에서)[60][61] 인텔 GMA 500 및 기타 이미지 테크놀로지(PowerVR) 기반 그래픽스 GPU 실험용 2D KMS 전용 드라이버
아스트 3.5[62] ASpeed Technologies 2000 시리즈 실험적인
mgag200 3.5[63] Matrox MGA-G200 서버 디스플레이 엔진 KMS만의
모바일 3.7[64] 르네사스 SH 모바일
테그라 3.8[65] Nvidia Tegra20, Tegra30 SoC 네. 활동적인
omapdrm 3.9[66] Texas Instruments OMAP5 SoC
rcar-du 3.11[67] 르네사스 R-Car SoC 디스플레이 유닛
메시지 3.12[68][69] 퀄컴의 Adreno A2xx/A3xx/A4xx GPU 패밀리(Snapdragon SOC)[70]
무적함대 3.13[71][72] Marvell Armada 510 SoCs
동작하다 3.14[73] Bochs dispi vGA 인터페이스를 사용한 가상 VGA 카드(QEMU stdvga 등) 가상 드라이버
스틱 3.17[74][75] STMicroelectronics SoC stiH41x 시리즈
imx 3.19 (스테이지에서)[76][77] 프리스케일 1MX SoC
록칩 3.19[76][78] 록칩 SoC 기반 GPU KMS만의
amdgpu[55] 4.2[79][80] GCN 3세대 및 4세대 아키텍처를 탑재한 AMD Radeon GPU 시리즈.Radeon Rx 200/300/400/500[81] 시리즈 및 Carrizo, Bristol & Stoney Ridge APU 모델 포함. 네. 활동적인
가상 4.2[82] QEMU 기반 가상 머신 매니저용 가상 GPU 드라이버(KVM 또는 Xen 등) 가상 드라이버
VC4 4.4[83][84][85] Rasberry Pi의 Broadcom BCM2835 및 BCM2836 SoC(VideoCore IV GPU)
내비게이션 4.5[86][87][88] Vivante GPU 코어는 Marvell ARMADA 및 Freescale i와 같은 여러 SoC에 포함되어 있습니다.MX6 시리즈
sun4i 4.7[89][90] Allwinner SoC (ARM Mali-400 GPU)
키린 4.7[91][90] HiSilicon Kirin hi6220 SoC(ARM Mali 450-MP4 GPU)
중개하다 4.7[92][90] MediaTek MT8173 SoC (이미지 PowerVR GX6250 GPU)
hibmc 4.10[93] HiSilicon hi1710 HuaweiiBMC SoC(Silicon Image SM750 GPU[94] 코어) KMS만의
비디오 4.19[95][96] 헤드리스 머신에서의 테스트 및 X(또는 이와 유사한 것) 실행에 도움이 되는 KMS 드라이버의 소프트웨어 전용 모델. 가상 드라이버
리마 5.2[97][98] ARM Mali 4xx GPU
동토층 5.2[99][98] ARM Mali Txx(Midgard) 및 Gxx(Bifrost) GPU
비디오 5.2 (스테이지에서)[100][98] Virtual Box용 가상 GPU 드라이버(VBoxVGA GPU) 가상 드라이버
하이퍼 v_drm 5.14[101][102] Hyper-V 가상 비디오 디바이스용 가상 GPU 드라이버 가상 드라이버
심플한 5.14[103][104] 펌웨어 제공 프레임 버퍼용 GPU 드라이버(UEFI GOP, VESA BIOS 확장, 임베디드 시스템)

또, 다음의 표에, 과거의 목적을 위해서, 낡은 하드웨어의 드라이버도 다수 기재되어 있습니다.이들 중 일부는 아직 커널 코드에 남아 있지만 대부분은 이미 제거되었습니다.

과거의 DRM 드라이버
드라이버 커널 이후 지원되는 하드웨어 상태/주의
감마 2.3.18 3Dlabs GLINT GMX 2000 2.6.14[105] 이후 삭제
ffb 2.4 Creator / Creator 3D (Sun Microsystems Ultra 워크스테이션에서 사용) 2.6.21[106] 이후 삭제
tdfx 2.4 3dfx Banshee / Voodoo 3+
mga 2.4 Matrox G200/G400/G450
r128 2.4 ATI Rage 128
i810 2.4 인텔 i810
누이 2.4.17 SiS 300/630/540
i830 2.4.20 인텔 830M/845G/852GM/855GM/865G 2.6.39[107] 이후 삭제(i915 드라이버로 대체)
경유로 2.6.13[108] VIA 유니크롬 / 유니크롬 프로
야만적인 2.6.14[109] S3 그래픽스 새비지 3D/MX/IX/4/SuperSavage/Pro/Twister

발전

Direct Rendering Manager는 Linux 커널 내에서 개발되며 소스 코드는/drivers/gpu/drmLinux 소스 코드의 디렉토리.서브시스템 유지보수는 Dave Airlie이며 다른 유지보수가 특정 드라이버를 [110]관리합니다.Linux 커널 개발에서와 마찬가지로 DRM 서브컨테이너와 컨트리뷰터는 새로운 기능과 버그 수정을 포함한 패치를 메인 DRM 메인터넌스에 송신하고 메인 DRM 메인터넌스는 이들 패치를 자체 Linux 저장소에 통합합니다.DRM 유지보수는 새로운 Linux 버전이 출시될 때마다 메인라인 준비가 된 패치를 모두 Linus Torvalds에 제출합니다.토르발스는 커널 전체의 상위 유지자로서 패치가 커널에 포함하기에 적합한지 여부에 대한 최종 결정권을 가집니다.

이력상의 이유로 libdrm 라이브러리의 소스 코드는 Mesa 프로젝트의 [111]산하에 유지됩니다.

역사

1999년 XFree86용 DRI를 개발하는 동안 Precision Insight는 Mesa 소스 [112]코드에 포함된 Linux 커널 패치로 3dfx 비디오 카드용 DRM의 첫 버전을 만들었습니다.그 해 후반, DRM 코드는 Linux 커널 2.3.18에서 메인 라인업 되었습니다./drivers/char/drm/를 지정합니다.[113]그 후, 서포트되고 있는 비디오 카드의 수는 증가했습니다.2001년 1월에 Linux 2.4.0이 출시되었을 때 이미 Creative Labs GMX 2000, Intel i810, Matrox G200/G400 및 ATI Rage 128 및 3dfx Voodoo3 [114]카드가 지원되었습니다.또, 2.4x 시리즈에서는, 일부의 Sionade 카드용의 드라이버를 사용해, 그 리스트가 확대되었습니다.

DRM을 DRM 코어 드라이버와 DRM 드라이버의 2개의 컴포넌트로 분할하여 DRM 코어/퍼스낼리티 스플릿이라고 불리는 것은 2004년 [11][115]하반기에 실시되어 커널 버전 2.6.[116]11에 통합되었습니다.이 분할에 의해, 복수의 디바이스용의 복수의 DRM 드라이버가 동시에 동작해, 멀티 GPU 서포트에의 길을 열 수 있었습니다.

모든 비디오 모드 설정 코드를 커널 내부의 한 곳에 넣는다는 생각은 [117][118]수년 전부터 인정되어 왔지만, 그래픽 카드 제조업체들은 모드 설정을 하는 유일한 방법은 각 그래픽 카드의 비디오 BIOS에 포함된 자체 루틴을 사용하는 것이라고 주장해 왔습니다.이러한 코드는 x86 real 모드를 사용하여 실행해야 하므로 보호 [44]모드에서 실행되는 커널에 의해 호출되지 않습니다.Luc Verhaegen과 다른 개발자들이 BIOS [119][44]기반 대신 네이티브로 모드 설정을 할 수 있는 방법을 찾았을 때 상황은 바뀌었고, 일반적인 커널 코드를 사용하여 모드 설정을 수행할 수 있음을 보여주고 커널 모드 설정이 될 수 있는 토대를 마련했습니다.2007년 5월 Jesse Barnes (인텔)는 drm-modeseting API와 i915 DRM [42]드라이버 내의 인텔 GPU 모드 설정의 네이티브 실장에 관한 최초의 제안을 발표했습니다.2007년 12월, 제롬 글리스는 ATI 카드의 네이티브 모드 설정 코드를 Rade on DRM [120][121]드라이버에 추가하기 시작했습니다.API와 드라이버의 작업은 2008년에도 계속되었지만 프레임 버퍼를 [122]처리하기 위해 커널 공간에서도 메모리 매니저가 필요하기 때문에 지연되었습니다.

2008년 10월 Linux 커널 2.6.27은 중대한 소스 코드 재구성을 단행한 후 몇 가지 중대한 변경을 가했습니다.DRM 소스 코드 트리가 자체 소스 디렉토리로 이동되었습니다./drivers/gpu/drm/그리고 다른 드라이버들은 각자의 서브디렉토리로 이동했습니다.헤더도 새로운 곳으로 이동했습니다./include/drm디렉토리로 이동합니다.[123]

비디오 메모리 관리의 복잡성이 증가했기 때문에, 이 문제를 해결하기 위한 몇개의 어프로치가 필요하게 되었습니다.첫 번째 시도는 TTM(Translation Table Maps) 메모리 매니저였습니다.Thomas Hellstrom(Tungsten Graphics)은 Emma Anholt(Intel) 및 Dave Airlie(Red Hat)[5]와 공동으로 개발했습니다.TTM은 2007년 [5]11월과 2008년 5월에 메인라인 커널 2.6.25로의 도입을 제안했지만 그래픽스 이그제큐션 매니저(GEM)[24]라고 불리는 새로운 접근방식을 위해 폐지되었습니다.GEM은 인텔의 Keith Packard와 Emma Anholt에 의해 i915 [6]드라이버의 메모리 관리를 위한 단순한 솔루션으로 처음 개발되었습니다.GEM은 호평을 받아 2008년 [124]12월에 출시된 Linux 커널 버전 2.6.28에 통합되었습니다.한편, TTM은 새로운 Rade on KMS [125]DRM 드라이버의 요건으로서 최종적으로 Linux 2.6.31에 통합될 때까지 2009년 9월까지 기다려야 했습니다.

버퍼 오브젝트를 처리하기 위한 메모리 관리를 통해 DRM 개발자는 최종적으로 이미 완료된 API와 코드 투 모드 설정을 커널에 추가할 수 있습니다.이 확장 API는 커널 모드 설정(KMS)이라고 불리며, 이를 구현하는 드라이버는 종종 KMS 드라이버라고 불립니다.2009년 3월에 KMS는 i915 [127]드라이버에 대한 KMS 지원과 함께 Linux 커널 버전 2.6.[30][126]29로 통합되었습니다.KMS API는 libdrm 2.4.[128]3 이후 사용자 공간 프로그램에 노출되어 있습니다.사용자 공간 X.또한 인텔 그래픽 카드용 Org DDX 드라이버는 새로운 GEM 및 KMS API를 [129]최초로 사용했습니다.Rade on DRM 드라이버에 대한 KMS 지원이 2009년 [130][131][132]9월 Linux 2.6.31 릴리즈에 추가되었습니다.새로운 Rade on KMS 드라이버는 TTM 메모리 매니저를 사용했지만 TTM 인터페이스 [23]대신 GEM 호환 인터페이스와 ioctls가 노출되었습니다.

2006년 이후, 누보 프로젝트는 Linux 커널 이외의 NVIDIA GPU용 무료 소프트웨어 DRM 드라이버를 개발하고 있습니다.2010년에 nouveau 소스 코드가 실험 [56][57]드라이버로 Linux 2.6.33에 통합되었습니다.병합 시 드라이버는 이미 KMS로 변환되어 GEM API의 배후에 TTM을 메모리 [133]매니저로 사용하고 있었습니다.

GEM API를 포함한 새로운 KMS API는 DRM 개발에 있어 큰 이정표가 되었지만, 이후 몇 년 동안 API가 향상되는 것을 막지는 못했습니다.KMS는 Linux 2.6.33의[134][135] 비동기 VBLANK 알림과 함께 페이지 플립을 지원하게 되었습니다.i915 드라이버, Radeon 및 nouveau에서만 나중에 Linux 2.6.38 [136]릴리즈에서 페이지 플립이 추가되었습니다.새로운 페이지 플립인터페이스가 libdrm 2.4.[137]17에 추가되었습니다.2011년 초 Linux 2.6.39 릴리즈 사이클 중에 이른바 덤버퍼(하드웨어에 의존하지 않는 비액셀러레이션 방식)가 KMS [138][139]API에 추가되었습니다.그 목적은 드라이버 [140]고유의 ioctl에 의해 제공되는 특별한 고속 조작을 사용할 필요가 없는 Plymouth 등의 애플리케이션의 복잡성을 줄이는 것이었습니다.이 기능은 버전 2.4.25 [141]이후 libdrm에 의해 공개되었습니다.그 해 후반에 그것은 평면이라고 불리는 새로운 주요 유형의 물체도 얻었다.평면은 스캔아웃 [142][143]엔진에서 지원되는 하드웨어 오버레이를 나타내기 위해 개발되었습니다.플레인 지원이 Linux 3.[144]3 및 libdrm 2.4.30으로 통합되었습니다.Linux 3.5 및[145] libdrm 2.4.36[146] 릴리즈 중에 API에 추가된 또 다른 개념은 범용 객체 속성입니다.이는 임의의 KMS 객체에 범용 값을 추가하는 방식입니다.속성은 CRTC 및 평면과 같은 객체에 특별한 동작 또는 기능을 설정하는 데 특히 유용합니다.

DRM 드라이버 간에 GPU 오프로드를 제공하는 초기 개념 증명은 [7][147]2010년에 Dave Airlie에 의해 개발되었습니다.Airlie는 NVIDIA Optimus 테크놀로지를 모방하려고 했기 때문에 [7]PRIME이라는 이름을 붙이기로 결정했습니다.Airlie는 2011년 말에 PRIME에 관한 작업을 재개했지만 Linux 커널 3.[148]3에 의해 도입된 새로운 DMA-BUF 버퍼 공유 메커니즘을 기반으로 합니다.기본적인 DMA-BUF PRIME 인프라스트럭처는 2012년 3월에[149] 완료되어 Linux 3.4 [150][151][152]릴리즈와 libdrm 2.4.[153]34로 통합되었습니다.Linux 3.5 릴리즈에서는 인텔 카드용 i915, AMD 카드용 radeon, NVIDIA [154][155]카드용 nouve 등 여러 DRM 드라이버가 PRIME 지원을 구현했습니다.

최근 몇 년 동안 DRM API는 새로운 기능과 향상된 기능으로 점차 확장되었습니다.2013년, GSoC의 일환으로 David Herrmann은 다중 렌더 노드 [53]기능을 개발했습니다.그의 코드는 [158]i915[159], radeon 및[160] nouveau 드라이버에 의해[156][157] 지원되는 실험적인 기능으로 Linux 커널 버전 3.12에 추가되었으며 Linux 3.17 [75]이후 기본적으로 활성화되었습니다.2014년 Matt Roper(Intel)는 프레임 버퍼(프라이머리 플레인), 오버레이(세컨더리 플레인), 커서(커서 플레인)를 모두 통합 [161]API로 단일 유형의 개체로 취급하는 유니버설 플레인(또는 유니파이드 플레인) 개념을 개발했습니다.유니버설 플레인 지원을 통해 보다 적은 수의 범용 ioctl로 [33]보다 일관된 DRM API를 제공합니다.API의 하위 호환성을 유지하기 위해 이 기능은 DRM 드라이버가 제공할 수 있는 추가 기능으로 DRM 코어에 의해 공개됩니다.유니버설 플레인 지원은 Linux 3.15[162] 및 libdrm 2.4.[163]55에서 처음 도입되었습니다.인텔 i915 [164]등, 복수의 드라이버가 이미 실장하고 있습니다.

최신 DRM API 확장 기능은 원자성 모드 설정 API로, DRM 디바이스에서의 모드 설정 및 페이지 플립 조작에 원자성을 가져옵니다.모드 설정을 위한 원자 API의 아이디어는 2012년 [165]초에 처음 제안되었습니다.Ville Syrjélä (Intel)는 그러한 원자 [166]API의 설계 및 구현 작업을 인계받았다.Rob Clark (Texas Instruments)는 그의 연구를 바탕으로 원자 페이지 [167]플립을 구현하기 위해 유사한 접근법을 취했습니다.이후 2013년에 제안된 두 기능은 두 [168]작업에 대해 단일 ioctl을 사용하여 단일 기능으로 통합되었다.요건이 되었기 때문에,[164] 이 기능은 유니버설 플레인의 지원이 2014년 중반에 통합될 때까지 기다려야 했습니다.2014년 하반기에 Daniel Vetter([170]Intel) 및 기타 DRM 개발자는[169]: 18 기존 KMS 드라이버를 새로운 원자 프레임워크로 쉽게 이행할 수 있도록 원자 코드를 대폭 강화했습니다.이 모든 작업은 최종적으로 Linux[171] 3.19 및 Linux[172][173][174] 4.0 릴리스로 병합되어 Linux 4.2.[175]libdrm이 버전 2.4.62 [176]이후 새로운 atomic API를 공개했기 때문에 기본적으로 활성화되었습니다.여러 드라이버가 이미 새로운 [177]atomic API로 변환되었습니다.2018년까지 이 새로운 원자 모델을 기반으로 한 10개의 새로운 DRM 드라이버가 Linux [178]커널에 추가되었습니다.

도입

Direct Rendering Manager 커널 서브시스템은 처음에 XFree86 4.0 디스플레이 서버의 새로운 Direct Rendering Infrastructure와 함께 사용하도록 개발되었으며, 이후 후속 제품인 X에 상속되었습니다.조직 서버따라서 DRM의 주요 사용자는 Mesa 3D 라이브러리에 존재하는 하드웨어 가속 OpenGL 구현과 X Server 자체에 링크하는 DRI 클라이언트였습니다.오늘날 DRM은 Weston 레퍼런스 컴포지터를 포함한 여러 Wayland 컴포지터에서도 사용되고 있습니다.kmscon은 DRM KMS [179]기능을 사용하여 사용자 공간에서 실행되는 가상 콘솔 구현입니다.

2015년 Nvidia GeForce 드라이버 버전 358.09(베타)는 DRM 모드 설정 인터페이스를 지원받았습니다.nvidia-modeset.ko이 새로운 드라이버 컴포넌트는,nvidia.koGPU의 디스플레이 엔진([180]디스플레이 컨트롤러)을 프로그래밍하는 커널 모듈.

「 」를 참조해 주세요.

레퍼런스

  1. ^ "Linux kernel/drivers/gpu/drm/README.drm". kernel.org. Archived from the original on 2014-02-26. Retrieved 2014-02-26.
  2. ^ a b Uytterhoeven, Geert. "The Frame Buffer Device". Kernel.org. Retrieved 28 January 2015.
  3. ^ a b c White, Thomas. "How DRI and DRM Work". Retrieved 22 July 2014.
  4. ^ Faith, Rickard E. (11 May 1999). "The Direct Rendering Manager: Kernel Support for the Direct Rendering Infrastructure". Retrieved 12 May 2016.
  5. ^ a b c d e f g h Corbet, Jonathan (6 November 2007). "Memory management for graphics processors". LWN.net. Retrieved 23 July 2014.
  6. ^ a b c d e f g Packard, Keith; Anholt, Eric (13 May 2008). "GEM - the Graphics Execution Manager". dri-devel mailing list. Retrieved 23 July 2014.
  7. ^ a b c Airlie, Dave (12 March 2010). "GPU offloading - PRIME - proof of concept". Archived from the original on 10 February 2015. Retrieved 10 February 2015.
  8. ^ a b c d e Kitching, Simon. "DRM and KMS kernel modules". Retrieved 13 May 2016.
  9. ^ a b c d e Herrmann, David (1 September 2013). "Splitting DRM and KMS device nodes". Retrieved 23 July 2014.
  10. ^ "README.rst - mesa/drm - Direct Rendering Manager headers and kernel modules". 2020-03-21. Archived from the original on 2020-03-21.
  11. ^ a b Airlie, Dave (4 September 2004). "New proposed DRM interface design". dri-devel (Mailing list).
  12. ^ a b c d e f g Peres, Martin; Ravier, Timothée (2 February 2013). "DRI-next/DRM2: A walkthrough the Linux Graphics stack and its security" (PDF). Retrieved 13 May 2016.
  13. ^ Høgsberg, Kristian (4 September 2008). "The DRI2 Extension - Version 2.0". X.Org. Retrieved 23 May 2016.
  14. ^ a b c d e f Barnes, Jesse; Pinchart, Laurent; Vetter, Daniel; Wunner, Lukas. "Linux GPU Driver Developer's Guide - Memory management". Retrieved 31 August 2016.
  15. ^ Vetter, Daniel. "i915/GEM Crashcourse by Daniel Vetter". Intel Open Source Technology Center. Retrieved 31 January 2015. GEM essentially deals with graphics buffer objects (which can contain textures, renderbuffers, shaders, or all kinds of other state objects and data used by the gpu)
  16. ^ a b c Vetter, Daniel (4 May 2011). "GEM Overview". Retrieved 13 February 2015.
  17. ^ Packard, Keith (28 September 2012). "Thoughts about DRI.Next". Retrieved 26 May 2016. GEM flink has lots of issues. The flink names are global, allowing anyone with access to the device to access the flink data contents.
  18. ^ a b Herrmann, David (2 July 2013). "DRM Security". The 2013 X.Org Developer's Conference (XDC2013) Proceedings. Retrieved 13 February 2015. gem-flink doesn't provide any private namespaces to applications and servers. Instead, only one global namespace is provided per DRM node. Malicious authenticated applications can attack other clients via brute-force "name-guessing" of gem buffers
  19. ^ Kerrisk, Michael (25 September 2012). "XDC2012: Graphics stack security". LWN.net. Retrieved 25 November 2015.
  20. ^ a b Packard, Keith (4 July 2008). "gem update". Retrieved 25 April 2016.
  21. ^ "drm-memory man page". Ubuntu manuals. Retrieved 29 January 2015. Many modern high-end GPUs come with their own memory managers. They even include several different caches that need to be synchronized during access. [...] . Therefore, memory management on GPUs is highly driver- and hardware-dependent.
  22. ^ "Intel Graphics Media Accelerator Developer's Guide". Intel Corporation. Retrieved 24 November 2015.
  23. ^ a b c Larabel, Michael (26 August 2008). "A GEM-ified TTM Manager For Radeon". Phoronix. Retrieved 24 April 2016.
  24. ^ a b c Corbet, Jonathan (28 May 2008). "GEM v. TTM". LWN.net. Retrieved 10 February 2015.
  25. ^ Corbet, Jonathan (11 January 2012). "DMA buffer sharing in 3.3". LWN.net. Retrieved 14 May 2016.
  26. ^ Clark, Rob; Semwal, Sumit. "DMA Buffer Sharing Framework: An Introduction" (PDF). Retrieved 14 May 2016.
  27. ^ Peres, Martin (26 September 2014). "The Linux graphics stack, Optimus and the Nouveau driver" (PDF). Retrieved 14 May 2016.
  28. ^ Pinchart, Laurent (20 February 2013). "Anatomy of an Embedded KMS Driver" (PDF). Retrieved 27 June 2016.
  29. ^ Edge, Jake (9 October 2013). "DRI3 and Present". LWN.net. Retrieved 28 May 2016.
  30. ^ a b c d "Linux 2.6.29 - Kernel Modesetting". Linux Kernel Newbies. Retrieved 19 November 2015.
  31. ^ "VGA Hardware". OSDev.org. Retrieved 23 November 2015.
  32. ^ Rathmann, B. (15 February 2008). "The state of Nouveau, part I". LWN.net. Retrieved 23 November 2015. Graphics cards are programmed in numerous ways, but most initialization and mode setting is done via memory-mapped IO. This is just a set of registers accessible to the CPU via its standard memory address space. The registers in this address space are split up into ranges dealing with various features of the graphics card such as mode setup, output control, or clock configuration.
  33. ^ a b c d e Paalanen, Pekka (5 June 2014). "From pre-history to beyond the global thermonuclear war". Retrieved 29 July 2014.
  34. ^ "drm-kms man page". Ubuntu manuals. Retrieved 19 November 2015.
  35. ^ Corbet, Jonathan (13 January 2010). "The end of user-space mode setting?". LWN.net. Retrieved 20 November 2015.
  36. ^ a b "Mode Setting Design Discussion". X.Org Wiki. Retrieved 19 November 2015.
  37. ^ a b Corbet, Jonathan (22 January 2007). "LCA: Updates on the X Window System". LWN.net. Retrieved 23 November 2015.
  38. ^ "XF86VIDMODE manual page". X.Org. Retrieved 23 April 2016.
  39. ^ "X11R6.1 Release Notes". X.Org. 14 March 1996. Retrieved 23 April 2016.
  40. ^ Corbet, Jonathan (20 July 2004). "Kernel Summit: Video Drivers". LWN.net. Retrieved 23 November 2015.
  41. ^ a b "Fedora - Features/KernelModeSetting". Fedora Project. Retrieved 20 November 2015. Historically, the X server was responsible for saving output state when it started up, and then restoring it when it switched back to text mode. Fast user switching was accomplished with a VT switch, so switching away from the first user's X server would blink once to go to text mode, then immediately blink again to go to the second user's session.
  42. ^ a b c d e Barnes, Jesse (17 May 2007). "[RFC] enhancing the kernel's graphics subsystem". linux-kernel (Mailing list).
  43. ^ a b c "DrmModesetting - Enhancing kernel graphics". DRI Wiki. Retrieved 23 November 2015.
  44. ^ a b c d e Packard, Keith (16 September 2007). "kernel-mode-drivers". Retrieved 30 April 2016.
  45. ^ a b Packard, Keith (24 April 2000). "Sharpening the Intel Driver Focus". Retrieved 23 May 2016. A more subtle limitation is that the driver couldn't handle interrupts, so there wasn't any hot-plug monitor support.
  46. ^ Barnes, Jesse; Pinchart, Laurent; Vetter, Daniel; Wunner, Lukas. "Linux GPU Driver Developer's Guide - Driver Initialization". Retrieved 31 August 2016.
  47. ^ a b c d e f g Barnes, Jesse; Pinchart, Laurent; Vetter, Daniel; Wunner, Lukas. "Linux GPU Driver Developer's Guide - KMS Initialization and Cleanup". Retrieved 31 August 2016.
  48. ^ a b "Video Cards". X.Org Wiki. Retrieved 11 April 2016.
  49. ^ a b Deucher, Alex (15 April 2010). "Notes about radeon display hardware". Archived from the original on 5 April 2016. Retrieved 8 April 2016.
  50. ^ a b c d e Vetter, Daniel (5 August 2015). "Atomic mode setting design overview, part 1". LWN.net. Retrieved 7 May 2016.
  51. ^ a b Reding, Thierry (1 February 2015). "Atomic Mode-Setting" (PDF). FOSDEM Archives. Retrieved 7 May 2016.
  52. ^ Vetter, Daniel (12 August 2015). "Atomic mode setting design overview, part 2". LWN.net. Retrieved 7 May 2016.
  53. ^ a b c Herrmann, David (29 May 2013). "DRM Render- and Modeset-Nodes". Retrieved 21 July 2014.
  54. ^ a b c d Barnes, Jesse; Pinchart, Laurent; Vetter, Daniel; Wunner, Lukas. "Linux GPU Driver Developer's Guide - Render nodes". Retrieved 31 August 2016.
  55. ^ a b Deucher, Alex (20 April 2015). "Initial amdgpu driver release". dri-devel (Mailing list).
  56. ^ a b "Linux 2.6.33 - Nouveau, a driver for Nvidia graphic cards". Linux Kernel Newbies. Retrieved 26 April 2016.
  57. ^ a b "drm/nouveau: Add DRM driver for NVIDIA GPUs". Kernel.org. Retrieved 27 January 2015.
  58. ^ "DRM: add DRM Driver for Samsung SoC EXYNOS4210". Kernel.org. Retrieved 3 March 2016.
  59. ^ "vmwgfx: Take the driver out of staging". Kernel.org. Retrieved 3 March 2016.
  60. ^ "Linux 3.3 - DriverArch - Graphics". Linux Kernel Newbies. Retrieved 3 March 2016.
  61. ^ Larabel, Michael (10 January 2012). "The Linux 3.3 DRM Pull Is Heavy On Enhancements". Phoronix. Retrieved 3 March 2016.
  62. ^ "drm: Initial KMS driver for AST (ASpeed Technologies) 2000 series (v2)". Kernel.org. Retrieved 3 March 2016.
  63. ^ Airlie, Dave (17 May 2012). "mgag200: initial g200se driver (v2)". Retrieved 24 January 2018.
  64. ^ "drm: Renesas SH Mobile DRM driver". Kernel.org. Retrieved 3 March 2016.
  65. ^ "drm: Add NVIDIA Tegra20 support". Kernel.org. Retrieved 3 March 2016.
  66. ^ "drm/omap: move out of staging". Kernel.org. Retrieved 3 March 2016.
  67. ^ "drm: Renesas R-Car Display Unit DRM driver". Kernel.org. Retrieved 3 March 2016.
  68. ^ "drm/msm: basic KMS driver for snapdragon". Kernel.org. Retrieved 3 March 2016.
  69. ^ Larabel, Michael (28 August 2013). "Snapdragon DRM/KMS Driver Merged For Linux 3.12". Phoronix. Retrieved 26 January 2015.
  70. ^ Edge, Jake (8 April 2015). "An update on the freedreno graphics driver". LWN.net. Retrieved 23 April 2015.
  71. ^ King, Russell (18 October 2013). "[GIT PULL] Armada DRM support". dri-devel (Mailing list).
  72. ^ "DRM: Armada: Add Armada DRM driver". Kernel.org. Retrieved 3 March 2016.
  73. ^ "drm/bochs: new driver". Kernel.org. Retrieved 3 March 2016.
  74. ^ Larabel, Michael (8 August 2014). "Linux 3.17 DRM Pull Brings New Graphics Driver". Phoronix. Retrieved 3 March 2016.
  75. ^ a b Corbet, Jonathan (13 August 2014). "3.17 merge window, part 2". LWN.net. Retrieved 7 October 2014.
  76. ^ a b Corbet, Jonathan (17 December 2014). "3.19 Merge window part 2". LWN.net. Retrieved 9 February 2015.
  77. ^ "drm: imx: Move imx-drm driver out of staging". Kernel.org. Retrieved 9 February 2015.
  78. ^ "drm: rockchip: Add basic drm driver". Kernel.org. Retrieved 3 March 2016.
  79. ^ Larabel, Michael (25 June 2015). "Linux 4.2 DRM Updates: Lots Of AMD Attention, No Nouveau Driver Changes". Phoronix. Retrieved 31 August 2015.
  80. ^ Corbet, Jonathan (1 July 2015). "4.2 Merge window part 2". LWN.net. Retrieved 31 August 2015.
  81. ^ Deucher, Alex (3 August 2015). "[PATCH 00/11] Add Fiji Support". dri-devel (Mailing list).
  82. ^ "Add virtio gpu driver". Kernel.org. Retrieved 3 March 2016.
  83. ^ Corbet, Jonathan (11 November 2015). "4.4 Merge window, part 1". LWN.net. Retrieved 11 January 2016.
  84. ^ Larabel, Michael (15 November 2015). "A Look At The New Features Of The Linux 4.4 Kernel". Phoronix. Retrieved 11 January 2016.
  85. ^ "drm/vc4: Add KMS support for Raspberry Pi". Kernel.org.
  86. ^ "Linux 4.5-DriversArch - Graphics". Linux Kernel Newbies. Retrieved 14 March 2016.
  87. ^ Larabel, Michael (24 January 2016). "The Many New Features & Improvements Of The Linux 4.5 Kernel". Phoronix. Retrieved 14 March 2016.
  88. ^ Corbet, Jonathan (20 January 2016). "4.5 merge window part 2". LWN.Net. Retrieved 14 March 2016.
  89. ^ "Merge tag 'sun4i-drm-for-4.7'". Kernel.org.
  90. ^ a b c Airlie, Dave (23 May 2016). "[git pull] drm for v4.7". dri-devel (Mailing list).
  91. ^ "Merge tag 'drm-hisilicon-next-2016-04-29'". Kernel.org.
  92. ^ "Merge tag 'mediatek-drm-2016-05-09'". Kernel.org.
  93. ^ Larabel, Michael (22 November 2016). "Hisilicon Hibmc DRM Driver Being Added For Linux 4.10". Phoronix. Retrieved 24 January 2018.
  94. ^ "Huawei FusionServer RH5885 V3 Technical White Paper". 18 November 2016. Archived from the original on 2018-01-25. uses an onboard display chip that is integrated into the management chip Hi1710 and uses the IP core of the SM750
  95. ^ "drm/vkms: Introduce basic VKMS driver". git.kernel.org. Retrieved 2022-07-20.
  96. ^ Larabel, Michael (15 August 2018). "Virtual Kernel Mode-Setting Driver Being Added To Linux 4.19". Phoronix. Retrieved 20 July 2022.
  97. ^ "kernel/git/torvalds/linux.git - Linux kernel source tree". git.kernel.org. Retrieved 2019-11-28.
  98. ^ a b c Larabel, Michael (9 May 2019). "Linux 5.2 DRM Makes Icelake Production-Ready, Adds Lima & Panfrost Drivers". Phoronix. Retrieved 20 July 2022.
  99. ^ "kernel/git/torvalds/linux.git - Linux kernel source tree". git.kernel.org. Retrieved 2019-11-28.
  100. ^ "drm/vboxvideo: Move the vboxvideo driver out of staging". git.kernel.org. Retrieved 2022-07-20.
  101. ^ "drm/hyperv: Add DRM driver for hyperv synthetic video device". git.kernel.org. Retrieved 2021-08-30.
  102. ^ Larabel, Michael (9 June 2021). "Microsoft's Hyper-V DRM Display Driver Will Land For Linux 5.14". Phoronix. Retrieved 30 August 2021.
  103. ^ "drm: Add simpledrm driver". git.kernel.org. Retrieved 2021-08-30.
  104. ^ Larabel, Michael (13 May 2021). "Linux 5.14 To Bring SimpleDRM Driver, VC4 HDR, Marks More AGP Code As Legacy". Phoronix. Retrieved 30 August 2021.
  105. ^ "drm: remove the gamma driver". Kernel.org. Retrieved 27 January 2015.
  106. ^ "[DRM]: Delete sparc64 FFB driver code that never gets built". Kernel.org. Retrieved 27 January 2015.
  107. ^ "drm: remove i830 driver". Kernel.org. Retrieved 27 January 2015.
  108. ^ "drm: Add via unichrome support". Kernel.org. Retrieved 27 January 2015.
  109. ^ "drm: add savage driver". Kernel.org. Retrieved 27 January 2015.
  110. ^ "List of maintainers of the linux kernel". Kernel.org. Retrieved 14 July 2014.
  111. ^ "libdrm git repository". Retrieved 23 July 2014.
  112. ^ "First DRI release of 3dfx driver". Mesa 3D. Retrieved 15 July 2014.
  113. ^ "Import 2.3.18pre1". The History of Linux in GIT Repository Format 1992-2010 (2010). Retrieved 15 July 2014.
  114. ^ Torvalds, Linus. "Linux 2.4.0 source code". Kernel.org. Retrieved 29 July 2014.
  115. ^ Airlie, Dave (30 December 2004). "[bk pull] drm core/personality split". linux-kernel (Mailing list).
  116. ^ Torvalds, Linus (11 January 2005). "Linux 2.6.11-rc1". linux-kernel (Mailing list).
  117. ^ Gettys, James; Packard, Keith (15 June 2004). "The (Re)Architecture of the X Window System". Retrieved 30 April 2016.
  118. ^ Smirl, Jon (30 August 2005). "The State of Linux Graphics". Retrieved 30 April 2016. I believe the best solution to this problem is for the kernel to provide a single, comprehensive device driver for each piece of video hardware. This means that conflicting drivers like fbdev and DRM must be merged into a cooperating system. It also means that poking hardware from user space while a kernel based device driver is loaded should be prevented.
  119. ^ Verhaegen, Luc (2 March 2006). "X and Modesetting: Atrophy illustrated" (PDF). Retrieved 30 April 2016.
  120. ^ Glisse, Jerome (4 December 2007). "Radeon kernel modesetting". Retrieved 30 April 2016.
  121. ^ Larabel, Michael (1 October 2008). "The State of Kernel Mode-Setting". Phoronix. Retrieved 30 April 2016.
  122. ^ Packard, Keith (21 July 2008). "X output status july 2008". Retrieved 1 May 2016.
  123. ^ "drm: reorganise drm tree to be more future proof". Kernel.org.
  124. ^ "Linux 2.6.28 - The GEM Memory Manager for GPU memory". Linux Kernel Newbies. Retrieved 23 July 2014.
  125. ^ "drm: Add the TTM GPU memory manager subsystem". Kernel.org.
  126. ^ "DRM: add mode setting support". Kernel.org.
  127. ^ "DRM: i915: add mode setting support". Kernel.org.
  128. ^ Anholt, Eric (22 December 2008). "[ANNOUNCE] libdrm-2.4.3". dri-devel (Mailing list).
  129. ^ Barnes, Jesse (20 October 2008). "[ANNOUNCE] xf86-video-intel 2.5.0". xorg-announce (Mailing list).
  130. ^ "Linux 2.6.31 - ATI Radeon Kernel Mode Setting support". Linux Kernel Newbies. Archived from the original on 5 November 2015. Retrieved 28 April 2016.
  131. ^ Torvalds, Linus (9 September 2009). "Linux 2.6.31". linux-kernel (Mailing list).
  132. ^ "drm/radeon: introduce kernel modesetting for radeon hardware". Kernel.org.
  133. ^ "The irregular Nouveau Development Companion #40". Nouveau project. Retrieved 3 May 2016.
  134. ^ "Linux 2.6.33 - Graphic improvements". Linux Kernel Newbies. Retrieved 28 April 2016.
  135. ^ "drm/kms: add page flipping ioctl". Kernel.org.
  136. ^ "Linux 2.6.38 - Graphics". Linux Kernel Newbies. Retrieved 28 April 2016.
  137. ^ Airlie, Dave (21 December 2009). "[ANNOUNCE] libdrm 2.4.17". dri-devel (Mailing list).
  138. ^ "drm: dumb scanout create/mmap for intel/radeon (v3)". Kernel.org.
  139. ^ "Linux 2 6 39-DriversArch". Linux Kernel Newbies. Retrieved 19 April 2016.
  140. ^ Barnes, Jesse; Pinchart, Laurent; Vetter, Daniel; Wunner, Lukas. "Linux GPU Driver Developer's Guide - Dumb Buffer Objects". Retrieved 31 August 2016.
  141. ^ Wilson, Chris (11 April 2011). "[ANNOUNCE] libdrm 2.4.25". dri-devel (Mailing list).
  142. ^ Barnes, Jesse (25 April 2011). "[RFC] drm: add overlays as first class KMS objects". dri-devel (Mailing list).
  143. ^ Barnes, Jesse (13 May 2011). "[RFC] drm: add overlays as first class KMS objects". dri-devel (Mailing list).
  144. ^ "drm: add plane support v3". Kernel.org.
  145. ^ "drm: add generic ioctls to get/set properties on any object". Kernel.org.
  146. ^ Widawsky, Ben (27 June 2012). "[ANNOUNCE] libdrm 2.4.36". xorg-announce (Mailing list).
  147. ^ Larabel, Michael. "Proof Of Concept: Open-Source Multi-GPU Rendering!". Phoronix. Retrieved 14 April 2016.
  148. ^ Larabel, Michael (23 February 2012). "DRM Base PRIME Support Part Of VGEM Work". Phoronix. Retrieved 14 April 2016.
  149. ^ Airlie, Dave (27 March 2012). "[PATCH] drm: base prime/dma-buf support (v5)". dri-devel (Mailing list).
  150. ^ Larabel, Michael (30 March 2012). "Last Minute For Linux 3.4: DMA-BUF PRIME Support". Phoronix. Retrieved 15 April 2016.
  151. ^ "drm: base prime/dma-buf support (v5)". Kernel.org.
  152. ^ "Linux 3.4 DriverArch". Linux Kernel Newbies. Retrieved 15 April 2016.
  153. ^ Anholt, Eric (10 May 2012). "[ANNOUNCE] libdrm 2.4.34". dri-devel (Mailing list).
  154. ^ Larabel, Michael (12 May 2012). "DMA-BUF PRIME Coming Together For Linux 3.5". Phoronix. Retrieved 15 April 2016.
  155. ^ "Linux 3.5 DriverArch". Linux Kernel Newbies. Retrieved 15 April 2016.
  156. ^ Corbet, Jonathan (11 September 2013). "3.12 merge window, part 2". LWN.net. Retrieved 21 July 2014.
  157. ^ "drm: implement experimental render nodes". Kernel.org.
  158. ^ "drm/i915: Support render nodes". Kernel.org.
  159. ^ "drm/radeon: Support render nodes". Kernel.org.
  160. ^ "drm/nouveau: Support render nodes". Kernel.org.
  161. ^ Roper, Matt (7 March 2014). "[RFCv2 00/10] Universal plane support". dri-devel (Mailing list).
  162. ^ Larabel, Michael (2 April 2014). "Universal Plane Support Set For Linux 3.15". Phoronix. Retrieved 14 April 2016.
  163. ^ Lankhorst, Maarten (25 July 2014). "[ANNOUNCE] libdrm 2.4.55". dri-devel (Mailing list).
  164. ^ a b Vetter, Daniel (7 August 2014). "Neat stuff for 3.17". Retrieved 14 April 2016.
  165. ^ Barnes, Jesse (15 February 2012). "[RFC] drm: atomic mode set API". dri-devel (Mailing list).
  166. ^ Syrjälä, Ville (24 May 2012). "[RFC][PATCH 0/6] WIP: drm: Atomic mode setting idea". dri-devel (Mailing list).
  167. ^ Clark, Rob (9 September 2012). "[RFC 0/9] nuclear pageflip". dri-devel (Mailing list).
  168. ^ Clark, Rob (6 October 2013). "[RFCv1 00/12] Atomic/nuclear modeset/pageflip". dri-devel (Mailing list).
  169. ^ Vetter, Daniel (3 February 2016). "Embrace the Atomic Display Age" (PDF). Retrieved 4 May 2016.
  170. ^ Vetter, Daniel (2 November 2014). "Atomic Modeset Support for KMS Drivers". Retrieved 4 May 2016.
  171. ^ Airlie, Dave (14 December 2014). "[git pull] drm for 3.19-rc1". dri-devel (Mailing list).
  172. ^ Vetter, Daniel (28 January 2015). "Update for Atomic Display Updates". Retrieved 4 May 2016.
  173. ^ Airlie, Dave (15 February 2015). "[git pull] drm pull for 3.20-rc1". dri-devel (Mailing list).
  174. ^ "Linux 4.0 - DriverArch - Graphics". Linux Kernel Newbies. Retrieved 3 May 2016.
  175. ^ "Linux 4.2 - Atomic modesetting API enabled by default". Linux Kernel Newbies. Retrieved 3 May 2016.
  176. ^ Velikov, Emil (29 June 2015). "[ANNOUNCE] libdrm 2.4.62". dri-devel (Mailing list).
  177. ^ Vetter, Daniel (6 June 2016). "Awesome Atomic Advances". Retrieved 7 June 2016. right now there's 17 drivers supporting atomic modesetting merged into the DRM subsystem
  178. ^ Stone, Daniel (20 March 2018). "A new era for Linux's low-level graphics - Part 1". Retrieved 5 May 2018.
  179. ^ Herrmann, David (10 December 2012). "KMSCON Introduction". Retrieved 22 November 2015.
  180. ^ "Linux, Solaris, and FreeBSD driver 358.09 (beta)". 2015-12-10.

External links