ダイレクトレンダリングマネージャー
ダイレクトレンダリングマネージャー
原作者kernel.orgとfreedesktop.org
開発者kernel.orgとfreedesktop.org
書かれたC
タイプ
ライセンス
Webサイトドリ.freedesktop .org /wiki /DRM

ダイレクトレンダリングマネージャ（DRM ）は、 Linuxカーネルのサブシステムであり、最新のビデオカードのGPUとのインターフェースを担っています。DRMは、ユーザー空間プログラムがGPUにコマンドやデータを送信し、ディスプレイのモード設定などの操作を実行するために使用できるAPIを公開しています。DRMは当初、 Xサーバーのダイレクトレンダリングインフラストラクチャのカーネル空間コンポーネントとして開発されましたが、[ 1 ]その後、Waylandなどの他のグラフィックスタックの代替手段や、 SDL2やKodiなどのスタンドアロンアプリケーションやライブラリでも使用されています。

ユーザー空間プログラムは、DRM API を使用して GPU にハードウェア アクセラレーションによる3D レンダリングとビデオ デコード、およびGPGPU コンピューティングを実行するよう指示できます。

概要

Linuxカーネルには既にfbdevというAPIがあり、グラフィックアダプタのフレームバッファの管理に使用されていましたが[ 2 ]、これでは最新の3Dアクセラレーション対応GPUベースのビデオハードウェアのニーズに対応できませんでした。これらのデバイスは通常、 GPUにコマンドをディスパッチするために独自のメモリ内にコマンドキューを設定して管理する必要があり、そのメモリ内のバッファと空き領域の管理も必要です。[ 3 ]当初は、ユーザー空間プログラム（ Xサーバーなど）がこれらのリソースを直接管理していましたが、通常は自分だけがそれらにアクセスできるかのように動作していました。2つ以上のプログラムが同時に同じハードウェアを制御し、それぞれ独自の方法でリソースを設定しようとすると、ほとんどの場合、悲惨な結果に終わりました。[ 3 ]

DRMなしでビデオカードにアクセス
DRMなし
DRM付きビデオカードへのアクセス
DRM付き
DRM により、衝突を回避しながら複数のプログラムが 3D ビデオ カードに同時にアクセスできるようになります。

ダイレクト・レンダリング・マネージャ（DRM）は、複数のプログラムがビデオハードウェアリソースを協調的に使用できるようにするために開発されました。[ 4 ] DRMはGPUへの排他的アクセスを取得し、コマンドキュー、メモリ、その他のハードウェアリソースの初期化と管理を担当します。GPUの使用を希望するプログラムはDRMにリクエストを送信し、DRMは仲裁役として機能し、競合の可能性を回避します。

DRMの適用範囲は長年にわたり拡大され、フレームバッファの管理とモード設定、メモリ共有オブジェクト、メモリ同期など、以前はユーザー空間プログラムが処理していた機能もカバーするようになりました。[ 5 ] [ 6 ]これらの拡張の一部には、Graphics Execution Manager（GEM）やカーネルモード設定（KMS）といった固有の名称が付けられており、それらが提供する機能が具体的に言及される場合には、これらの用語が用いられます。しかし、実際にはそれらはカーネルDRMサブシステム全体の一部です。

コンピュータに2つのGPU（ディスクリートGPUと統合型GPU）を搭載するというトレンドは、GPU切り替えなどの新たな問題を引き起こし、DRMレイヤーでも解決する必要が生じました。NVIDIA Optimusテクノロジーに対応するため、DRMにはPRIMEと呼ばれるGPUオフロード機能が搭載されました。[ 7 ]

ソフトウェアアーキテクチャ

Linuxカーネルのダイレクトレンダリングマネージャを使用して3Dアクセラレーショングラフィックカードにアクセスするプロセス

ダイレクトレンダリングマネージャはカーネル空間に常駐するため、ユーザー空間プログラムはカーネルシステムコールを使用してそのサービスを要求する必要があります。ただし、DRM は独自のカスタマイズされたシステムコールを定義していません。代わりに、階層の下のデバイスファイルを使用して、ファイルシステムの名前空間を通じてGPUを公開するという、 Unixの「すべてがファイルである」という原則に従います。DRM によって検出された各 GPU はDRM デバイスと呼ばれ、デバイスファイル( Xは連番) が作成され、その GPU とインターフェイスします。[ 8 ] [ 9 ] GPU と通信するユーザー空間プログラムは、このファイルを開き、 ioctl呼び出しを使用して DRM と通信する必要があります。さまざまな ioctl は、DRM APIのさまざまな機能に対応しています。 /dev/dev/dri/cardX

libdrmと呼ばれるライブラリは、ユーザー空間プログラムとDRMサブシステムとのインターフェースを容易にするために作成されました。このライブラリは、 DRM APIのすべてのioctlに対応するC言語で書かれた関数、定数、構造体、その他のヘルパー要素を提供するラッパーです。 [ 10 ] libdrmを使用すると、カーネルインターフェースがアプリケーションに直接公開されることが回避されるだけでなく、プログラム間でコードを再利用・共有できるという一般的な利点も得られます。

Direct Rendering Manager のアーキテクチャの詳細: libdrm によってインターフェースされる DRM コアと DRM ドライバー (GEM と KMS を含む)

DRM は、汎用の「DRM コア」と、サポートされるハードウェアの種類ごとに固有の「DRM ドライバ」の 2 つの部分で構成されています。[ 11 ] DRM コアは、さまざまな DRM ドライバが登録できる基本的なフレームワークを提供し、共通のハードウェアに依存しない機能を備えた最小限の ioctl セットをユーザー空間に提供します。[ 8 ]一方、DRM ドライバは、サポートする GPU の種類に固有の API のハードウェア依存部分を実装します。DRM コアでカバーされていない残りの ioctl の実装を提供する必要がありますが、API を拡張して、そのようなハードウェアでのみ利用可能な追加機能を備えた追加の ioctl を提供することもできます。[ 8 ]特定の DRM ドライバが拡張 API を提供する場合、ユーザー空間 libdrm も、ユーザー空間で追加の ioctl とのインターフェイスとして使用できる 追加のライブラリ libdrm- driverによって拡張されます。

API

DRMコアは、ユーザー空間アプリケーション向けに複数のインターフェースをエクスポートします。これらは通常、対応するlibdrmラッパー関数を介して使用されることを目的としています。さらに、ドライバは、ioctlおよびsysfsファイルを介して、ユーザー空間ドライバおよびデバイス対応アプリケーションが使用するデバイス固有のインターフェースをエクスポートします。外部インターフェースには、メモリマッピング、コンテキスト管理、DMA操作、AGP管理、vblank制御、フェンス管理、メモリ管理、出力管理などがあります。

DRMマスターとDRM認証

DRM APIには、セキュリティ上の理由または同時実行の問題により、デバイスごとに1つのユーザー空間プロセスによって使用されるように制限する必要がある操作（ioctl）がいくつかあります。[ 8 ]この制限を実装するために、DRMでは、このようなioctlが、通常DRM-Masterと呼ばれるDRMデバイスの「マスター」と見なされるプロセスによってのみ呼び出されるように制限しています。デバイスノードを開いているすべてのプロセスのうち、SET_MASTER ioctlを最初に呼び出したプロセスだけが、ファイルハンドルをマスターとしてマークされます。DRM-Masterでない場合、これらの制限されたioctlのいずれかを使用しようとすると、エラーが返されます。プロセスは、 DROP_MASTER ioctlを呼び出すことによってマスターの役割を放棄し、別のプロセスにその役割を取得させることもできます。 /dev/dri/cardX

Xサーバー(またはその他のディスプレイ サーバー)は、通常、起動時に対応するデバイス ノードを開いたときに、管理するすべての DRM デバイスで DRM マスター ステータスを取得し、終了するか停止するまでグラフィカル セッション全体にわたってこれらの権限を保持するプロセスです。

残りのユーザー空間プロセスには、DRMデバイス上で制限された操作を実行する権限を取得する別の方法があり、これはDRM-Authと呼ばれます。これは基本的に、プロセスがDRMマスターから権限の取得を承認されていることをDRMデバイスに対して証明するための認証方法です。この手順は以下のとおりです。[ 12 ] : 13

  • クライアントはGET_MAGIC ioctlを使用してDRMデバイスから一意のトークン（32ビット整数）を取得し、何らかの手段（通常は何らかのIPC。例えばDRI2では、どのXクライアントもXサーバーに送信できるDRI2Authenticateリクエストがあります。 [ 13 ]）でそれをDRMマスタープロセスに渡します。
  • DRM マスター プロセスは、AUTH_MAGIC ioctl を呼び出してトークンを DRM デバイスに送り返します。
  • デバイスは、認証トークンが DRM マスターから受信したトークンと一致するプロセス ファイル ハンドルに特別な権限を付与します。

グラフィックス実行マネージャー

ビデオメモリの増大とOpenGLなどのグラフィックスAPIの複雑化により、コンテキストスイッチごとにグラフィックスカードの状態を再初期化する戦略は、パフォーマンス面でコストがかかりすぎました。また、現代のLinuxデスクトップでは、オフスクリーンバッファを合成マネージャと共有するための最適な方法が必要でした。これらの要件により、カーネル内でグラフィックスバッファを管理する新しい手法が開発されました。これらの手法の一つとして、 Graphics Execution Manager（GEM）が登場しました。[ 6 ]

GEMは明示的なメモリ管理プリミティブを備えたAPIを提供します。[ 6 ] GEMを介して、ユーザー空間プログラムはGPUビデオメモリ内に存在するメモリオブジェクトを作成、処理、および破棄できます。これらのオブジェクトは「GEMオブジェクト」と呼ばれ、[ 14 ]ユーザー空間プログラムの観点からは永続的であり、プログラムがGPUの制御を取り戻すたびに再ロードする必要はありません。ユーザー空間プログラムがビデオメモリのチャンク（フレームバッファ、テクスチャ、またはGPUに必要なその他のデータを格納するため[ 15 ]）を必要とする場合、GEM APIを使用してDRMドライバに割り当てを要求します。DRMドライバは使用済みのビデオメモリを追跡し、空きメモリがある場合は要求に応じることができます。その後の操作で割り当てられたメモリを参照できるように、ユーザー空間に「ハンドル」を返します。[ 6 ] [ 14 ] GEM APIは、バッファにデータを追加したり、不要になったときに解放したりする操作も提供します。解放されていないGEMハンドルのメモリは、ユーザー空間プロセスがDRMデバイスファイル記述子を意図的にまたは終了したために閉じたときに回復されます。[ 16 ]

GEM では、同じ DRM デバイス (つまり同じ DRM ドライバー) を使用する2 つ以上のユーザー空間プロセスが、GEM オブジェクトを共有することもできます。 [ 16 ] GEM ハンドルはプロセスに一意の 32 ビットのローカル整数ですが、他のプロセスでは繰り返し可能なため、共有には適していません。必要なのはグローバル名前空間であり、GEM はGEM 名と呼ばれるグローバル ハンドルの使用によりそれを提供します。GEM 名は、一意の 32 ビット整数を使用して、同じ DRM ドライバーによって同じ DRM デバイス内に作成された 1 つの GEM オブジェクトのみを参照します。GEM は、GEM ハンドルから GEM 名を取得する操作flinkを提供します。 [ 16 ] [ 12 ] : 16 プロセスは、使用可能な任意のIPCメカニズムを使用して、この GEM 名 (32 ビット整数) を別のプロセスに渡すことができます 。[ 12 ] : 15

