Loading article…
| 原作者 | kernel.orgとfreedesktop.org |
|---|---|
| 開発者 | kernel.orgとfreedesktop.org |
| 書かれた | Ｃ |
| タイプ | |
| ライセンス | |
| Webサイト | dri.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 により、複数のプログラムが 3D ビデオ カードに同時にアクセスでき、衝突を回避できます。
ダイレクトレンダリングマネージャは、複数のプログラムがビデオハードウェアリソースを協調して使用できるようにするために作成されました。[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]
ソフトウェアアーキテクチャ
ダイレクトレンダリングマネージャはカーネル空間に常駐するため、ユーザー空間プログラムはカーネルシステムコールを使用してそのサービスを要求する必要があります。ただし、DRMは独自のカスタマイズされたシステムコールを定義していません。代わりに、階層の下のデバイスファイルを使用して、ファイルシステムの名前空間を通じてGPUを公開するという、 Unixの「すべてがファイルである」という原則に従います。DRMによって検出された各GPUはDRMデバイスと呼ばれ、デバイスファイル（Xは連番）が作成されてインターフェイスします。[8] [9] GPUと通信するユーザー空間プログラムは、このファイルを開き、 ioctl呼び出しを使用してDRMと通信する必要があります。異なるioctlは、DRM APIの異なる機能に対応しています。
/dev/dev/dri/cardX
libdrmと呼ばれるライブラリは、ユーザー空間プログラムと DRM サブシステムのインターフェイスを容易にするために作成されました。このライブラリは、 DRM API のすべての ioctl に対してCで記述された関数、および定数、構造体、その他のヘルパー要素を提供するラッパーにすぎません。 [10] libdrm を使用すると、カーネル インターフェイスがアプリケーションに直接公開されることが回避されるだけでなく、プログラム間でコードを再利用および共有するという通常の利点が得られます。
DRM は、汎用の「DRM コア」と、サポートされるハードウェアの種類ごとに固有の「DRM ドライバー」の 2 つの部分で構成されています。[11] DRM コアは、さまざまな DRM ドライバーが登録できる基本的なフレームワークを提供し、共通のハードウェアに依存しない機能を備えた最小限の ioctl セットをユーザー空間に提供します。[8]一方、DRM ドライバーは、サポートする GPU の種類に固有の API のハードウェア依存部分を実装します。DRM コアでカバーされていない残りの ioctl の実装を提供する必要がありますが、API を拡張して、そのようなハードウェアでのみ利用可能な追加機能を備えた追加の ioctl を提供することもできます。[8]特定の DRM ドライバーが拡張 API を提供する場合、ユーザー空間 libdrm も、ユーザー空間で追加の ioctl とのインターフェイスに使用できる追加の ライブラリ libdrm- driverによって拡張されます。
翻訳
DRM コアは、通常、対応するlibdrmラッパー関数を通じて使用されることを意図した、ユーザー空間アプリケーションへのいくつかのインターフェイスをエクスポートします。さらに、ドライバーは、ioctlおよびsysfsファイルを通じて、ユーザー空間ドライバーおよびデバイス対応アプリケーションが使用するデバイス固有のインターフェイスをエクスポートします。外部インターフェイスには、メモリ マッピング、コンテキスト管理、 DMA操作、AGP管理、vblank制御、フェンス管理、メモリ管理、および出力管理
が含まれます。
DRM マスターと DRM 認証
DRM API には、セキュリティ上の理由または同時実行の問題により、デバイスごとに 1 つのユーザー空間プロセスによって使用されるように制限する必要がある操作 (ioctl) がいくつかあります。[8]この制限を実装するために、DRM は、このような ioctl が DRM デバイスの「マスター」と見なされるプロセス (通常はDRM-Masterと呼ばれます) によってのみ呼び出されるように制限します。デバイス ノードを開いているすべてのプロセスのうち、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デスクトップでは、オフスクリーンバッファを合成マネージャと共有するための最適な方法が必要でした。これらの要件により、カーネル内でグラフィックスバッファを管理する新しい方法が開発されました。これらの方法の1つとして、グラフィックス実行マネージャ（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 名は、受信側プロセスが元の GEM オブジェクトを指すローカル GEM ハンドルを取得するために使用できます。
残念ながら、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でも使用されます。
カーネルモード設定
ビデオカードやグラフィックスアダプタが適切に動作するには、それ自体と接続されたディスプレイ画面でサポートされている値の範囲内で、画面解像度、色深度、リフレッシュレートの組み合わせであるモードを設定する必要があります。この操作はモード設定と呼ばれ、[30]グラフィックスハードウェアへの生のアクセス、つまりビデオカードのディスプレイコントローラの特定のレジスタに書き込む機能が必要になります。[31] [32]モード設定操作は、フレームバッファの使用を開始する前、およびアプリケーションやユーザーがモードを変更する必要があるときに実行する必要があります。
初期の頃は、グラフィカル フレームバッファを使用するユーザー空間プログラムは、モード設定操作の提供も担当していたため[3]、ビデオ ハードウェアへの特権アクセスで実行する必要がありました。Unix タイプのオペレーティング システムでは、X サーバーが最も顕著な例であり、そのモード設定の実装は、特定の種類のビデオ カードごとにDDX ドライバーに存在していました。 [33]このアプローチは、後にユーザー空間モード設定または UMSと呼ばれるようになりましたが、 [34] [35]いくつかの問題を引き起こします。[36] [30]これは、オペレーティング システムがプログラムとハードウェアの間に提供すべき分離を破壊し、安定性とセキュリティの両方の懸念を引き起こすだけでなく、2 つ以上のユーザー空間プログラムが同時にモード設定を行おうとすると、グラフィックス ハードウェアが不整合な状態になる可能性もあります。これらの競合を回避するために、X サーバーは、実際にはモード設定操作を実行する唯一のユーザー空間プログラムになりました。残りのユーザー空間プログラムは、適切なモードを設定し、モード設定を含むその他の操作を処理するために X サーバーに依存していました。当初、モード設定はXサーバーの起動プロセス中にのみ実行されていましたが、後にXサーバーは実行中にモード設定を行う機能を獲得しました。[37] XFree86-VidModeExtension拡張機能は、XクライアントがXサーバーにモデルライン（解像度）の変更を要求できるように、XFree86 3.1.2で導入されました。 [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 がカーネルの一部であるという事実により、割り込みなどのカーネル空間でのみ利用可能なリソースを使用することができます。[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 にはプライマリ プレーンが 1 つ関連付けられている必要があります。[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]これにより、モード設定 API などの特権部分を含む DRM API に完全にアクセスできるのは、信頼できるユーザー空間プログラム (X サーバー、グラフィカル コンポジターなど) のみというアーキテクチャになります。レンダリングや 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
ハードウェアサポート
Linux DRM サブシステムには、デスクトップ コンピューター用 GPU の 3 大メーカー (AMD、NVIDIA、Intel) のハードウェアをサポートする無料のオープン ソースドライバーと、増加しているモバイル GPU およびシステム オン チップ(SoC) インテグレーターのハードウェアをサポートする無料のオープン ソース ドライバーが含まれています。各ドライバーの品質は、メーカーの協力度やその他の事項によって大きく異なります。
次の表には、履歴目的で、古くて廃止されたハードウェア用のドライバーもいくつか記載されています。
発達
Direct Rendering ManagerはLinuxカーネル内で開発されており、そのソースコードは/drivers/gpu/drmLinuxソースコードのディレクトリ内にあります。サブシステムのメンテナはDave Airlieで、他のメンテナが特定のドライバを担当しています。 [127] Linuxカーネル開発では通常、DRMサブメンテナと貢献者は新しい機能とバグ修正のパッチをメインDRMメンテナに送信し、メインDRMメンテナはそれを独自のLinuxリポジトリに統合します。DRMメンテナは、新しいLinuxバージョンがリリースされるたびに、メインライン化できるこれらのパッチをすべてLinus Torvaldsに提出します。カーネル全体のトップメンテナであるTorvaldsは、パッチがカーネルに含めるのに適しているかどうかの最終決定権を持っています。
歴史的な理由により、libdrmライブラリのソースコードはMesaプロジェクトの傘下で管理されています。[128]
歴史
1999年、 XFree86用のDRIを開発していたPrecision Insight社は、3dfxビデオカード用のDRMの最初のバージョンを、Mesaソースコード内に含まれるLinuxカーネルパッチとして作成した。[129]その年の後半、DRMコードはLinuxカーネル2.3.18のキャラクタデバイスディレクトリの下にメインライン化された。[130]その後数年間で、サポートされるビデオカードの数は増加した。2001年1月にLinux 2.4.0がリリースされたとき、3dfx Voodoo3カードに加えて、Creative Labs GMX 2000、Intel i810、Matrox G200/G400、ATI Rage 128が既にサポートされていた。[131]そして、2.4.xシリーズの間にそのリストは拡大し、ATI Radeonカード、一部のSiSビデオカード、Intel 830Mとその後の統合GPU用のドライバーが追加された。
/drivers/char/drm/
DRMをDRMコアとDRMドライバの2つのコンポーネントに分割する作業は、DRMコア/パーソナリティ分割と呼ばれ、 2004年後半に実施され、[11] [132]カーネルバージョン2.6.11に統合されました。[133]この分割により、複数のデバイス用の複数のDRMドライバが同時に動作できるようになり、マルチGPUサポートへの道が開かれました。
ビデオモード設定コードをすべてカーネル内の1か所に置くというアイデアは何年も前から認められていたが、[134] [135]グラフィックカード製造業者は、モード設定を行う唯一の方法は、各グラフィックカードのビデオBIOSに含まれる自社提供のルーチンを使用することだと主張していた。そのようなコードはx86リアルモードを使用して実行する必要があり、保護モードで実行中のカーネルによって呼び出されることを防いでいた。[44] Luc Verhaegenと他の開発者がBIOSベースではなくネイティブにモード設定を行う方法を発見し、[136] [44]通常のカーネルコードを使用してそれが可能であることを示し、カーネルモード設定となるものの基礎を築いたことで状況は変わった。2007年5月、Jesse Barnes ( Intel )は、i915 DRMドライバ内でIntel GPUのモード設定のネイティブ実装とdrm-modesetting APIの最初の提案を公開した。 [42] 2007年12月、ジェローム・グリッセはATIカードのネイティブモード設定コードをRadeon DRMドライバに追加し始めた。[137] [138] APIとドライバの両方の作業は2008年も続けられたが、フレームバッファを処理するためにカーネル空間にもメモリマネージャが必要になったため遅れた。[139]
2008年10月、Linuxカーネル2.6.27では、いくつかの重要な変更に先立って、ソースコードが大幅に再編成されました。DRMソースコードツリーは独自のソースディレクトリに移動され/drivers/gpu/drm/、さまざまなドライバーは独自のサブディレクトリに移動されました。ヘッダーも新しい/include/drmディレクトリに移動されました。[140]
ビデオメモリ管理の複雑さが増すにつれ、この問題を解決するためのいくつかのアプローチが生まれました。最初の試みは、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に統合されました。 [141]一方、TTMは、新しいRadeon KMS DRMドライバーの要件として、最終的にLinux 2.6.31に統合されるまで、2009年9月まで待たなければなりませんでした。[142]
バッファオブジェクトを処理するためのメモリ管理が導入されたので、DRM開発者は、すでに完成していたモード設定を行うためのAPIとコードをカーネルにようやく追加できるようになりました。この拡張APIはカーネルモード設定（KMS）と呼ばれ、これを実装するドライバはKMSドライバと呼ばれることがよくあります。2009年3月、KMSはLinuxカーネルバージョン2.6.29に統合されました。 [30] [143] i915ドライバのKMSサポートとともに。[144] KMS APIは、libdrm 2.4.3以降、ユーザー空間プログラムに公開されています。[145] Intelグラフィックスカード用のユーザー空間X.Org DDXドライバも、新しいGEMおよびKMS APIを使用した最初のドライバでした。[146] radeon DRMドライバのKMSサポートは、2009年9月のLinux 2.6.31リリースに追加されました。[147] [148] [149]新しいradeon KMSドライバはTTMメモリマネージャを使用しましたが、TTMの代わりにGEM互換のインターフェイスとioctlを公開しました。[23]
2006年以来、nouveauプロジェクトは公式Linuxカーネルの外でNVIDIA GPU用のフリーソフトウェアDRMドライバーを開発してきました。2010年にnouveauのソースコードは実験的なドライバーとしてLinux 2.6.33に統合されました。 [58] [59]統合の時点で、ドライバーはすでにKMSに変換されており、GEM APIの背後ではTTMをメモリマネージャーとして使用していました。[150]
GEM API を含む新しい KMS API は DRM 開発における大きなマイルストーンでしたが、その後の数年間で API の機能強化が止まることはありませんでした。KMS はLinux 2.6.33 で非同期VBLANK通知と連動したページ フリップのサポートを獲得しました[151] [152] — i915 ドライバーのみを対象とし、radeon と nouveau は後に Linux 2.6.38 リリース中にこれを追加しました。[153]新しいページ フリップ インターフェイスは libdrm 2.4.17 に追加されました。[154] 2011 年初頭、Linux 2.6.39 リリース サイクル中に、いわゆるダム バッファー— フレームバッファーとして使用するのに適した単純なバッファーを処理するためのハードウェアに依存しない非加速方法 — が KMS API に追加されました。[155] [156]目標は、ドライバ固有のioctlによって提供される特別な加速操作を使用する必要のないPlymouthなどのアプリケーションの複雑さを軽減することでした。 [157]この機能は、libdrmバージョン2.4.25以降で公開されました。[158]その年の後半には、プレーンと呼ばれる新しい主要なオブジェクトタイプも追加されました。プレーンは、スキャンアウトエンジンによってサポートされるハードウェアオーバーレイを表すために開発されました。[159] [160]プレーンのサポートは、Linux 3.3. [161]およびlibdrm 2.4.30に統合されました。 Linux 3.5 [162]およびlibdrm 2.4.36 [163]リリース中にAPIに追加されたもう1つの概念は、汎用オブジェクトプロパティです。これは、任意のKMSオブジェクトに汎用的な値を追加する方法です。プロパティは、CRTCやプレーンなどのオブジェクトに特別な動作や機能を設定する場合に特に役立ちます。
DRM ドライバー間の GPU オフロードを提供するための初期の概念実証は、2010 年に Dave Airlie によって開発されました。[7] [164] Airlie はNVIDIA Optimus技術を模倣しようとしていたため、これを「PRIME」と名付けることにしました。[7] Airlie は 2011 年後半に PRIME の作業を再開しましたが、Linux カーネル 3.3 で導入された新しいDMA-BUFバッファー共有メカニズムに基づいていました。[165]基本的な DMA-BUF PRIME インフラストラクチャは 2012 年 3 月に完成し[166]、Linux 3.4 リリースに統合されました。[167] [168] [169]また、libdrm 2.4.34 にも統合されました。[170]その後、Linux 3.5 リリース中に、Intel カード用の i915、AMD カード用の radeon、NVIDIA カード用の nouveau など、いくつかの DRM ドライバーが PRIME サポートを実装しました。[171] [172]
近年、DRM APIは、新機能や改良された機能により段階的に拡張されてきました。2013年には、GSoCの一環として、David Herrmannが複数のレンダリングノード機能を開発しました。[55]彼のコードは、Linuxカーネルバージョン3.12に実験的な機能として追加され、 [173] [174] i915、[175] radeon [176]およびnouveau [177]ドライバでサポートされ、Linux 3.17以降ではデフォルトで有効になっています。[77] 2014年にMatt Roper (Intel) がユニバーサルプレーン（または統合プレーン）のコンセプトを開発しました。これにより、フレームバッファ（プライマリプレーン）、オーバーレイ（セカンダリプレーン）、およびカーソル（カーソルプレーン）はすべて、統合APIを持つ単一のオブジェクトとして扱われます。[178]ユニバーサルプレーンのサポートにより、より少ない、より汎用的なioctlで、より一貫性のあるDRM APIが提供されます。[33] APIの下位互換性を維持するために、この機能はDRMコアによってDRMドライバが提供できる追加機能として公開されています。ユニバーサルプレーンのサポートはLinux 3.15 [179]とlibdrm 2.4.55で導入されました。[180] Intel i915 [181]などのいくつかのドライバではすでに実装されています。
最も最近の DRM API 拡張機能は、 DRM デバイスのモード設定とページ フリップ操作にアトミック性をもたらすアトミック モード設定API です。モード設定用のアトミック API のアイデアは、2012 年初頭に初めて提案されました。[182] Ville Syrjälä (Intel) が、このようなアトミック API の設計と実装を引き継ぎました。[183] 彼の作業に基づいて、Rob Clark ( Texas Instruments ) は、アトミック ページ フリップの実装を目指して同様のアプローチを採用しました。[184] 2013 年後半に、提案された両方の機能が 1 つの ioctl を使用して 1 つに統合されました。[185]これは要件であったため、この機能はユニバーサル プレーンのサポートがマージされる 2014 年半ばまで待たなければなりませんでした。[181] 2014年後半、アトミックコードはダニエル・ベッター（インテル）と他のDRM開発者によって大幅に強化されました[186] : 18 既存のKMSドライバーを新しいアトミックフレームワークに移行しやすくするためです。[187]この作業はすべて最終的にLinux 3.19 [188]とLinux 4.0 [189] [190] [191]リリースに統合され、Linux 4.2以降ではデフォルトで有効になっています。[192] libdrmはバージョン2.4.62以降、新しいアトミックAPIを公開しています。[193]複数のドライバーがすでに新しいアトミックAPIに変換されています。[194] 2018年までに、この新しいアトミックモデルに基づく10の新しいDRMドライバーがLinuxカーネルに追加されました。[195]
採択
Direct Rendering Managerカーネルサブシステムは、当初はXFree86 4.0ディスプレイサーバーの新しいDirect Rendering Infrastructureで使用するために開発され、後に後継のX.Org Serverに継承されました。したがって、DRMの主なユーザーは、Mesa 3DライブラリにあるハードウェアアクセラレーションOpenGL実装にリンクするDRIクライアントと、X Server自体でした。今日では、DRMはWestonリファレンスコンポジターを含むいくつかのWaylandコンポジターでも使用されています。kmsconは、 DRM KMS機能を使用してユーザースペースで実行される仮想コンソール実装です。[196]
2015年、独自のNvidia GeForceドライバのバージョン358.09（ベータ版）は、と呼ばれる新しいカーネルブロブとして実装されたDRMモード設定インターフェースのサポートを受けましたnvidia-modeset.ko。この新しいドライバコンポーネントはカーネルモジュールと連携してnvidia.ko、GPUのディスプレイエンジン（ディスプレイコントローラ）をプログラムします。[197]
参照
.svg/500px-Free_and_open-source_software_logo_(2009).svg.png){kind=logo}
参考文献
- ^ 「Linux kernel/drivers/gpu/drm/README.drm」。kernel.org 。 2014年2月26日時点のオリジナルよりアーカイブ。2014年2月26日閲覧。
- ^ ab ウ イッターホーフェン、ギアルト。 「フレームバッファデバイス」。カーネル.org 。2015 年1 月 28 日に取得。
- ^ abc White, Thomas. 「DRI と DRM の仕組み」 。2014年7 月 22 日閲覧。
- ^ Faith, Rickard E. (1999 年 5 月 11 日). 「ダイレクト レンダリング マネージャー: ダイレクト レンダリング インフラストラクチャのカーネル サポート」。2016 年 5 月 24 日時点のオリジナルよりアーカイブ。2016 年5 月 12 日閲覧。
- ^ abcdefgh Corbet, Jonathan (2007 年 11 月 6 日). 「グラフィック プロセッサのメモリ管理」. LWN.net . 2014 年7 月 23 日閲覧。
- ^ abcdefg Packard, Keith; Anholt, Eric (2008 年 5 月 13 日). 「GEM - the Graphics Execution Manager」. dri-devel メーリング リスト. 2014 年7 月 23 日閲覧。
- ^ abc Airlie, Dave (2010年3月12日). 「GPUオフロード - PRIME - 概念実証」。2015年2月10日時点のオリジナルよりアーカイブ。2015年2月10日閲覧。
- ^ abcde Kitching, Simon. 「DRM および KMS カーネル モジュール」 。2016年5 月 13 日閲覧。
- ^ abcde Herrmann, David (2013 年 9 月 1 日). 「DRM と KMS デバイス ノードの分割」 . 2014 年7 月 23 日閲覧。
- ^ 「README.rst - mesa/drm - Direct Rendering Manager ヘッダーとカーネルモジュール」。2020-03-21。2020-03-21時点のオリジナルよりアーカイブ。
- ^ ab Airlie, Dave (2004 年 9 月 4 日). 「新しく提案された DRM インターフェース設計」. dri-devel (メーリング リスト).
- ^ abcdefg Peres, Martin; Ravier, Timothée (2013 年 2 月 2 日). 「DRI-next/DRM2: Linux グラフィックス スタックとそのセキュリティのウォークスルー」(PDF) 。2016年5 月 13 日閲覧。
- ^ クリスチャン、ホーグスバーグ (2008 年 9 月 4 日)。 「DRI2 拡張機能 - バージョン 2.0」。X.組織。2016 年5 月 23 日に取得。
- ^ abcdef Barnes, Jesse; Pinchart, Laurent; Vetter, Daniel; Wunner, Lukas. 「Linux GPU ドライバー開発者ガイド - メモリ管理」 。2016年8 月 31 日閲覧。
- ^ Vetter, Daniel. 「i915/GEM Crashcourse by Daniel Vetter」。Intel Open Source Technology Center 。 2015年1月31日閲覧。GEM
は基本的にグラフィックス バッファ オブジェクト (テクスチャ、レンダバッファ、シェーダ、または GPU が使用するその他のあらゆる種類の状態オブジェクトとデータを含む) を扱います。
- ^ abc Vetter, Daniel (2011年5月4日). 「GEMの概要」 . 2015年2月13日閲覧。
- ^ Packard, Keith (2012 年 9 月 28 日). 「DRI.Next についての考察」 . 2016 年5 月 26 日閲覧。GEM flink には多くの問題があります。flink
名はグローバルであるため、デバイスにアクセスできる人なら誰でも flink データの内容にアクセスできます。
- ^ ab Herrmann, David (2013 年 7 月 2 日)。「DRM セキュリティ」。2013 X.Org Developer's Conference (XDC2013) Proceedings。2015年2 月 13 日閲覧。gem
-flink は、アプリケーションやサーバーにプライベート名前空間を提供しません。代わりに、DRM ノードごとに 1 つのグローバル名前空間のみが提供されます。悪意のある認証済みアプリケーションは、gem バッファーのブルートフォース「名前推測」を介して他のクライアントを攻撃できます。
- ^ Kerrisk, Michael (2012 年 9 月 25 日). 「XDC2012: グラフィックス スタックのセキュリティ」. LWN.net . 2015 年11 月 25 日閲覧。
- ^ ab Packard, Keith (2008年7月4日). 「gem update」 . 2016年4月25日閲覧。
- ^ 「drm-memory man page」。Ubuntu マニュアル。2015年1 月 29 日閲覧。
最近のハイエンド GPU の多くには、独自のメモリ マネージャーが搭載されています。アクセス中に同期する必要のある複数の異なるキャッシュも含まれています。[...] そのため、GPU のメモリ管理は、ドライバーとハードウェアに大きく依存します。
- ^ 「Intel Graphics Media Accelerator 開発者ガイド」。Intel Corporation。2015年11 月 24 日閲覧。
- ^ abc Larabel, Michael (2008 年 8 月 26 日). 「A GEM-ified TTM Manager For Radeon」. Phoronix . 2016 年4 月 24 日閲覧。
- ^ abc Corbet, Jonathan (2008年5月28日). 「GEM v. TTM」. LWN.net . 2015年2月10日閲覧。
- ^ Corbet, Jonathan (2012 年 1 月 11 日). 「3.3 での DMA バッファー共有」. LWN.net . 2016 年5 月 14 日閲覧。
- ^ Clark, Rob; Semwal, Sumit. 「DMA バッファー共有フレームワーク: 概要」(PDF) 。2016 年5 月 14 日閲覧。
- ^ Peres, Martin (2014 年 9 月 26 日). 「Linux グラフィックス スタック、Optimus、Nouveau ドライバー」(PDF) 。2016 年5 月 14 日閲覧。
- ^ Pinchart, Laurent (2013 年 2 月 20 日). 「組み込み KMS ドライバーの構造」(PDF) . 2016 年6 月 27 日閲覧。
- ^ Edge, Jake (2013年10月9日). 「DRI3と現在」. LWN.net . 2016年5月28日閲覧。
- ^ abcd 「Linux 2.6.29 - カーネルモード設定」。Linuxカーネル初心者。 2015年11月19日閲覧。
- ^ 「VGA ハードウェア」。OSDev.org。2015年11 月 23 日閲覧。
- ^ Rathmann, B. (2008 年 2 月 15 日). 「Nouveau の現状、パート I」. LWN.net . 2015 年11 月 23 日閲覧。
グラフィックス カードはさまざまな方法でプログラムされますが、ほとんどの初期化とモード設定はメモリ マップ IO を介して行われます。これは、CPU の標準メモリ アドレス空間を介してアクセスできるレジスタのセットです。このアドレス空間のレジスタは、モード設定、出力制御、クロック構成など、グラフィックス カードのさまざまな機能を処理する範囲に分割されています。
- ^ abcde Paalanen, Pekka (2014年6月5日). 「先史時代から世界的熱核戦争の先へ」2014年7月29日閲覧。
- ^ 「drm-kms man page」。Ubuntuマニュアル。2015年11 月 19 日閲覧。
- ^ Corbet, Jonathan (2010 年 1 月 13 日). 「ユーザー空間モード設定の終了?」LWN.net . 2015 年11 月 20 日閲覧。
- ^ ab 「モード設定設計に関する議論」。X.Org Wiki 。 2015年11月19日閲覧。
- ^ ab Corbet, Jonathan (2007 年 1 月 22 日). 「LCA: X Window System のアップデート」. LWN.net . 2015 年11 月 23 日閲覧。
- ^ 「XF86VIDMODE マニュアルページ」X.Org . 2016年4月23日閲覧。
- ^ 「X11R6.1 リリースノート」。X.Org。1996年3月14日。 2016年4月23日閲覧。
- ^ Corbet, Jonathan (2004 年 7 月 20 日). 「Kernel Summit: ビデオ ドライバー」. LWN.net . 2015 年11 月 23 日閲覧。
- ^ ab "Fedora - Features/KernelModeSetting". Fedora プロジェクト。2015年11 月 20 日閲覧。
歴史的には、X サーバーは起動時に出力状態を保存し、テキスト モードに戻ったときにそれを復元する役割を担っていました。高速ユーザー切り替えは VT スイッチで実現されていたため、最初のユーザーの X サーバーから切り替えると、テキスト モードに切り替えるために 1 回点滅し、すぐに 2 番目のユーザーのセッションに切り替えるためにもう一度点滅していました。
- ^ abcde Barnes, Jesse (2007 年 5 月 17 日). 「[RFC] カーネルのグラフィックス サブシステムの強化」. linux-kernel (メーリング リスト).
- ^ abc 「DrmModesetting - カーネルグラフィックス強化」。DRI Wiki 。 2015年11月23日閲覧。
- ^ abcde Packard, Keith (2007年9月16日). 「kernel-mode-drivers」 . 2016年4月30日閲覧。
- ^ ab Packard, Keith (2000 年 4 月 24 日). 「Intel ドライバーの焦点を絞る」。2016 年5 月 23 日閲覧。
より微妙な制限は、ドライバーが割り込みを処理できなかったため、ホットプラグ モニターがサポートされていなかったことです。
- ^ Barnes, Jesse; Pinchart, Laurent; Vetter, Daniel; Wunner, Lukas. 「Linux GPU ドライバー開発者ガイド - ドライバーの初期化」 。2016年8 月 31 日閲覧。
- ^ "q3k (@q3k@hackerspace.pl)". Warsaw Hackerspace Social Club . 2023-01-31 . 2023-02-13に取得。
DRM/KMS ドライバーは完全に動作するようになりましたが、DMA はまだありません。 ああ、これは Rust で書かれていますが、ほとんどが生の安全でないブロックでいっぱいです。
- ^ "q3k (@q3k@hackerspace.pl)". Warsaw Hackerspace Social Club . 2023-01-31 . 2023-02-13に取得。
素晴らしいのは、通常の DRM/KMS ドライバー (および @emersion@hackerspace.pl の支援) があるため、次のようなことが可能です...Wayland! Weston を iPod Nano 5G で実行します。
- ^ abcdefg Barnes, Jesse; Pinchart, Laurent; Vetter, Daniel; Wunner, Lukas. 「Linux GPU ドライバー開発者ガイド - KMS の初期化とクリーンアップ」 。2016年8 月 31 日閲覧。
- ^ ab 「ビデオカード」。X.Org Wiki 。 2016年4月11日閲覧。
- ^ ab Deucher, Alex (2010年4月15日). 「Radeonディスプレイハードウェアに関するメモ」。2016年4月5日時点のオリジナルよりアーカイブ。2016年4月8日閲覧。
- ^ abcde Vetter, Daniel (2015年8月5日). 「Atomic mode setting design summary, part 1」. LWN.net . 2016年5月7日閲覧。
- ^ ab Reding, Thierry (2015年2月1日). 「Atomic Mode-Setting」(PDF) . FOSDEM アーカイブ. 2016年5月7日閲覧。
- ^ Vetter, Daniel (2015年8月12日). 「Atomic mode setting design summary, part 2」. LWN.net . 2016年5月7日閲覧。
- ^ abc Herrmann, David (2013年5月29日). 「DRM Render- and Modeset-Nodes」 . 2014年7月21日閲覧。
- ^ abcd Barnes, Jesse; Pinchart, Laurent; Vetter, Daniel; Wunner, Lukas. 「Linux GPU ドライバー開発者ガイド - レンダリングノード」 。2016年8 月 31 日閲覧。
- ^ ab Deucher, Alex (2015 年 4 月 20 日). 「amdgpu ドライバーの初期リリース」. dri-devel (メーリング リスト).
- ^ ab 「Linux 2.6.33 - Nouveau、Nvidia グラフィック カード用ドライバー」。Linux Kernel Newbies。2016年4 月 26 日閲覧。
- ^ ab "drm/nouveau: NVIDIA GPU 用の DRM ドライバーを追加". Kernel.org . 2015 年1 月 27 日閲覧。
- ^ 「DRM: Samsung SoC EXYNOS4210 用の DRM ドライバーを追加」Kernel.org 。2016年3 月 3 日閲覧。
- ^ 「vmwgfx: ドライバーをステージングから外す」Kernel.org 。2016年3 月 3 日閲覧。
- ^ 「Linux 3.3 - DriverArch - グラフィックス」。Linux Kernel Newbies。2016年3 月 3 日閲覧。
- ^ Larabel, Michael (2012 年 1 月 10 日). 「Linux 3.3 DRM の強化は多岐にわたる」. Phoronix . 2016 年3 月 3 日閲覧。
- ^ 「drm: AST (ASpeed Technologies) 2000 シリーズ用の初期 KMS ドライバー (v2)」。Kernel.org。2016年3 月 3 日閲覧。
- ^ Airlie, Dave (2012年5月17日). 「mgag200: initial g200se driver (v2)」 . 2018年1月24日閲覧。
- ^ 「drm: Renesas SH Mobile DRM ドライバー」Kernel.org . 2016 年3 月 3 日閲覧。
- ^ 「drm: NVIDIA Tegra20 サポートを追加」Kernel.org . 2016 年3 月 3 日閲覧。
- ^ 「drm/omap: ステージングから移動」Kernel.org . 2016年3月3日閲覧。
- ^ 「drm: Renesas R-Car ディスプレイユニット DRM ドライバー」Kernel.org 。2016 年3 月 3 日閲覧。
- ^ 「drm/msm: snapdragon 用の基本 KMS ドライバー」Kernel.org 。2016年3 月 3 日閲覧。
- ^ Larabel, Michael (2013 年 8 月 28 日). 「Snapdragon DRM/KMS ドライバーが Linux 3.12 に統合」. Phoronix . 2015 年1 月 26 日閲覧。
- ^ Edge, Jake (2015 年 4 月 8 日). 「freedreno グラフィック ドライバーのアップデート」. LWN.net . 2015 年4 月 23 日閲覧。
- ^ King, Russell (2013 年 10 月 18 日). 「[GIT PULL] Armada DRM サポート」. dri-devel (メーリング リスト).
- ^ 「DRM: Armada: Armada DRM ドライバーの追加」Kernel.org。2016年3 月 3 日閲覧。
- ^ 「drm/bochs: 新しいドライバー」Kernel.org . 2016年3月3日閲覧。
- ^ Larabel, Michael (2014 年 8 月 8 日). 「Linux 3.17 DRM Pull で新しいグラフィック ドライバーが提供」. Phoronix . 2016 年3 月 3 日閲覧。
- ^ ab Corbet, Jonathan (2014 年 8 月 13 日). 「3.17 マージウィンドウ、パート 2」. LWN.net . 2014 年10 月 7 日閲覧。
- ^ ab Corbet, Jonathan (2014 年 12 月 17 日). 「3.19 Merge window part 2」. LWN.net . 2015 年2 月 9 日閲覧。
- ^ 「drm: imx: imx-drm ドライバーをステージングから移動」Kernel.org 。2015年2 月 9 日閲覧。
- ^ 「drm: rockchip: 基本的な drm ドライバーの追加」Kernel.org。2016年3 月 3 日閲覧。
- ^ Larabel, Michael (2015 年 6 月 25 日). 「Linux 4.2 DRM アップデート: AMD が注目、Nouveau ドライバーの変更なし」. Phoronix . 2015 年8 月 31 日閲覧。
- ^ Corbet, Jonathan (2015 年 7 月 1 日). 「4.2 マージウィンドウ パート 2」. LWN.net . 2015 年8 月 31 日閲覧。
- ^ Deucher, Alex (2015 年 8 月 3 日). 「[PATCH 00/11] Fiji サポートを追加」. dri-devel (メーリング リスト).
- ^ 「virtio gpu ドライバーの追加」Kernel.org。2016年3 月 3 日閲覧。
- ^ Corbet, Jonathan (2015 年 11 月 11 日). 「4.4 マージウィンドウ、パート 1」. LWN.net . 2016 年1 月 11 日閲覧。
- ^ Larabel, Michael (2015 年 11 月 15 日). 「Linux 4.4 カーネルの新機能の概要」. Phoronix . 2016 年1 月 11 日閲覧。
- ^ 「drm/vc4: Raspberry Pi に KMS サポートを追加」Kernel.org。
- ^ Larabel, Michael (2016 年 1 月 24 日). 「Linux 4.5 カーネルの多くの新機能と改善点」. Phoronix . 2016 年3 月 14 日閲覧。
- ^ Corbet, Jonathan (2016 年 1 月 20 日). 「4.5 マージウィンドウ パート 2」. LWN.Net . 2016 年3 月 14 日閲覧。
- ^ 「タグ 'sun4i-drm-for-4.7' をマージ」Kernel.org。
- ^ abc Airlie, Dave (2016 年 5 月 23 日). 「[git pull] drm for v4.7」. dri-devel (メーリング リスト).
- ^ 「タグ 'drm-hisilicon-next-2016-04-29' をマージ」Kernel.org。
- ^ 「タグ 'mediatek-drm-2016-05-09' をマージ」Kernel.org。
- ^ Larabel, Michael (2016 年 11 月 22 日). 「Hisilicon Hibmc DRM ドライバーが Linux 4.10 に追加されました」. Phoronix . 2018 年1 月 24 日閲覧。
- ^ 「Huawei FusionServer RH5885 V3 テクニカルホワイトペーパー」。2016年11月18日。2018年1月25日時点のオリジナルからアーカイブ。
管理チップHi1710に統合されたオンボードディスプレイチップを使用し、SM750のIPコアを使用しています。
- ^ 「drm/vkms: 基本的な VKMS ドライバーの導入」. git.kernel.org . 2022 年 7 月 20 日閲覧。
- ^ Larabel, Michael (2018年8月15日). 「Linux 4.19に仮想カーネルモード設定ドライバーが追加されました」. Phoronix . 2022年7月20日閲覧。
- ^ 「kernel/git/torvalds/linux.git - Linuxカーネルソースツリー」。git.kernel.org 。2019年11月28日閲覧。
- ^ abc Larabel, Michael (2019年5月9日). 「Linux 5.2 DRM により Icelake が製品版に対応、Lima および Panfrost ドライバーを追加」. Phoronix . 2022年7月20日閲覧。
- ^ 「kernel/git/torvalds/linux.git - Linuxカーネルソースツリー」。git.kernel.org 。2019年11月28日閲覧。
- ^ 「drm/vboxvideo: vboxvideo ドライバーをステージングから移動」。git.kernel.org。2022年 7 月 20 日閲覧。
- ^ 「drm/hyperv: hyperv 合成ビデオデバイス用の DRM ドライバーを追加」。git.kernel.org 。2021 年 8 月 30 日閲覧。
- ^ Larabel, Michael (2021年6月9日). 「MicrosoftのHyper-V DRMディスプレイドライバーがLinux 5.14に登場」. Phoronix . 2021年8月30日閲覧。
- ^ 「drm: simpledrm ドライバーを追加」。git.kernel.org 。2021年 8 月 30 日閲覧。
- ^ Larabel, Michael (2021年5月13日). 「Linux 5.14 で SimpleDRM ドライバー、VC4 HDR が導入され、AGP コードをさらにレガシーとしてマーク」Phoronix . 2021年8月30日閲覧。
- ^ 「drm/ofdrm: Open Firmware フレームバッファー用の ofdrm を追加」。git.kernel.org 。2023年2 月 21 日閲覧。
- ^ Larabel, Michael (2022年10月20日). 「Linux 6.2用のOpen Firmware DRMドライバー「OFDRM」キューイング」。Phoronix . 2023年2月21日閲覧。
- ^ 「drm: loongson ディスプレイ コントローラー用の kms ドライバーを追加」。git.kernel.org。2024年2 月 23 日閲覧。
- ^ Larabel, Michael (2023年7月13日). 「Linux 6.6のオープンソースグラフィックドライバーアップデートがキューイング開始」. Phoronix . 2024年2月23日閲覧。
- ^ 「drm/imagination: スケルトン PowerVR ドライバーを追加」。git.kernel.org。2024年5月 27 日閲覧。
- ^ Larabel, Michael (2023年11月23日). 「Imagination PowerVRオープンソースGPUドライバーがLinux 6.8で導入される」. Phoronix . 2024年5月27日閲覧。
- ^ 「drm/xe: Intel GPU 用の新しい DRM ドライバーを導入」。git.kernel.org。2024年5月 27 日閲覧。
- ^ Larabel, Michael (2023年12月15日). 「Intelの新しい「Xe」カーネルグラフィックスドライバーがLinux 6.8に先駆けて提出」. Phoronix . 2024年5月27日閲覧。
- ^ 「drm: ガンマ ドライバーを削除する」Kernel.org。2015年1 月 27 日閲覧。
- ^ 「[DRM]: ビルドされないsparc64 FFBドライバコードを削除する」Kernel.org 。 2015年1月27日閲覧。
- ^ 「drm: 廃止されたドライバー tdfx を削除する」Kernel.org 。2024年2 月 23 日閲覧。
- ^ 「drm: 廃止されたドライバー-mga を削除する」Kernel.org 。2024年2 月 23 日閲覧。
- ^ 「drm: 古いドライバー r128 を削除する」Kernel.org 。2024年2 月 23 日閲覧。
- ^ 「drm: 廃止されたドライバー i810 を削除する」Kernel.org 。2024年2 月 23 日閲覧。
- ^ 「drm: 廃止されたドライバー sis を削除する」Kernel.org 。2024年2 月 23 日閲覧。
- ^ 「drm: i830 ドライバーを削除」Kernel.org . 2015 年1 月 27 日閲覧。
- ^ 「drm: unichrome サポート経由で追加」Kernel.org 。2015年1 月 27 日閲覧。
- ^ 「drm: 古いドライバーを削除する - via」Kernel.org 。 2024年2月23日閲覧。
- ^ 「drm: add savage driver」Kernel.org . 2015年1月27日閲覧。
- ^ 「drm: 廃止されたドライバー savage を削除する」Kernel.org 。2024年2 月 23 日閲覧。
- ^ 「Linuxカーネルのメンテナーのリスト」Kernel.org 。 2014年7月14日閲覧。
- ^ 「libdrm git リポジトリ」 。2014年7 月 23 日閲覧。
- ^ 「3dfx ドライバーの最初の DRI リリース」Mesa 3D。2014年7 月 15 日閲覧。
- ^ 「Import 2.3.18pre1」。GITリポジトリ形式でのLinuxの歴史 1992-2010 (2010) 。 2014年7月15日閲覧。
- ^ Torvalds, Linus. 「Linux 2.4.0 ソースコード」Kernel.org 。 2014年7月29日閲覧。
- ^ Airlie, Dave (2004 年 12 月 30 日). 「[bk pull] drm core/personality split」. linux-kernel (メーリング リスト).
- ^ Torvalds, Linus (2005 年 1 月 11 日). 「Linux 2.6.11-rc1」. linux-kernel (メーリング リスト).
- ^ Gettys, James; Packard, Keith (2004 年 6 月 15 日). 「X ウィンドウ システムの (再) アーキテクチャ」 . 2016 年4 月 30 日閲覧。
- ^ Smirl, Jon (2005 年 8 月 30 日). 「Linux グラフィックスの現状」 . 2016 年4 月 30 日閲覧.
この問題に対する最善の解決策は、カーネルが各ビデオ ハードウェアに対して単一の包括的なデバイス ドライバーを提供することだと考えています。これは、fbdev や DRM などの競合するドライバーを連携システムに統合する必要があることを意味します。また、カーネル ベースのデバイス ドライバーがロードされている間は、ユーザー空間からハードウェアを操作することを防ぐ必要があることも意味します。
- ^ Verhaegen, Luc (2006 年 3 月 2 日). 「X とモード設定: 萎縮の図解」(PDF) 。2016 年4 月 30 日閲覧。
- ^ Glisse, Jerome (2007 年 12 月 4 日). 「Radeon カーネル モード設定」 . 2016 年4 月 30 日閲覧。
- ^ Larabel, Michael (2008 年 10 月 1 日). 「カーネル モード設定の現状」. Phoronix . 2016 年4 月 30 日閲覧。
- ^ Packard, Keith (2008年7月21日). 「X output status july 2008」 . 2016年5月1日閲覧。
- ^ 「drm: 将来性を高めるために drm ツリーを再編成」Kernel.org。
- ^ 「Linux 2.6.28 - GPU メモリ用の GEM メモリ マネージャー」。Linux Kernel Newbies。2014年7 月 23 日閲覧。
- ^ 「drm: TTM GPU メモリ マネージャー サブシステムを追加する」。Kernel.org。
- ^ 「DRM: モード設定サポートを追加」Kernel.org。
- ^ 「DRM: i915: モード設定サポートを追加」Kernel.org。
- ^ Anholt, Eric (2008 年 12 月 22 日). 「[ANNOUNCE] libdrm-2.4.3」. dri-devel (メーリング リスト).
- ^ Barnes, Jesse (2008 年 10 月 20 日). 「[ANNOUNCE] xf86-video-intel 2.5.0」. xorg-announce (メーリング リスト).
- ^ 「Linux 2.6.31 - ATI Radeon カーネルモード設定のサポート」。Linux Kernel Newbies。2015年11月5日時点のオリジナルよりアーカイブ。2016年4月28日閲覧。
- ^ Torvalds, Linus (2009 年 9 月 9 日). 「Linux 2.6.31」. linux-kernel (メーリング リスト).
- ^ 「drm/radeon: radeon ハードウェア用のカーネル モード設定を導入」Kernel.org。
- ^ 「The irregiver Nouveau Development Companion #40」Nouveau プロジェクト2016 年5 月 3 日閲覧。
- ^ 「Linux 2.6.33 - グラフィックの改善」。Linux Kernel Newbies 。 2016年4月28日閲覧。
- ^ 「drm/kms: ページ反転 ioctl を追加」。Kernel.org。
- ^ 「Linux 2.6.38 - グラフィックス」。Linux Kernel Newbies 。 2016年4月28日閲覧。
- ^ Airlie, Dave (2009 年 12 月 21 日). 「[ANNOUNCE] libdrm 2.4.17」. dri-devel (メーリング リスト).
- ^ 「drm: intel / radeon (v3) 用のダム スキャンアウト作成/mmap」Kernel.org 。
- ^ 「Linux 2 6 39-DriversArch」。Linux Kernel Newbies 。 2016年4月19日閲覧。
- ^ Barnes, Jesse; Pinchart, Laurent; Vetter, Daniel; Wunner, Lukas. 「Linux GPU ドライバー開発者ガイド - ダム バッファー オブジェクト」 。2016年8 月 31 日閲覧。
- ^ Wilson, Chris (2011 年 4 月 11 日). 「[ANNOUNCE] libdrm 2.4.25」. dri-devel (メーリング リスト).
- ^ Barnes, Jesse (2011 年 4 月 25 日). 「[RFC] drm: オーバーレイをファーストクラス KMS オブジェクトとして追加」. dri-devel (メーリング リスト).
- ^ Barnes, Jesse (2011 年 5 月 13 日). 「[RFC] drm: オーバーレイをファーストクラス KMS オブジェクトとして追加」. dri-devel (メーリング リスト).
- ^ 「drm: プレーンサポート v3 を追加」Kernel.org。
- ^ 「drm: あらゆるオブジェクトのプロパティを取得/設定するための汎用 ioctl を追加」Kernel.org。
- ^ Widawsky, Ben (2012 年 6 月 27 日). 「[ANNOUNCE] libdrm 2.4.36」. xorg-announce (メーリング リスト).
- ^ Larabel, Michael. 「概念実証: オープンソースのマルチ GPU レンダリング!」. Phoronix . 2016 年4 月 14 日閲覧。
- ^ Larabel, Michael (2012 年 2 月 23 日). 「DRM Base PRIME Support Part Of VGEM Work」. Phoronix . 2016 年4 月 14 日閲覧。
- ^ Airlie, Dave (2012 年 3 月 27 日). 「[PATCH] drm: base prime/dma-buf サポート (v5)」. dri-devel (メーリング リスト).
- ^ Larabel, Michael (2012 年 3 月 30 日). 「Linux 3.4 の最後の瞬間: DMA-BUF PRIME サポート」. Phoronix . 2016 年4 月 15 日閲覧。
- ^ 「drm: base prime/dma-buf サポート (v5)」。Kernel.org。
- ^ 「Linux 3.4 DriverArch」。Linux Kernel Newbies 。 2016年4月15日閲覧。
- ^ Anholt, Eric (2012 年 5 月 10 日). 「[ANNOUNCE] libdrm 2.4.34」. dri-devel (メーリング リスト).
- ^ Larabel, Michael (2012 年 5 月 12 日). 「DMA-BUF PRIME Coming Together For Linux 3.5」. Phoronix . 2016 年4 月 15 日閲覧。
- ^ 「Linux 3.5 DriverArch」。Linux Kernel Newbies 。 2016年4月15日閲覧。
- ^ Corbet, Jonathan (2013 年 9 月 11 日). 「3.12 マージウィンドウ、パート 2」. LWN.net . 2014 年7 月 21 日閲覧。
- ^ 「drm: 実験的なレンダリングノードを実装する」Kernel.org。
- ^ 「drm/i915: レンダリングノードのサポート」Kernel.org。
- ^ 「drm/radeon: レンダリングノードのサポート」Kernel.org。
- ^ 「drm/nouveau: レンダリングノードのサポート」Kernel.org。
- ^ Roper, Matt (2014 年 3 月 7 日). 「[RFCv2 00/10] ユニバーサル プレーン サポート」. dri-devel (メーリング リスト).
- ^ Larabel, Michael (2014 年 4 月 2 日). 「Linux 3.15 用のユニバーサル プレーン サポート セット」. Phoronix . 2016 年4 月 14 日閲覧。
- ^ マールテン州ランクホルスト (2014 年 7 月 25 日)。 「[お知らせ] libdrm 2.4.55」。dri-devel (メーリングリスト)。
- ^ ab Vetter, Daniel (2014年8月7日). 「3.17向けのすばらしい機能」 . 2016年4月14日閲覧。
- ^ Barnes, Jesse (2012 年 2 月 15 日). 「[RFC] drm: アトミック モード セット API」. dri-devel (メーリング リスト).
- ^ Syrjälä, Ville (2012 年 5 月 24 日). 「[RFC][PATCH 0/6] WIP: drm: Atomic モード設定のアイデア」. dri-devel (メーリング リスト).
- ^ Clark, Rob (2012年9月9日). 「[RFC 0/9] 核ページフリップ」. dri-devel (メーリングリスト).
- ^ Clark, Rob (2013 年 10 月 6 日). 「[RFCv1 00/12] Atomic/nuclear modeset/pageflip」. dri-devel (メーリング リスト).
- ^ Vetter, Daniel (2016年2月3日). 「Atomic Display Ageを受け入れよう」(PDF) 。 2016年5月4日閲覧。
- ^ Vetter, Daniel (2014 年 11 月 2 日). 「KMS ドライバーの Atomic Modeset サポート」 . 2016 年5 月 4 日閲覧。
- ^ Airlie, Dave (2014 年 12 月 14 日). 「[git pull] drm for 3.19-rc1」. dri-devel (メーリング リスト).
- ^ Vetter, Daniel (2015年1月28日). 「Atomic Display Updates のアップデート」 . 2016年5月4日閲覧。
- ^ Airlie, Dave (2015 年 2 月 15 日). 「[git pull] drm pull for 3.20-rc1」. dri-devel (メーリング リスト).
- ^ 「Linux 4.0 - DriverArch - グラフィックス」。Linux Kernel Newbies 。 2016年5月3日閲覧。
- ^ 「Linux 4.2 - Atomic modesetting API がデフォルトで有効化」Linux Kernel Newbies . 2016 年5 月 3 日閲覧。
- ^ Velikov, Emil (2015 年 6 月 29 日). 「[ANNOUNCE] libdrm 2.4.62」. dri-devel (メーリング リスト).
- ^ Vetter, Daniel (2016 年 6 月 6 日). 「素晴らしいアトミックの進歩」. 2016 年6 月 7 日閲覧.
現在、DRM サブシステムに統合されたアトミック モード設定をサポートするドライバーは 17 個あります。
- ^ Stone, Daniel (2018年3月20日). 「Linuxの低レベルグラフィックスの新時代 - パート1」 。 2018年5月5日閲覧。
- ^ Herrmann, David (2012年12月10日). 「KMSCON 紹介」 . 2015年11月22日閲覧。
- ^ 「Linux、Solaris、FreeBSD ドライバー 358.09 (ベータ)」 2015 年 12 月 10 日。
外部リンク
- DRMホームページ
- Linux GPU ドライバー開発者ガイド (旧Linux DRM 開発者ガイド)
- Embedded Linux Conference 2013 - YouTubeでの組み込み KMS ドライバーの分析