残念ながら、GEM名を使用してバッファを共有することは安全ではありません。[ 12 ] : 16 [ 17 ] [ 18 ]同じDRMデバイスにアクセスする悪意のあるサードパーティのプロセスは、32ビット整数を調べるだけで、他の2つのプロセスによって共有されているバッファのGEM名を推測しようとする可能性があります。[ 19 ] [ 18 ] GEM名が見つかると、その内容にアクセスして変更することができ、バッファの情報の機密性と整合性が侵害されます。この欠点は、 DMA-BUFサポートがDRMに導入されたことで後に克服されました。DMA-BUFは、ユーザー空間のバッファをファイル記述子として表現し、安全に共有できるためです。

ビデオメモリ管理システムにとって、ビデオメモリ空間の管理に加えて重要なタスクは、GPUとCPU間のメモリ同期の処理です。現在のメモリアーキテクチャは非常に複雑で、通常、システムメモリ、そして場合によってはビデオメモリにも、様々なレベルのキャッシュが存在します。そのため、ビデオメモリマネージャは、CPUとGPU間で共有されるデータの一貫性を確保するために、キャッシュの一貫性も管理する必要があります。 [ 20 ]これは、ビデオメモリ管理の内部構造がGPUとメモリアーキテクチャのハードウェアの詳細に大きく依存し、ドライバ固有のものになることが多いことを意味します。[ 21 ]

GEMは当初、Intelのエンジニアによってi915ドライバ用のビデオメモリマネージャを提供するために開発されました。[ 20 ] Intel GMA 9xxファミリは、Uniform Memory Architecture（UMA）を備えた統合GPUであり、GPUとCPUが物理メモリを共有し、専用のVRAMはありません。[ 22 ] GEMはメモリ同期のための「メモリドメイン」を定義しており、これらのメモリドメインはGPUに依存しませんが、[ 6 ] UMAメモリアーキテクチャを念頭に設計されているため、独立したVRAMを備えたメモリアーキテクチャなど、他のメモリアーキテクチャには適していません。このため、他のDRMドライバはユーザー空間プログラムにGEM APIを公開することを決定しましたが、内部的には特定のハードウェアとメモリアーキテクチャに適した別のメモリマネージャを実装していました。[ 23 ]

GEM APIは実行フロー（コマンドバッファ）を制御するためのioctlも提供していますが、これらはIntel固有のものであり、Intel i915以降のGPUで使用されます。[ 6 ]他のDRMドライバは、メモリ管理特有のioctlを超えてGEM APIのいかなる部分も実装しようとはしていません。

翻訳テーブルマップ

変換テーブルマップ(TTM) は、GEM より前に開発された GPU 用の汎用メモリマネージャの名前です。[ 5 ] [ 14 ]これは、専用のビデオ RAM (通常ビデオカードにインストールされる) やグラフィックス アドレス リマッピング テーブル(GART)と呼ばれるI/O メモリ管理ユニットを介してアクセス可能なシステム メモリなど、GPU がアクセスする可能性のあるさまざまな種類のメモリを管理するために特別に設計されました。[ 5 ] TTM は、CPU によって直接アドレス指定できないビデオ RAM の部分も処理し、通常、ユーザー空間グラフィックス アプリケーションが大量のビデオ データで作業することを考慮して、可能な限り最高のパフォーマンスで処理する必要があります。もう 1 つの重要な点は、関連するさまざまなメモリとキャッシュ間の一貫性を維持することでした。

TTMの主な概念は「バッファオブジェクト」、つまりGPUがアドレス指定可能でなければならないビデオメモリ領域である。[ 5 ]ユーザー空間グラフィックスアプリケーションが特定のバッファオブジェクトにアクセスしたい場合（通常はコンテンツを埋めるため）、TTMではCPUがアドレス指定可能なメモリへの再配置が必要となる場合がある。GPUがバッファオブジェクトにアクセスする必要があるが、そのオブジェクトがまだGPUのアドレス空間に存在しない場合、さらなる再配置（GARTマッピング操作）が発生する可能性がある。これらの再配置操作はそれぞれ、関連するデータやキャッシュの一貫性の問題を処理する必要がある。[ 5 ]

TTMのもう一つの重要な概念はフェンスです。フェンスは本質的にCPUとGPU間の同時実行性を管理するためのメカニズムです。[ 24 ]フェンスはバッファオブジェクトがGPUによって使用されなくなったことを追跡し、通常はそのバッファオブジェクトにアクセスできるユーザー空間プロセスに通知します。[ 5 ]

TTM が、専用 VRAM の有無にかかわらず、あらゆる種類のメモリ アーキテクチャを適切に管理し、あらゆる種類のハードウェアで使用するためにメモリ マネージャで考えられるすべての機能を提供しようとしたことにより、必要以上に大きな API を持つ過度に複雑なソリューションが生まれました。[ 24 ] [ 14 ] DRM 開発者の中には、特定のドライバ、特に API には適合しないと考える人もいました。よりシンプルなメモリ マネージャとして GEM が登場したとき、その API が TTM のものより好まれました。しかし、ドライバ開発者の中には、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をエクスポータ、ユーザ（コンシューマ）、またはその両方として実装できます。

この機能は、DMA-BUFを使用してディスクリートGPUと統合GPUのDRMドライバー間で結果のフレームバッファーを共有するGPUオフロードのソリューションであるPRIMEを実装するためにDRMで初めて利用されました。 [ 27 ] : 13 DMA-BUFの重要な機能は、共有バッファーがファイル記述子としてユーザー空間に提示されることです。[ 14 ] [ 12 ] : 17 PRIMEの開発では、2つの新しいioctlがDRM APIに追加されました。1つはローカルGEMハンドルをDMA-BUFファイル記述子に変換し、もう1つはまったく逆の操作を行います。

これら 2 つの新しい ioctl は、後に GEM バッファー共有の固有の危険性を修正する方法として再利用されました。[ 12 ] : 17 GEM 名とは異なり、ファイル記述子は推測できず (グローバル名前空間ではない)、Unix オペレーティングシステムはSCM_RIGHTS セマンティクスを使用してUnix ドメインソケットを介してそれらを渡す安全な方法を提供しています。 [ 14 ] [ 28 ] : 11 GEM オブジェクトを別のプロセスと共有するプロセスは、ローカル GEM ハンドルを DMA-BUF ファイル記述子に変換して受信者に渡すことができ、受信者は受信したファイル記述子から独自の GEM ハンドルを取得できます。[ 12 ] : 16 この方法は、 DRI3がクライアントと X サーバーの間でバッファーを共有するために使用します[ 29 ]また、Waylandでも使用されます。

カーネルモード設定

ユーザー空間には「DRM マスター」が存在する必要があり、このプログラムは KMS に排他的にアクセスできます。

ビデオカードまたはグラフィックスアダプタが正常に動作するには、画面解像度、色深度、リフレッシュレートの組み合わせであるモードを、カードまたはアダプタ自体と接続されたディスプレイ画面でサポートされている値の範囲内に設定する必要があります。この操作はモード設定と呼ばれ、[ 30 ]グラフィックスハードウェアへの生のアクセス、つまりビデオカードのディスプレイコントローラの特定のレジスタに書き込む機能が必要になります。[ 31 ] [ 32 ]モード設定操作は、フレームバッファの使用を開始する前、およびアプリケーションやユーザーがモードを変更する必要がある場合に実行する必要があります。

初期の頃は、グラフィカル フレーム バッファを使用するユーザ空間プログラムは、モード設定操作の提供も担当していました。 [ 3 ]そのため、これらのプログラムはビデオ ハードウェアへの特権アクセスで実行する必要がありました。Unix 系のオペレーティング システムでは、X サーバが最も顕著な例でした。モード設定の実装は、各特定のビデオ カード タイプのDDX ドライバ内にありました。 [ 33 ]このアプローチは、後にユーザ空間モード設定(UMS)と呼ばれるようになりましたが、 [ 34 ] [ 35 ]いくつかの問題を引き起こします。[ 36 ] [ 30 ]これは、オペレーティング システムがプログラムとハードウェアの間に提供すべき分離を破壊し、安定性とセキュリティの両方の懸念を引き起こすだけでなく、2 つ以上のユーザ空間プログラムが同時にモード設定を行おうとすると、グラフィックス ハードウェアが不整合な状態になる可能性もあります。これらの競合を回避するために、X サーバは、事実上、モード設定操作を実行する唯一のユーザ空間プログラムになりました。残りのユーザー空間プログラムは、適切なモードの設定やモード設定に関わるその他の操作をXサーバーに依存していました。当初、モード設定はXサーバーの起動プロセス中にのみ行われていましたが、後にXサーバーは動作中にもモード​​設定を行えるようになりました。[ 37 ] XFree86-VidModeExtension拡張機能は、 XFree86 3.1.2で導入され、XクライアントがXサーバーにモデルライン（解像度）の変更を要求できるようになりました。[ 38 ] [ 39 ] VidMode拡張機能は、後に、より汎用的なXRandR拡張機能に置き換えられました。

しかし、これはLinuxシステムでモード設定を行う唯一のコードではありませんでした。システムのブートプロセス中に、Linuxカーネルは仮想コンソールの最小限のテキストモードを設定する必要があります（ VESA BIOS拡張で定義された標準モードに基づいて）。[ 40 ]また、Linuxカーネルのフレームバッファドライバには、フレームバッファデバイスを構成するためのモード設定コードが含まれていました。[ 2 ]モード設定の競合を回避するために、XFree86サーバ（後にX.Orgサーバ）は、ユーザーがグラフィカル環境からテキスト仮想コンソールに切り替えた場合に、モード設定状態を保存し、ユーザーがXに戻ったときにそれを復元することで対応しました。[ 41 ]このプロセスは、遷移時に厄介なちらつきを引き起こし、失敗する可能性があり、出力表示が壊れたり使用できなくなったりする可能性があります。[ 42 ]

ユーザー空間モード設定アプローチは他の問題も引き起こした: [ 43 ] [ 42 ]

  • サスペンド/レジュームプロセスは、以前のモードを復元するためにユーザー空間ツールに頼らなければなりません。これらのプログラムの1つに障害が発生したりクラッシュしたりすると、モードセットの設定ミスによりシステムのディスプレイが機能しなくなり、使用不能になる可能性があります。
  • また、画面がグラフィック モードになっているとき (たとえば、X の実行中) は、カーネルが認識できるモードが VESA BIOS 標準テキスト モードだけであったため、カーネルがエラー メッセージやデバッグ メッセージを表示することも不可能でした。
  • さらに差し迫った問題は、X サーバーをバイパスするグラフィカル アプリケーションの急増と、X に代わる他のグラフィック スタックの出現により、システム全体でモード設定コードの重複がさらに拡大したことです。

これらの問題に対処するため、モード設定コードはカーネル内の1か所、具体的には既存のDRMモジュールに移動されました。[ 36 ] [ 37 ] [ 44 ] [ 42 ] [ 43 ]これにより、Xサーバーを含むすべてのプロセスがカーネルにモード設定操作の実行を指示できるようになり、カーネルは同時実行によって不整合な状態が発生しないようにします。これらのモード設定操作を実行するためにDRMモジュールに追加された新しいカーネルAPIとコードは、カーネルモード設定（KMS）と呼ばれました。[ 30 ]

カーネルモード設定にはいくつかの利点がある。最も直接的な利点は、もちろん、カーネル (Linux コンソール、fbdev) とユーザー空間 (X サーバー DDX ドライバー) の両方から重複したモード設定コードが削除されることだ。KMS により、独自のモード設定コードを実装する必要がなくなるため、代替グラフィックシステムの作成も容易になる。[ 42 ] [ 43 ]集中モード管理を提供することにより、KMS は、コンソールと X の間、および X の異なるインスタンス間 (高速ユーザー切り替え) を切り替えるときに発生するちらつきの問題を解決します。[ 41 ] [ 44 ]これはカーネル内で使用できるため、ブートプロセスの開始時にも使用でき、これらの初期段階でのモード変更によるちらつきを防ぎます。

KMS がカーネルの一部であるという事実は、割り込みなどのカーネル空間でのみ利用可能なリソースを KMS が使用することを可能にする。[ 45 ]たとえば、サスペンド/レジュームプロセス後のモード回復はカーネル自体によって管理されることによって大幅に簡素化され、付随的にセキュリティも向上する（ルート権限を必要とするユーザー空間ツールがなくなる）。 また、カーネルは新しいディスプレイデバイスのホットプラグを容易にし、長年の問題を解決している。[ 45 ]モード設定はメモリ管理とも密接に関連している（フレームバッファは基本的にメモリバッファであるため）ため、グラフィックスメモリマネージャとの緊密な統合が強く推奨される。 これが、カーネルモード設定コードが独立したサブシステムとしてではなく DRM に組み込まれた主な理由である。[ 44 ]

DRM APIの下位互換性を損なわないように、カーネルモード設定は特定のDRMドライバの追加ドライバ機能として提供されています。 [ 46 ]すべてのDRMドライバは、DRMコアに登録するときにDRIVER_MODESETフラグを提供して、KMS APIをサポートしていることを示すことができます。[ 8 ]カーネルモード設定を実装するドライバは、KMSのない従来のDRMドライバと区別するために、 KMSドライバと呼ばれることがよくあります。

KMSは、3Dアクセラレーションが欠けている（またはハードウェアベンダーがそれを公開または実装したくない）特定のドライバーでも、DRM APIの残りの部分なしでKMS APIを実装し、ディスプレイサーバー（Waylandなど）を簡単に実行できるほどに採用されています。[ 47 ] [ 48 ]

KMSデバイスモデル

KMSは、ディスプレイコントローラのディスプレイ出力パイプラインに一般的に見られる一連の抽象的なハードウェアブロックとして出力デバイスをモデル化し、管理します。これらのブロックは以下のとおりです。[ 49 ]

  • CRTC : 各CRTC（CRTコントローラ[ 50 ] [ 33 ]）は、ディスプレイコントローラのスキャンアウトエンジンを表し、スキャンアウトバッファ（フレームバッファ）を指します。[ 49 ] CRTCの目的は、スキャンアウトバッファに現在あるピクセルデータを読み取り、PLL回路を使用してビデオモードタイミング信号を生成することです。[ 51 ]利用可能なCRTCの数によって、ハードウェアが同時に処理できる独立した出力デバイスの数が決まるため、マルチヘッド構成を使用するには、ディスプレイデバイスごとに少なくとも1つのCRTCが必要です。[ 49 ] 2つ以上のCRTCが同じフレームバッファからスキャンアウトして同じ画像を複数の出力デバイスに送信する場合、クローンモードで動作することもできます。 [ 51 ] [ 50 ]
  • コネクタ：コネクタは、ディスプレイコントローラがスキャンアウト操作からビデオ信号を送信して表示する場所を表します。通常、KMSの概念であるコネクタは、ハードウェア上の物理的なコネクタ（VGA、DVI、FPD-Link、HDMI、DisplayPort、S-Videoなど）に対応し、出力デバイス（モニター、ラップトップパネルなど）が恒久的または一時的に接続される場所です。現在物理的に接続されている出力デバイスに関する情報（接続状態、EDIDデータ、DPMS状態、サポートされているビデオモードなど）もコネクタに保存されます。[ 49 ]
  • エンコーダ: ディスプレイコントローラは、CRTCからのビデオモードタイミング信号を、対象のコネクタに適したフォーマットでエンコードする必要があります。[ 49 ]エンコーダは、これらのエンコードのいずれかを実行できるハードウェアブロックを表します。エンコードの例としては、デジタル出力の場合、TMDSやLVDSなどがあります。VGAやTV出力などのアナログ出力の場合は、通常、専用のDACブロックが使用されます。コネクタは一度に1つのエンコーダからの信号しか受信できません。 [ 49 ]また、各タイプのコネクタは一部のエンコードのみをサポートします。また、すべてのCRTCがすべての利用可能なエンコーダに接続されるわけではないという追加の物理的な制約があり、CRTC-エンコーダ-コネクタの組み合わせが制限される場合もあります。
  • プレーン：プレーンはハードウェアブロックではなく、スキャンアウトエンジン（CRTC）に供給されるバッファを含むメモリオブジェクトです。フレームバッファを保持するプレーンはプライマリプレーンと呼ばれ、各CRTCには必ずプライマリプレーンが関連付けられています。[ 49 ]これは、CRTCがビデオモード（ディスプレイ解像度（幅と高さ）、ピクセルサイズ、ピクセルフォーマット、リフレッシュレートなど）を決定するための情報源となるためです。ディスプレイコントローラがハードウェアカーソルオーバーレイをサポートしている場合、CRTCにはカーソルプレーンが関連付けられている場合があります。また、追加のハードウェアオーバーレイからスキャンアウトし、出力デバイスに送信される最終画像を「オンザフライ」で合成またはブレンドできる場合は、セカンダリプレーンが関連付けられている場合があります。 [ 33 ]

アトミックディスプレイ

近年、KMS APIに関連するいくつかの通常の操作、具体的にはモード設定とページ反転操作にアトミック性をもたらす取り組みが続けられています。[ 33 ] [ 52 ]この強化されたKMS APIは、アトミックディスプレイ（以前はアトミックモード設定とアトミックまたはニュークロページフリップと呼ばれていました）と呼ばれています。

アトミックモード設定の目的は、不整合または無効なビデオ状態につながる可能性のある中間ステップを回避することにより、複数の制約がある複雑な構成でモードの正しい変更を確実にすることです。[ 52 ]また、失敗したモード設定プロセスを元に戻す（「ロールバック」）必要がある場合にも、危険なビデオ状態を回避します。[ 53 ]：9 アトミックモード設定は、モードテスト機能を提供することにより、特定のモード構成が適切かどうかを事前に知ることができます。[ 52 ]アトミックモードがテストされ、その有効性が確認されると、単一の分割できない（アトミック）コミット操作で適用できます。テスト操作とコミット操作はどちらも、異なるフラグを持つ同じ新しいioctlによって提供されます。

一方、アトミックページフリップでは、同じ出力上の複数のプレーン（たとえば、プライマリプレーン、カーソルプレーン、場合によってはいくつかのオーバーレイまたはセカンダリプレーン）をすべて同じVBLANK間隔内で同期して更新できるため、ティアリングのない適切な表示が保証されます。[ 53 ]：9,14 [ 52 ]この要件は、電力を節約するために複数のプレーン/オーバーレイを使用する傾向があるモバイルおよび組み込みディスプレイコントローラーに特に関連しています。

新しいアトミックAPIは、古いKMS APIをベースに構築されています。同じモデルとオブジェクト（CRTC、エンコーダ、コネクタ、プレーンなど）を使用しますが、変更可能なオブジェクトプロパティの数が増えています。[ 52 ]アトミック手順は、テストまたはコミットする状態を構築するために、関連するプロパティを変更することに基づいています。変更するプロパティは、モード設定（主にCRTC、エンコーダ、コネクタのプロパティ）を行うか、ページ反転（通常はプレーンのプロパティ）を行うかによって異なります。ioctlはどちらの場合も同じですが、それぞれに渡されるプロパティのリストが異なります。[ 54 ]

レンダリングノード

オリジナルのDRM APIでは、DRMデバイスは特権操作（モード設定、その他のディスプレイ制御）と非特権操作（レンダリング、 GPGPU計算）の両方に使用されます。 [ 9 ]セキュリティ上の理由から、関連するDRMデバイスファイルを開くには、「ルート権限と同等」の特別な権限が必要です。[ 55 ]これにより、信頼性の高いユーザー空間プログラム（Xサーバー、グラフィカルコンポジターなど）のみが、モード設定APIなどの特権部分を含むDRM APIに完全にアクセスできるアーキテクチャが実現します。レンダリングやGPGPU計算を行うその他のユーザー空間アプリケーションには、DRMデバイスの所有者（「DRMマスター」）が特別な認証インターフェースを使用してアクセスを許可する必要があります。[ 56 ]これにより、認証されたアプリケーションは、特権操作なしでDRM APIの制限されたバージョンを使用してレンダリングや計算を行うことができます。この設計には厳しい制約が課せられます。GPGPU計算のようにグラフィックス表示を伴わない場合でも、他のユーザー空間プログラムにデバイスの使用を許可できるように、DRMデバイスのDRMマスターとして機能するグラフィックスサーバー（Xサーバー、Waylandコンポジターなど）が常に実行されている必要があります。[ 55 ] [ 56 ]/dev/dri/cardX

「レンダーノード」というコンセプトは、DRMユーザー空間APIを2つのインターフェース（1つは特権インターフェース、もう1つは非特権インターフェース）に分割し、それぞれに別々のデバイスファイル（または「ノード」）を使用することで、これらのシナリオを解決しようとします。[ 9 ]検出されたGPUごとに、対応するDRMドライバー（レンダーノード機能をサポートしている場合）は、プライマリノードに加えて、レンダーノードと呼ばれるデバイスファイルを作成します。[ 56 ] [ 9 ]ダイレクトレンダリングモデルを使用するクライアントや、GPUのコンピューティング機能を利用したいアプリケーションは、既存のレンダーノードを開き、それらのノードがサポートするDRM APIの限定されたサブセットを使用してGPU操作をディスパッチするだけで、追加の権限を必要とせずにこれを実現できます。ただし、デバイスファイルを開くためのファイルシステム権限が必要です。ディスプレイサーバー、コンポジター、およびモードセットAPIやその他の特権操作を必要とするその他のプログラムは、完全なDRM APIへのアクセスを許可する標準のプライマリノードを開き、通常どおり使用する必要があります。レンダリングノードは、安全でないGEMグローバル名を使用したバッファ共有を防ぐために、GEM flink操作を明示的に禁止します。グラフィックスサーバーを含む他のクライアントとバッファを共有するには、PRIME（DMA-BUF）ファイル記述子のみを使用できます。[ 9 ] [ 56 ]/dev/dri/renderDX/dev/dri/cardX

ハードウェアサポート

DRMは、 AMD CatalystやMesa 3Dなどのユーザーモードグラフィックデバイスドライバによって使用されます。ユーザー空間プログラムはLinuxシステムコールインターフェースを使用してDRMにアクセスします。DRMはLinuxシステムコールインターフェースを独自のシステムコールで拡張します。[ 57 ]

Linux DRMサブシステムには、デスクトップコンピューター向けGPUの主要3メーカー（AMD、NVIDIA、Intel）のハードウェアに加え、増加傾向にあるモバイルGPUおよびシステムオンチップ（SoC）インテグレーターのハードウェアをサポートする、無料のオープンソースドライバーが含まれています。各ドライバーの品質は、メーカーの協力度などによって大きく異なります。

DRMドライバー
ドライバ カーネル以来 サポートされているハードウェア ベンダーサポート ステータス/メモ
ラデオン 2.4.1 TeraScaleおよびGCN 第 1世代と第 2 世代アーキテクチャを搭載したAMD (旧 ATi) Radeon GPU シリーズ。R100 / 200 / 300 / 400、Radeon X1000、HD 2000 / 3000 / 4000 / 5000 / 6000 / 7000 / 8000、R5/R7/R9 200/300シリーズおよびKaveri APU のモデルを含みます。 はい アクティブ
915年 2.6.9 Intel GMA 830M、845G、852GM、855GM、865G、915G、945G、965G、G35、G41、G43、G45 チップセット。Intel HD および Iris Graphics HD Graphics 2000/3000/2500/4000/4200/4400/4600/P4600/P4700/5000、Iris Graphics 5100、Iris Pro Graphics 5200 統合 GPU。 はい アクティブ
ヌーボー2.6.33 [ 58 ] [ 59 ]NVIDIA Tesla、Fermi、Kepler、MaxwellベースのGeForce GPU、Tegra K1、X1 SoC 部分的 アクティブ
エクシノス 3.2 [ 60 ]Samsung ARMベースのExynos SoC
vmwgfx 3.2（ステージングから）[ 61 ]VMware SVGA2 用の仮想 GPU仮想ドライバー
gma500 3.3（ステージングから）[ 62 ] [ 63 ]Intel GMA 500およびその他のImagination Technologies ( PowerVR ) ベースのグラフィックス GPU 実験的な2D KMS専用ドライバー
最悪 3.5 [ 64 ]ASpeed Technologies 2000シリーズ 実験的な
mgag200 3.5 [ 65 ]Matrox MGA-G200 サーバー ディスプレイ エンジン KMSのみ
shmobile 3.7 [ 66 ]ルネサスSHモバイル
テグラ 3.8 [ 67 ]Nvidia Tegra 20、Tegra30 SoC はい アクティブ
オマップドrm 3.9 [ 68 ]テキサス・インスツルメンツOMAP 5 SoC
rcar-du 3.11 [ 69 ]ルネサスR-Car SoC ディスプレイユニット
msm 3.12 [ 70 ] [ 71 ]QualcommのAdreno A2xx/A3xx/A4xx GPUファミリー（Snapdragon SOC）[ 72 ]
艦隊 3.13 [ 73 ] [ 74 ]Marvell Armada 510 SoC
ボッホ 3.14 [ 75 ]Bochs dispi vga インターフェースを使用する仮想VGAカード( QEMU stdvgaなど) 仮想ドライバー
スティ 3.17 [ 76 ] [ 77 ]STマイクロエレクトロニクスSoC stiH41x シリーズ
imx 3.19（ステージングより）[ 78 ] [ 79 ]フリースケールi.MX SoC
ロックチップ 3.19 [ 78 ] [ 80 ]Rockchip SoCベースのGPU KMSのみ
amdgpu [ 57 ]4.2 [ 81 ] [ 82 ]AMD Radeon GPUシリーズ（GCN第3世代および第4世代アーキテクチャ搭載） 。Radeon Rx 200/300/400/500 [ 83 ]シリーズおよびCarrizo、Bristol 、 Stoney Ridge APUのモデルを含む。 はい アクティブ
ヴィルティオ 4.2 [ 84 ]QEMUベースの仮想マシン マネージャー ( KVMやXenなど) 用の仮想 GPU ドライバー仮想ドライバー
vc4 4.4 [ 85 ] [ 86 ] [ 87 ]Raspberry PiのBroadcom BCM2835 および BCM2836 SoC ( VideoCore IV GPU)
エトナヴィヴ 4.5 [ 88 ] [ 89 ] [ 90 ]Vivante GPUコアは、 Marvell ARMADAやFreescale i.MX6シリーズなどのいくつかのSoCに搭載されています。
サン4i 4.7 [ 91 ] [ 92 ]Allwinner SoC (ARM Mali-400 GPU)
キリン 4.7 [ 93 ] [ 92 ]HiSilicon Kirin hi6220 SoC (ARM Mali 450-MP4 GPU)
メディアテック 4.7 [ 94 ] [ 92 ]MediaTek MT8173 SoC (Imagination PowerVR GX6250 GPU)
ヒブマク 4.10 [ 95 ]HiSilicon hi1710 Huawei iBMC SoC（Silicon Image SM750 GPUコア[ 96 ]） KMSのみ
vkms 4.19 [ 97 ] [ 98 ]テストやヘッドレス マシンでのX (または同様のもの) の実行に役立つ KMS ドライバーのソフトウェアのみのモデル。 仮想ドライバー、実験的
リマ 5.2 [ 99 ] [ 100 ]ARM Mali 4xx GPU
パンフロスト 5.2 [ 101 ] [ 100 ]ARM Mali Txxx (Midgard) および Gxx (Bifrost) GPU
vboxビデオ 5.2（ステージングから）[ 102 ] [ 100 ]VirtualBox用の仮想 GPU ドライバー(VBoxVGA GPU) 仮想ドライバー
ハイパーV_DRM 5.14 [ 103 ] [ 104 ]Hyper-V合成ビデオデバイス 用の仮想 GPU ドライバー仮想ドライバー
シンプルDRM 5.14 [ 105 ] [ 106 ]ファームウェア提供フレームバッファ用 GPU ドライバ ( UEFI GOP、VESA BIOS 拡張、組み込みシステム) KMSのみ
オフドライブ 6.2 [ 107 ] [ 108 ]Open Firmwareフレームバッファ 用 GPU ドライバKMSのみ
ロンソン 6.6 [ 109 ] [ 110 ]Loongson GPU および SoC 用 GPU ドライバー
パワーVR 6.8 [ 111 ] [ 112 ]Imagination Technologies PowerVR（シリーズ6以降）およびIMGグラフィックスGPU
xe 6.8 [ 113 ] [ 114 ]Intel Xeシリーズ GPU ( Gen12統合 GPU、Intel Arcディスクリート GPU) はい 実験的な
パンサー 6.10 [ 115 ] [ 116 ]ARM Mali Gxxx (Valhall) GPU
efidrm 6.16 [ 117 ] [ 118 ]EFIフレームバッファ用 GPU ドライバー(UEFI GOP) KMSのみ
ベサドルム 6.16 [ 119 ] [ 118 ]VESAフレームバッファ用 GPU ドライバ(VESA BIOS 拡張) KMSのみ

次の表には、履歴目的で詳細が示された、古くて廃止されたハードウェア用のドライバーもいくつかあります。

歴史的なDRMドライバー
ドライバ カーネル以来 サポートされているハードウェア ステータス/メモ
ガンマ 2.3.18 3Dlabs GLINT GMX 2000 2.6.14以降削除[ 120 ]
ffb 2.4 Creator/Creator3D ( Sun Microsystems Ultraワークステーションで使用) 2.6.21以降削除[ 121 ]
tdfx 2.4 3dfxバンシー/ブードゥー3 + 6.3以降削除[ 122 ]
mga 2.4 マトロックスG200 / G400 / G450 6.3以降削除[ 123 ]
r128 2.4 ATI レイジ 1286.3以降削除[ 124 ]
i810 2.4 インテル i8106.3以降削除[ 125 ]
姉 2.4.17 SiS 300 /630/540 6.3以降削除[ 126 ]
i830 2.4.20 インテル 830M/845G/852GM/855GM/865G 2.6.39以降削除[ 127 ]（i915ドライバに置き換えられた）
経由 2.6.13 [ 128 ]VIAユニクローム/ ユニクローム プロ 6.3以降削除[ 129 ]
野蛮人 2.6.14 [ 130 ]S3 グラフィックス サベージ3D /MX/IX/4/スーパーサベージ/プロ/ツイスター 6.3以降削除[ 131 ]

発達

Direct Rendering Manager はLinux カーネル内で開発されており、そのソースコードはLinux ソースコードのディレクトリ内にあります/drivers/gpu/drm。サブシステムのメンテナは Dave Airlie 氏が務め、他のメンテナが特定のドライバを担当しています。[ 132 ] Linux カーネル開発ではよくあることですが、DRM のサブメンテナと貢献者は新機能やバグ修正のパッチをメインの DRM メンテナに送り、メインの DRM メンテナがそれを自身の Linuxリポジトリに統合します。DRM メンテナは新しい Linux バージョンがリリースされるたびに、すぐにメインライン化できるこれらのパッチをすべてLinus Torvalds氏に提出します。カーネル全体のトップメンテナである Torvalds 氏は、パッチがカーネルに組み込むのに適しているかどうかの最終決定権を持っています。

歴史的な理由により、libdrmライブラリのソースコードはMesaプロジェクトの傘下で管理されています。[ 133 ]

歴史

1999年、XFree86用のDRIを開発していたPrecision Insight社は、3dfxビデオカード用のDRMの最初のバージョンを、Mesaソースコード内に含まれるLinuxカーネルパッチとして作成した。[ 134 ]その年の後半、DRMコードは、キャラクターデバイス用のディレクトリの下のLinuxカーネル2.3.18にメインライン化された。[ 135 ]その後数年間で、サポートされるビデオカードの数は増えていった。2001年1月にLinux 2.4.0がリリースされたときには、3dfx Voodoo3カードに加えて、Creative Labs GMX 2000、Intel i810、Matrox G200/G400、ATI Rage 128が既にサポートされていた。[ 136 ]そして、2.4.xシリーズでは、ATI Radeonカード、一部のSiSビデオカード、Intel 830M以降の統合GPU用のドライバーが追加されていった。 /drivers/char/drm/

DRMをDRMコアとDRMドライバの2つのコンポーネントに分割するDRMコア/パーソナリティ分割は2004年後半に行われ、[ 11 ] [ 137 ]カーネルバージョン2.6.11に統合されました。[ 138 ]この分割により、複数のデバイス用の複数のDRMドライバが同時に動作できるようになり、マルチGPUサポートへの道が開かれました。

ビデオモード設定コードをすべてカーネル内の1か所に置くというアイデアは何年も前から認識されていたが、[ 139 ] [ 140 ]、グラフィックカード製造業者は、モード設定を行う唯一の方法は、各グラフィックカードのビデオBIOSに含まれている、製造業者が提供したルーチンを使用することだと主張していた。そのようなコードはx86リアルモードで実行する必要があり、保護モードで実行中のカーネルによって呼び出されることを防いでいた。[ 44 ] Luc Verhaegenと他の開発者がBIOSベースではなくネイティブでモード設定を行う方法を発見し、[ 141 ] [ 44 ]通常のカーネルコードを使用してそれが可能であることを示し、カーネルモード設定となるものの基礎を築いたことで状況は変わった。2007年5月、Jesse Barnes ( Intel )は drm-modesetting APIの最初の提案と、i915 DRM ドライバー内の Intel GPU 用モード設定のネイティブ実装を公開した。[ 42 ] 2007年12月、ジェローム・グリッセはATIカードのネイティブモード設定コードをRadeon DRMドライバに追加し始めた。[ 142 ] [ 143 ] APIとドライバの作業は2008年も続けられたが、フレームバッファを扱うためにカーネル空間にもメモリマネージャが必要になったため遅延した。[ 144 ]

2008年10月、Linuxカーネル2.6.27では、今後の重要な変更に先立ち、ソースコードが大幅に再編されました。DRMのソースコードツリーは専用のソースディレクトリに移動され/drivers/gpu/drm/、各種ドライバはそれぞれ専用のサブディレクトリに移動されました。ヘッダーも新しい/include/drmディレクトリに移動されました。[ 145 ]

ビデオメモリ管理の複雑さが増すにつれ、この問題を解決するためのいくつかのアプローチが生まれました。最初の試みは、Thomas Hellstrom ( Tungsten Graphics ) が Emma Anholt (Intel) および Dave Airlie ( Red Hat )と共同で開発したTranslation Table Maps (TTM) メモリマネージャでした。[ 5 ] TTM は、2007年11月にメインラインカーネル 2.6.25 に組み込むことが提案され、[ 5 ] 2008年5月にも提案されましたが、 Graphics Execution Manager (GEM)と呼ばれる新しいアプローチに取って代わられました。 [ 24 ] GEM は、Intel の Keith Packard と Emma Anholt によって、i915 ドライバのメモリ管理をより簡単にするソリューションとして最初に開発されました。[ 6 ] GEMは好評を博し、2008年12月にリリースされたLinuxカーネルバージョン2.6.28に統合されました。[ 146 ]一方、TTMは新しいRadeon KMS DRMドライバの要件として、最終的にLinux 2.6.31に統合されるまで2009年9月まで待たなければなりませんでした。[ 147 ]

バッファオブジェクトを扱うためのメモリ管理が導入されたことで、DRM開発者はカーネルに既に完成していたAPIとモード設定コードを追加できるようになりました。この拡張APIはカーネルモード設定（KMS）と呼ばれ、これを実装するドライバはKMSドライバと呼ばれることがよくあります。2009年3月に、KMSはi915ドライバのKMSサポートとともにLinuxカーネルバージョン2.6.29に統合されました。 [ 30 ] [ 148 ] KMS APIはlibdrm 2.4.3からユーザ空間プログラムに公開されています。[ 150 ] Intelグラフィックカード用のユーザ空間X.Org DDXドライバも新しいGEMおよびKMS APIを使用した最初のドライバでした。[ 151 ] radeon DRMドライバのKMSサポートは、2009年9月のLinux 2.6.31リリースに追加されました。[ 152 ] [ 153 ] [ 154 ]新しいradeon KMSドライバはTTMメモリマネージャを使用しましたが、TTMの代わりにGEM互換のインタフェースとioctlを公開しました。[ 23 ]

nouveauプロジェクトは2006年以来、公式Linuxカーネルの外部でNVIDIA GPU用のフリーソフトウェアDRMドライバを開発してきました。2010年にnouveauのソースコードは実験的なドライバとしてLinux 2.6.33にマージされました。 [ 58 ] [ 59 ]マージ時点で、ドライバは既にKMS化されており、GEM APIの背後ではTTMをメモリマネージャとして使用していました。[ 155 ]

GEM API を含む新しい KMS API は DRM 開発における大きなマイルストーンであったが、その後も API の強化が続けられた。KMS はLinux 2.6.33 で非同期VBLANK通知と連動したページ フリップのサポートを獲得した[ 156 ] [ 157 ] —i915 ドライバーのみで、radeon と nouveau は後に Linux 2.6.38 リリース中にそれを追加した。[ 158 ]新しいページ フリップ インターフェイスは libdrm 2.4.17 に追加された。[ 159 ] 2011 年初頭、Linux 2.6.39 リリース サイクル中に、いわゆるダム バッファー— フレームバッファーとして使用するのに適した単純なバッファーを処理するためのハードウェアに依存しない非加速方法 — が KMS API に追加された。[ 160 ] [ 161 ]目標は、ドライバ固有の ioctl によって提供される特別な加速操作を使用する必要のないPlymouthなどのアプリケーションの複雑さを軽減することでした。 [ 162 ]この機能は、libdrm バージョン 2.4.25 以降で公開されました。[ 163 ]その年の後半には、プレーンと呼ばれる新しい主要なオブジェクト タイプも追加されました。プレーンは、スキャンアウト エンジンによってサポートされているハードウェア オーバーレイを表すために開発されました。[ 164 ] [ 165 ]プレーンのサポートは Linux 3.3. [ 166 ]と libdrm 2.4.30 に統合されました。Linux 3.5 [ 167 ]および libdrm 2.4.36 [ 168 ]リリース中に API に追加されたもう 1 つの概念は、汎用オブジェクト プロパティ、つまりあらゆる KMS オブジェクトに汎用的な値を追加する方法でした。プロパティは、CRTC や飛行機などのオブジェクトに特別な動作や機能を設定するのに特に役立ちます。

DRM ドライバー間の GPU オフロードを提供するための初期の概念実証は、2010 年に Dave Airlie 氏によって開発されました。[ 7 ] [ 169 ] Airlie 氏はNVIDIA Optimus技術を模倣しようとしていたため、これを「PRIME」と名付けることにしました。[ 7 ] Airlie 氏は 2011 年後半に PRIME の作業を再開しましたが、Linux カーネル 3.3 で導入された新しいDMA-BUFバッファー共有メカニズムに基づいていました。[ 170 ]基本的な DMA-BUF PRIME インフラストラクチャは 2012 年 3 月に完成し[ 171 ]、Linux 3.4 リリースに統合され、[ 172 ] [ 173 ] [ 174 ] libdrm 2.4.34 にも統合されました。[ 175 ]その後、Linux 3.5 リリース中に、Intel カード用の i915、AMD カード用の radeon、NVIDIA カード用の nouveau など、いくつかの DRM ドライバーが PRIME サポートを実装しました。[ 176 ] [ 177 ]

近年、DRM API は新機能や改良された機能により段階的に拡張されてきました。 2013 年に、GSoCの一環として、David Herrmann が複数のレンダリング ノード機能を開発しました。[ 55 ]彼のコードは Linux カーネル バージョン 3.12 に実験的な機能として追加され[ 178 ] [ 179 ] i915、[ 180 ] radeon [ 181 ]および nouveau [ 182 ]ドライバでサポートされ、Linux 3.17 以降ではデフォルトで有効になっています。[ 77 ] 2014 年に Matt Roper (Intel) がユニバーサル プレーン(または統合プレーン) の概念を開発しました。これにより、フレーム バッファー (プライマリプレーン)、オーバーレイ (セカンダリ プレーン)、カーソル (カーソル プレーン)がすべて、統合 API を持つ単一のオブジェクトとして扱われます。[ 183 ] [ 33 ] APIの後方互換性を維持するために、この機能はDRMコアによってDRMドライバが提供できる追加機能として公開されています。ユニバーサルプレーンのサポートはLinux 3.15 [ 184 ]とlibdrm 2.4.55で初めて導入されました。[ 185 ] Intel i915 [ 186 ]などのいくつかのドライバでは既に実装されています。

最も最近の DRM API 拡張機能はアトミック モード設定API であり、DRM デバイスのモード設定とページ フリップ操作にアトミック性をもたらします。モード設定用のアトミック API のアイデアは、2012 年初頭に初めて提案されました。 [ 187 ] Ville Syrjälä (Intel) が、このようなアトミック API の設計と実装を引き継ぎました。[ 188 ]彼の成果を基に、Rob Clark ( Texas Instruments ) は、アトミック ページ フリップの実装を目指して同様のアプローチを取りました。[ 189 ] 2013 年後半に、提案された両方の機能が 1 つの ioctl を使用して 1 つの機能に再統合されました。[ 190 ]これは要件であったため、この機能はユニバーサル プレーンのサポートがマージされる 2014 年半ばまで待たなければなりませんでした。[ 186 ] 2014年後半には、ダニエル・ベッター（インテル）と他のDRM開発者によってアトミックコードが大幅に強化され[ 191 ] : 18 既存のKMSドライバーを新しいアトミックフレームワークに移行しやすくしました。[ 192 ]この作業はすべて最終的にLinux 3.19 [ 193 ]とLinux 4.0 [ 194 ] [ 195 ] [ 196 ]リリースに統合され、Linux 4.2以降ではデフォルトで有効になっています。[ 197 ] libdrmはバージョン2.4.62以降で新しいアトミックAPIを公開しています。[ 198 ]複数のドライバーがすでに新しいアトミックAPIに変換されています。[ 199 ] 2018年までに、この新しいアトミックモデルに基づく10個の新しいDRMドライバーがLinuxカーネルに追加されました。[ 200 ]

採択

ダイレクトレンダリングマネージャカーネルサブシステムは、当初XFree86 4.0ディスプレイサーバーの新しいダイレクトレンダリングインフラストラクチャで使用するために開発され、後に後継のX.Orgサーバーに継承されました。そのため、DRMの主なユーザーは、 Mesa 3Dライブラリにあるハードウェアアクセラレーション対応のOpenGL実装にリンクするDRIクライアントと、Xサーバー自体でした。現在では、DRMはWestonリファレンスコンポジターを含むいくつかのWaylandコンポジターでも使用されています。kmsconは、DRM KMS機能を使用してユーザー空間で実行される仮想コンソール実装です。[ 201 ]

2015年、独自仕様のNvidia GeForceドライバのバージョン358.09（ベータ版）は、DRMモード設定インターフェースのサポートを開始しましたnvidia-modeset.ko。このインターフェースは、新しいカーネルBLOBとして実装されました。この新しいドライバコンポーネントは、カーネルモジュールと連携して動作しnvidia.ko、GPUのディスプレイエンジン（ディスプレイコントローラ）をプログラムします。[ 202 ]

参照

参考文献

  1. ^ "Linux kernel/drivers/gpu/drm/README.drm" . kernel.org . 2014年2月26日時点のオリジナルよりアーカイブ。 2014年2月26日閲覧。
  2. ^ a bウイッターホーフェン、ヘルト。「フレームバッファデバイス」。カーネル.org 。2015 年1 月 28 日に取得。
  3. ^ a b cホワイト、トーマス. 「DRIとDRMの仕組み」 . 2014年7月22日閲覧。
  4. ^ Faith, Rickard E. (1999年5月11日). 「ダイレクトレンダリングマネージャ：ダイレクトレンダリングインフラストラクチャのカーネルサポート」 . 2016年5月24日時点のオリジナルよりアーカイブ。2016年5月12日閲覧。
  5. ^ a b c d e f g h Corbet, Jonathan (2007年11月6日). 「グラフィックプロセッサのメモリ管理」 . LWN.net . 2014年7月23日閲覧。
  6. ^ a b c d e f g Packard, Keith; Anholt, Eric (2008年5月13日). 「GEM - the Graphics Execution Manager」 . dri-develメーリングリスト. 2014年7月23日閲覧。
  7. ^ a b c Airlie, Dave (2010年3月12日). 「GPUオフロード - PRIME - 概念実証」 . 2015年2月10日時点のオリジナルよりアーカイブ。2015年2月10日閲覧。
  8. ^ a b c d e Kitching, Simon. 「DRMとKMSカーネルモジュール」 . 2016年5月13日閲覧。
  9. ^ a b c d e Herrmann, David (2013年9月1日). 「DRMとKMSデバイスノードの分割」 . 2014年7月23日閲覧。
  10. ^ 「README.rst - mesa/drm - Direct Rendering Manager のヘッダーとカーネルモジュール」 2020年3月21日.オリジナルより2020年3月21日時点のアーカイブ。
  11. ^ a b Airlie, Dave (2004年9月4日). 「新しく提案されたDRMインターフェース設計」 . dri-devel (メーリングリスト).
  12. ^ a b c d e f g Peres, Martin; Ravier, Timothée (2013年2月2日). 「DRI-next/DRM2: Linuxグラフィックススタックとそのセキュリティのウォークスルー」(PDF) . 2016年5月13日閲覧。
  13. ^クリスチャン、ホーグスバーグ (2008 年 9 月 4 日)。「DRI2 拡張機能 - バージョン 2.0」。X.組織。2016 年5 月 23 日に取得。
  14. ^ a b c d e f Barnes, Jesse; Pinchart, Laurent; Vetter, Daniel; Wunner, Lukas. 「Linux GPUドライバー開発者ガイド - メモリ管理」 . 2016年8月31日閲覧。
  15. ^ Vetter, Daniel. 「i915/GEM Crashcourse by Daniel Vetter」 . Intel Open Source Technology Center . 2015年1月31日閲覧. GEMは基本的にグラフィックスバッファオブジェクト（テクスチャ、レンダーバッファ、シェーダ、その他GPUが使用するあらゆる状態オブジェクトやデータを含む）を扱います。
  16. ^ a b c Vetter, Daniel (2011年5月4日). 「GEMの概要」 . 2015年2月13日閲覧。
  17. ^ Packard, Keith (2012年9月28日). 「DRI.Nextについての考察」. 2016年5月26日閲覧。GEM flinkには多くの問題があります。flink名はグローバルであるため、デバイスにアクセスできる人なら誰でもflinkデータの内容にアクセスできます。
  18. ^ a b Herrmann, David (2013年7月2日). 「DRMセキュリティ」 . 2013 X.Org Developer's Conference (XDC2013) Proceedings . 2015年2月13日閲覧. gem-flinkはアプリケーションやサーバーにプライベートな名前空間を提供しません。代わりに、DRMノードごとに1つのグローバル名前空間のみが提供されます。悪意のある認証済みアプリケーションは、gemバッファのブルートフォース「名前推測」によって他のクライアントを攻撃する可能性があります。
  19. ^ Kerrisk, Michael (2012年9月25日). 「XDC2012: グラフィックススタックのセキュリティ」 . LWN.net . 2015年11月25日閲覧。
  20. ^ a b Packard, Keith (2008年7月4日). 「gem update」 . 2016年4月25日閲覧。
  21. ^ "drm-memory man page" . Ubuntuマニュアル. 2015年1月29日閲覧.多くの最新のハイエンドGPUには独自のメモリマネージャーが搭載されています。アクセス時に同期が必要な複数のキャッシュも含まれています。[...] . そのため、GPUのメモリ管理はドライバーとハードウェアに大きく依存します。
  22. ^ 「Intel グラフィックス・メディア・アクセラレーター開発者ガイド」 Intel Corporation 2015年11月24日閲覧。
  23. ^ a b c Larabel, Michael (2008年8月26日). 「Radeon用GEM化されたTTMマネージャー」 . Phoronix . 2016年4月24日閲覧。
  24. ^ a b c Corbet, Jonathan (2008年5月28日). 「GEM v. TTM」 . LWN.net . 2015年2月10日閲覧。
  25. ^ Corbet, Jonathan (2012年1月11日). 「3.3におけるDMAバッファ共有」 . LWN.net . 2016年5月14日閲覧。
  26. ^ Clark, Rob; Semwal, Sumit. 「DMA バッファ共有フレームワーク：概要」(PDF) . 2016年5月14日閲覧。
  27. ^ Peres, Martin (2014年9月26日). 「Linux グラフィックスタック、Optimus、そして Nouveau ドライバー」(PDF) . 2016年5月14日閲覧。
  28. ^ Pinchart, Laurent (2013年2月20日). 「組み込みKMSドライバーの解剖学」(PDF) . 2016年6月27日閲覧。
  29. ^ Edge, Jake (2013年10月9日). 「DRI3と現在」 . LWN.net . 2016年5月28日閲覧。
  30. ^ a b c d「Linux 2.6.29 - カーネルモード設定」 . Linux Kernel Newbies . 2015年11月19日閲覧。
  31. ^ 「VGAハードウェア」 . OSDev.org . 2015年11月23日閲覧。
  32. ^ Rathmann, B. (2008年2月15日). 「Nouveauの現状、パートI」 . LWN.net . 2015年11月23日閲覧。グラフィックカードのプログラミングには様々な方法がありますが、初期化とモード設定のほとんどはメモリマップドIOを介して行われます。これは、CPUの標準メモリアドレス空間を介してアクセスできるレジスタ群です。このアドレス空間内のレジスタは、モード設定、出力制御、クロック設定など、グラフィックカードの様々な機能を扱う範囲に分割されています。
  33. ^ a b c d e Paalanen, Pekka (2014年6月5日). 「先史時代から世界的熱核戦争の先へ」 . 2014年7月29日閲覧。
  34. ^ 「drm-kms man page」 . Ubuntuマニュアル. 2015年11月19日閲覧。
  35. ^ Corbet, Jonathan (2010年1月13日). 「ユーザー空間モード設定の終焉か？」 LWN.net . 2015年11月20日閲覧。
  36. ^ a b「モード設定の設計に関する議論」。X.Org Wiki 。 2015年11月19日閲覧。
  37. ^ a b Corbet, Jonathan (2007年1月22日). 「LCA: X Window Systemのアップデート」 . LWN.net . 2015年11月23日閲覧。
  38. ^ 「XF86VIDMODE マニュアルページ」 . X.Org . 2016年4月23日閲覧。
  39. ^ 「X11R6.1 リリースノート」 . X.Org . 1996年3月14日. 2016年4月23日閲覧。
  40. ^ Corbet, Jonathan (2004年7月20日). 「Kernel Summit: ビデオドライバー」 . LWN.net . 2015年11月23日閲覧。
  41. ^ a b "Fedora - Features/KernelModeSetting" . Fedora Project . 2015年11月20日閲覧。歴史的に、Xサーバーは起動時に出力状態を保存し、テキストモードに戻った際にそれを復元する役割を担っていました。高速ユーザー切り替えはVTスイッチによって実現されており、最初のユーザーのXサーバーから切り替えると、テキストモードに移行するために一度点滅し、すぐに次のユーザーのセッションに移行するために再び点滅していました。
  42. ^ a b c d e Barnes, Jesse (2007年5月17日). 「[RFC] カーネルのグラフィックサブシステムの拡張」 . linux-kernel (メーリングリスト).
  43. ^ a b c「DrmModesetting - カーネルグラフィックスの強化」 DRI Wiki . 2015年11月23日閲覧。
  44. ^ a b c d e Packard, Keith (2007年9月16日). 「カーネルモードドライバー」 . 2016年4月30日閲覧。
  45. ^ a b Packard, Keith (2000年4月24日). 「Intelドライバーの焦点を絞る」 . 2016年5月23日閲覧。より微妙な制限は、ドライバーが割り込みを処理できなかったため、ホットプラグモニターがサポートされていなかったことです。
  46. ^ Barnes, Jesse; Pinchart, Laurent; Vetter, Daniel; Wunner, Lukas. 「Linux GPUドライバー開発者ガイド - ドライバー初期化」 . 2016年8月31日閲覧。
  47. ^ "q3k (@[email protected])" . Warsaw Hackerspace Social Club . 2023年1月31日. 2023年2月13日閲覧. DRM/KMSドライバーは完全に動作するようになりましたが、DMAはまだサポートされていません。ちなみに、Rustで書かれていますが、ほとんどが生のunsafeブロックだらけです。
  48. ^ "q3k (@[email protected])" . Warsaw Hackerspace Social Club . 2023年1月31日. 2023年2月13日閲覧.素晴らしいのは、通常のDRM/KMSドライバー（と@[email protected]の協力）があるので、例えばWayland! WestonをiPod Nano 5Gで実行できるということです。
  49. ^ a b c d e f g Barnes, Jesse; Pinchart, Laurent; Vetter, Daniel; Wunner, Lukas. 「Linux GPUドライバー開発者ガイド - KMSの初期化とクリーンアップ」 . 2016年8月31日閲覧。
  50. ^ a b「ビデオカード」 . X.Org Wiki . 2016年4月11日閲覧。
  51. ^ a b Deucher, Alex (2010年4月15日). 「Radeonディスプレイハードウェアに関するメモ」 . 2016年4月5日時点のオリジナルよりアーカイブ。 2016年4月8日閲覧。
  52. ^ a b c d e Vetter, Daniel (2015年8月5日). 「Atomic mode setting design overview, part 1」 . LWN.net . 2016年5月7日閲覧。
  53. ^ a b Reding, Thierry (2015年2月1日). 「Atomic Mode-Setting」(PDF) . FOSDEMアーカイブ. 2016年5月7日閲覧。
  54. ^ Vetter, Daniel (2015年8月12日). 「Atomic mode setting design overview, part 2」 . LWN.net . 2016年5月7日閲覧。
  55. ^ a b c Herrmann, David (2013年5月29日). 「DRM Render- and Modeset-Nodes」 . 2014年7月21日閲覧。
  56. ^ a b c d Barnes, Jesse; Pinchart, Laurent; Vetter, Daniel; Wunner, Lukas. 「Linux GPUドライバー開発者ガイド - レンダリングノード」 . 2016年8月31日閲覧。
  57. ^ a b Deucher, Alex (2015年4月20日). 「amdgpuドライバの初期リリース」 . dri-devel (メーリングリスト).
  58. ^ a b「Linux 2.6.33 - Nouveau、Nvidiaグラフィックカード用ドライバー」。Linux Kernel Newbies 。 2016年4月26日閲覧。
  59. ^ a b「drm/nouveau: NVIDIA GPU用DRMドライバーを追加」 Kernel.org . 2015年1月27日閲覧。
  60. ^ 「DRM: ​​Samsung SoC EXYNOS4210用DRMドライバーを追加」 Kernel.org . 2016年3月3日閲覧。
  61. ^ 「vmwgfx: ドライバーをステージングから外す」 Kernel.org . 2016年3月3日閲覧。
  62. ^ 「Linux 3.3 - DriverArch - グラフィックス」 . Linux Kernel Newbies . 2016年3月3日閲覧。
  63. ^ Larabel, Michael (2012年1月10日). 「Linux 3.3 DRM Pull Is Heavy On Enhancements」 . Phoronix . 2016年3月3日閲覧。
  64. ^ "drm: AST (ASpeed Technologies) 2000シリーズ用初期KMSドライバー (v2)" . Kernel.org . 2016年3月3日閲覧。
  65. ^ Airlie, Dave (2012年5月17日). 「mgag200: initial g200se driver (v2)」 . 2018年1月24日閲覧。
  66. ^ "drm: Renesas SH Mobile DRM ドライバ" . Kernel.org . 2016年3月3日閲覧。
  67. ^ "drm: NVIDIA Tegra20のサポートを追加" . Kernel.org . 2016年3月3日閲覧。
  68. ^ "drm/omap: ステージングから移行" . Kernel.org . 2016年3月3日閲覧。
  69. ^ "drm: Renesas R-Car ディスプレイユニット DRM ドライバー" . Kernel.org . 2016年3月3日閲覧。
  70. ^ "drm/msm: snapdragon用基本KMSドライバー" . Kernel.org . 2016年3月3日閲覧。
  71. ^ Larabel, Michael (2013年8月28日). 「Snapdragon DRM/KMSドライバーがLinux 3.12に統合」 . Phoronix . 2015年1月26日閲覧。
  72. ^ Edge, Jake (2015年4月8日). 「freedreno グラフィックドライバーのアップデート」 . LWN.net . 2015年4月23日閲覧。
  73. ^ King, Russell (2013年10月18日). 「[GIT PULL] Armada DRMサポート」 . dri-devel (メーリングリスト).
  74. ^ 「DRM: ​​Armada: Armada DRM ドライバーの追加」 Kernel.org . 2016年3月3日閲覧。
  75. ^ "drm/bochs: 新しいドライバー" . Kernel.org . 2016年3月3日閲覧。
  76. ^ Larabel, Michael (2014年8月8日). 「Linux 3.17 DRM Pull Brings New Graphics Driver」 . Phoronix . 2016年3月3日閲覧。
  77. ^ a b Corbet, Jonathan (2014年8月13日). 「3.17 マージウィンドウ パート2」 . LWN.net . 2014年10月7日閲覧。
  78. ^ a b Corbet, Jonathan (2014年12月17日). 「3.19 Merge window part 2」 . LWN.net . 2015年2月9日閲覧。
  79. ^ "drm: imx: imx-drm ドライバーをステージングから移動" . Kernel.org . 2015年2月9日閲覧。
  80. ^ "drm: rockchip: 基本的なdrmドライバーの追加" . Kernel.org . 2016年3月3日閲覧。
  81. ^ Larabel, Michael (2015年6月25日). 「Linux 4.2 DRMアップデート：AMDが注目、Nouveauドライバーの変更なし」 . Phoronix . 2015年8月31日閲覧。
  82. ^ Corbet, Jonathan (2015年7月1日). 「4.2 マージウィンドウ パート2」 . LWN.net . 2015年8月31日閲覧。
  83. ^ Deucher, Alex (2015年8月3日). 「[PATCH 00/11] Fijiサポートを追加」 . dri-devel (メーリングリスト).
  84. ^ 「virtio gpuドライバーの追加」 Kernel.org 2016年3月3日閲覧。
  85. ^ Corbet, Jonathan (2015年11月11日). 「4.4 マージウィンドウ パート1」 . LWN.net . 2016年1月11日閲覧。
  86. ^ Larabel, Michael (2015年11月15日). 「Linux 4.4カーネルの新機能の概要」 . Phoronix . 2016年1月11日閲覧。
  87. ^ 「drm/vc4: Raspberry PiにKMSサポートを追加」Kernel.org。
  88. ^ 「Linux 4.5-DriversArch - グラフィックス」 . Linux Kernel Newbies . 2016年3月14日閲覧。
  89. ^ Larabel, Michael (2016年1月24日). 「Linux 4.5カーネルの多くの新機能と改善点」 . Phoronix . 2016年3月14日閲覧。
  90. ^ Corbet, Jonathan (2016年1月20日). 「4.5 マージウィンドウ パート2」 . LWN.Net . 2016年3月14日閲覧。
  91. ^ 「タグ 'sun4i-drm-for-4.7' をマージ」「 . Kernel.org .
  92. ^ a b c Airlie, Dave (2016年5月23日). 「[git pull] drm for v4.7」 . dri-devel (メーリングリスト).
  93. ^ 「タグ 'drm-hisilicon-next-2016-04-29' をマージ」「 . Kernel.org .
  94. ^ 「タグ 'mediatek-drm-2016-05-09' をマージ」「 . Kernel.org .
  95. ^ Larabel, Michael (2016年11月22日). 「Hisilicon Hibmc DRMドライバーがLinux 4.10に追加される」 . Phoronix . 2018年1月24日閲覧。
  96. ^ 「Huawei FusionServer RH5885 V3テクニカルホワイトペーパー」 。2016年11月18日。2018年1月25日時点のオリジナルからのアーカイブ。管理チップHi1710に統合されたオンボードディスプレイチップを使用し、SM750のIPコアを使用しています。
  97. ^ "drm/vkms: 基本的なVKMSドライバーの導入" . git.kernel.org . 2022年7月20日閲覧。
  98. ^ Larabel, Michael (2018年8月15日). 「Linux 4.19に仮想カーネルモード設定ドライバーが追加される」 . Phoronix . 2022年7月20日閲覧。
  99. ^ "drm/lima: ARM Mali4xx GPU用ドライバー" . git.kernel.org . 2019年11月28日閲覧。
  100. ^ a b c Larabel, Michael (2019年5月9日). 「Linux 5.2 DRM により Icelake が本番環境に対応、Lima と Panfrost ドライバーを追加」 . Phoronix . 2022年7月20日閲覧。
  101. ^ "drm/panfrost: 初期panfrostドライバーの追加" . git.kernel.org . 2019年11月28日閲覧。
  102. ^ "drm/vboxvideo: vboxvideoドライバーをステージングから移動" . git.kernel.org . 2022年7月20日閲覧。
  103. ^ "drm/hyperv: HyperV合成ビデオデバイス用のDRMドライバーを追加" . git.kernel.org . 2021年8月30日閲覧。
  104. ^ Larabel, Michael (2021年6月9日). 「MicrosoftのHyper-V DRMディスプレイドライバーがLinux 5.14に登場」 . Phoronix . 2021年8月30日閲覧。
  105. ^ "drm: simpledrm ドライバーを追加" . git.kernel.org . 2021年8月30日閲覧。
  106. ^ Larabel, Michael (2021年5月13日). 「Linux 5.14でSimpleDRMドライバーとVC4 HDRがサポートされ、AGPコードの一部がレガシーとしてマークされる」 . Phoronix . 2021年8月30日閲覧。
  107. ^ "drm/ofdrm: Open Firmwareフレームバッファ用のofdrmを追加" . git.kernel.org . 2023年2月21日閲覧。
  108. ^ Larabel, Michael (2022年10月20日). 「Linux 6.2向けOpen Firmware DRMドライバー「OFDRM」キューイング」 . Phoronix . 2023年2月21日閲覧。
  109. ^ "drm: loongsonディスプレイコントローラ用のkmsドライバを追加" . git.kernel.org . 2024年2月23日閲覧。
  110. ^ Larabel, Michael (2023年7月13日). 「Linux 6.6向けオープンソースグラフィックドライバーアップデートのキューイング開始」 . Phoronix . 2024年2月23日閲覧。
  111. ^ "drm/imagination: スケルトンPowerVRドライバーを追加" . git.kernel.org . 2024年5月27日閲覧。
  112. ^ Larabel, Michael (2023年11月23日). 「Imagination PowerVRオープンソースGPUドライバーがLinux 6.8で導入される」 . Phoronix . 2024年5月27日閲覧。
  113. ^ "drm/xe: Intel GPU向けの新しいDRMドライバーを導入" . git.kernel.org . 2024年5月27日閲覧。
  114. ^ Larabel, Michael (2023年12月15日). 「Intelの新しい「Xe」カーネルグラフィックスドライバーがLinux 6.8に先駆けて提出」 . Phoronix . 2024年5月27日閲覧。
  115. ^ 「タグ 'drm-misc-next-2024-03-28' を drm-next にマージ」 . git.kernel.org . 2025年8月3日閲覧。drm /panthor ドライバとその他修正を追加。
  116. ^ Larabel, Michael (2024年3月26日). 「Panthor DRMドライバーがLinux 6.10にキューイングされ、新しいArm Mali GPUをサポート」 . Phoronix . 2025年8月3日閲覧。
  117. ^ "drm/sysfb: EFIディスプレイ用のefidrmを追加" . git.kernel.org . 2025年8月3日閲覧。
  118. ^ a b Larabel, Michael (2025年4月10日). 「Linux 6.16のグラフィックス/ディスプレイドライバーの変更が今夏開始」 . Phoronix . 2025年8月3日閲覧。
  119. ^ "drm/sysfb: VESAディスプレイ用のvesadrmを追加" . git.kernel.org . 2025年8月3日閲覧。
  120. ^ "drm: ガンマドライバを削除する" . Kernel.org . 2015年1月27日閲覧。
  121. ^ 「[DRM]: ビルドされないsparc64 FFBドライバコードを削除する」 Kernel.org . 2015年1月27日閲覧。
  122. ^ "drm: 廃止されたdriver-tdfxを削除する" . Kernel.org . 2024年2月23日閲覧。
  123. ^ "drm: 廃止されたdriver-mgaを削除する" . Kernel.org . 2024年2月23日閲覧。
  124. ^ "drm: 廃止されたドライバーr128を削除する" . Kernel.org . 2024年2月23日閲覧。
  125. ^ "drm: 廃止されたドライバーi810を削除する" . Kernel.org . 2024年2月23日閲覧。
  126. ^ 「drm: 廃止されたドライバーsisを削除する」 Kernel.org . 2024年2月23日閲覧。
  127. ^ "drm: i830 ドライバーを削除" . Kernel.org . 2015年1月27日閲覧。
  128. ^ "drm: unichromeサポート経由で追加" . Kernel.org . 2015年1月27日閲覧。
  129. ^ "drm: 古いドライバーを削除する-via" . Kernel.org . 2024年2月23日閲覧。
  130. ^ "drm: add savage driver" . Kernel.org . 2015年1月27日閲覧。
  131. ^ 「drm: 廃止されたdriver-savageを削除する」 Kernel.org . 2024年2月23日閲覧。
  132. ^ 「Linuxカーネルのメンテナー一覧」 Kernel.org . 2014年7月14日閲覧。
  133. ^ "libdrm gitリポジトリ" . 2014年7月23日閲覧。
  134. ^ 「3dfxドライバの最初のDRIリリース」 Mesa 3D 2014年7月15日閲覧。
  135. ^ "Import 2.3.18pre1" . The History of Linux in GIT Repository Format 1992-2010 (2010) . 2014年7月15日閲覧。
  136. ^ Torvalds, Linus. 「Linux 2.4.0 ソースコード」 . Kernel.org . 2014年7月29日閲覧。
  137. ^ Airlie, Dave (2004年12月30日). 「[bk pull] drm core/personality split」 . linux-kernel (メーリングリスト).
  138. ^ Torvalds, Linus (2005年1月11日). 「Linux 2.6.11-rc1」 . linux-kernel (メーリングリスト).
  139. ^ Gettys, James; Packard, Keith (2004年6月15日). 「X Window Systemの（再）アーキテクチャ」 . 2016年4月30日閲覧。
  140. ^ Smirl, Jon (2005年8月30日). 「Linuxグラフィックスの現状」. 2016年4月30日閲覧。この問題の最善の解決策は、カーネルが各ビデオハードウェアに対して単一の包括的なデバイスドライバを提供することだと私は考えています。これは、fbdevやDRMのような競合するドライバを、協調動作するシステムに統合する必要があることを意味します。また、カーネルベースのデバイスドライバがロードされている間は、ユーザー空間からハードウェアへの不正アクセスを防止することも必要です。
  141. ^ Verhaegen, Luc (2006年3月2日). 「Xとモードセッティング：萎縮の図解」(PDF) . 2016年4月30日閲覧。
  142. ^ Glisse, Jerome (2007年12月4日). 「Radeonカーネルモード設定」 . 2016年4月30日閲覧。
  143. ^ Larabel, Michael (2008年10月1日). 「カーネルモード設定の現状」 . Phoronix . 2016年4月30日閲覧。
  144. ^ Packard, Keith (2008年7月21日). 「X output status july 2008」 . 2016年5月1日閲覧。
  145. ^ 「drm: 将来性を高めるためにdrmツリーを再編成」Kernel.org。
  146. ^ 「Linux 2.6.28 - GPUメモリ用のGEMメモリマネージャー」Linuxカーネル初心者向け。2014年7月23日閲覧。
  147. ^ "drm: TTM GPUメモリマネージャサブシステムを追加する" . Kernel.org .
  148. ^ 「DRM: ​​モード設定サポートを追加」Kernel.org。
  149. ^ 「DRM: ​​i915: モード設定サポートを追加」Kernel.org。
  150. ^ Anholt, Eric (2008年12月22日). 「[ANNOUNCE] libdrm-2.4.3」 . dri-devel (メーリングリスト).
  151. ^ Barnes, Jesse (2008年10月20日). 「[ANNOUNCE] xf86-video-intel 2.5.0」 . xorg-announce (メーリングリスト).
  152. ^ 「Linux 2.6.31 - ATI Radeon カーネルモード設定のサポート」 . Linux Kernel Newbies . 2015年11月5日時点のオリジナルよりアーカイブ。 2016年4月28日閲覧。
  153. ^ Torvalds, Linus (2009年9月9日). 「Linux 2.6.31」 . linux-kernel (メーリングリスト).
  154. ^ 「drm/radeon: radeonハードウェア用のカーネルモード設定を導入」Kernel.org。
  155. ^ 「The irregular Nouveau Development Companion #40」Nouveauプロジェクト。2016年5月3日閲覧。
  156. ^ 「Linux 2.6.33 - グラフィックの改善」 . Linux Kernel Newbies . 2016年4月28日閲覧。
  157. ^ "drm/kms: ページ反転ioctlを追加" . Kernel.org .
  158. ^ 「Linux 2.6.38 - グラフィックス」 . Linux Kernel Newbies . 2016年4月28日閲覧。
  159. ^ Airlie, Dave (2009年12月21日). 「[ANNOUNCE] libdrm 2.4.17」 . dri-devel (メーリングリスト).
  160. ^ "drm: intel/radeon (v3) 用のダムスキャンアウト作成/mmap" . Kernel.org .
  161. ^ 「Linux 2 6 39-DriversArch」 . Linux Kernel Newbies . 2016年4月19日閲覧。
  162. ^ Barnes, Jesse; Pinchart, Laurent; Vetter, Daniel; Wunner, Lukas. 「Linux GPUドライバー開発者ガイド - ダムバッファオブジェクト」 . 2016年8月31日閲覧。
  163. ^ Wilson, Chris (2011年4月11日). 「[ANNOUNCE] libdrm 2.4.25」 . dri-devel (メーリングリスト).
  164. ^ Barnes, Jesse (2011年4月25日). 「[RFC] drm: オーバーレイをファーストクラスKMSオブジェクトとして追加する」 . dri-devel (メーリングリスト).
  165. ^ Barnes, Jesse (2011年5月13日). 「[RFC] drm: オーバーレイをファーストクラスKMSオブジェクトとして追加する」 . dri-devel (メーリングリスト).
  166. ^ "drm: プレーンサポート v3 を追加" . Kernel.org .
  167. ^ 「drm: あらゆるオブジェクトのプロパティを取得/設定するための汎用 ioctl を追加する」Kernel.org。
  168. ^ Widawsky, Ben (2012年6月27日). 「[ANNOUNCE] libdrm 2.4.36」 . xorg-announce (メーリングリスト).
  169. ^ Larabel, Michael. 「概念実証：オープンソースのマルチGPUレンダリング！」 Phoronix . 2016年4月14日閲覧。
  170. ^ Larabel, Michael (2012年2月23日). 「DRM Base PRIME Support Part Of VGEM Work」 . Phoronix . 2016年4月14日閲覧。
  171. ^ Airlie, Dave (2012年3月27日). 「[PATCH] drm: base prime/dma-buf サポート (v5)」 . dri-devel (メーリングリスト).
  172. ^ Larabel, Michael (2012年3月30日). 「Linux 3.4の最終段階：DMA-BUF PRIMEのサポート」 . Phoronix . 2016年4月15日閲覧。
  173. ^ "drm: base prime/dma-buf サポート (v5)" . Kernel.org .
  174. ^ 「Linux 3.4 DriverArch」 . Linux Kernel Newbies . 2016年4月15日閲覧。
  175. ^ Anholt, Eric (2012年5月10日). 「[ANNOUNCE] libdrm 2.4.34」 . dri-devel (メーリングリスト).
  176. ^ Larabel, Michael (2012年5月12日). 「DMA-BUF PRIME Coming Together For Linux 3.5」 . Phoronix . 2016年4月15日閲覧。
  177. ^ 「Linux 3.5 DriverArch」 . Linux Kernel Newbies . 2016年4月15日閲覧。
  178. ^ Corbet, Jonathan (2013年9月11日). 「3.12 マージウィンドウ パート2」 . LWN.net . 2014年7月21日閲覧。
  179. ^ 「drm: 実験的なレンダリングノードを実装する」Kernel.org。
  180. ^ "drm/i915: レンダリングノードのサポート" . Kernel.org .
  181. ^ "drm/radeon: レンダリングノードのサポート" . Kernel.org .
  182. ^ "drm/nouveau: レンダリングノードのサポート" . Kernel.org .
  183. ^ Roper, Matt (2014年3月7日). 「[RFCv2 00/10] ユニバーサルプレーンサポート」 . dri-devel (メーリングリスト).
  184. ^ Larabel, Michael (2014年4月2日). 「Linux 3.15向けユニバーサルプレーンサポートセット」 . Phoronix . 2016年4月14日閲覧。
  185. ^マールテン州ランクホルスト (2014 年 7 月 25 日)。「[お知らせ] libdrm 2.4.55」。dri-devel (メーリングリスト)。
  186. ^ a b Vetter, Daniel (2014年8月7日). 「3.17向けの便利な機能」 . 2016年4月14日閲覧。
  187. ^ Barnes, Jesse (2012年2月15日). 「[RFC] drm: アトミックモードセットAPI」 . dri-devel (メーリングリスト).
  188. ^ Syrjälä, Ville (2012年5月24日). 「[RFC][PATCH 0/6] WIP: drm: Atomic mode setting idea」 . dri-devel (メーリングリスト).
  189. ^ Clark, Rob (2012年9月9日). 「[RFC 0/9] 核ページフリップ」 . dri-devel (メーリングリスト).
  190. ^ Clark, Rob (2013年10月6日). 「[RFCv1 00/12] Atomic/nuclear modeset/pageflip」 . dri-devel (メーリングリスト).
  191. ^ Vetter, Daniel (2016年2月3日). 「Atomic Display Ageを受け入れよう」(PDF) . 2016年5月4日閲覧。
  192. ^ Vetter, Daniel (2014年11月2日). 「KMSドライバー向けAtomic Modesetサポート」 . 2016年5月4日閲覧。
  193. ^ Airlie, Dave (2014年12月14日). 「[git pull] drm for 3.19-rc1」 . dri-devel (メーリングリスト).
  194. ^ Vetter, Daniel (2015年1月28日). 「Atomic Display Updatesのアップデート」 . 2016年5月4日閲覧。
  195. ^ Airlie, Dave (2015年2月15日). 「[git pull] drm pull for 3.20-rc1」 . dri-devel (メーリングリスト).
  196. ^ 「Linux 4.0 - DriverArch - グラフィックス」 . Linux Kernel Newbies . 2016年5月3日閲覧。
  197. ^ 「Linux 4.2 - Atomic modesetting APIがデフォルトで有効化」 Linux Kernel Newbies . 2016年5月3日閲覧。
  198. ^ Velikov, Emil (2015年6月29日). 「[ANNOUNCE] libdrm 2.4.62」 . dri-devel (メーリングリスト).
  199. ^ Vetter, Daniel (2016年6月6日). 「素晴らしいアトミックの進歩」 . 2016年6月7日閲覧。現在、DRMサブシステムに統合されたアトミックモード設定をサポートするドライバは17種類あります。
  200. ^ Stone, Daniel (2018年3月20日). 「Linuxの低レベルグラフィックスの新時代 - パート1」 . 2018年5月5日閲覧。
  201. ^ Herrmann, David (2012年12月10日). 「KMSCON Introduction」 . 2015年11月22日閲覧。
  202. ^ 「Linux、Solaris、FreeBSD ドライバー 358.09 (ベータ)」 2015年12月10日。
「 https://en.wikipedia.org/w/index.php?title=Direct_Rendering_Manager&oldid=1305829519#libdrm」から取得