自動ディスプレイ切り替え

重要

一部の情報はリリース前の製品に関する事項であり、正式版がリリースされるまでに大幅に変更される可能性があります。 Microsoft はここに示されている情報について、明示か黙示かを問わず、一切保証しません。

この記事では、ラップトップの内部パネルを統合 GPU (iGPU) とディスクリート GPU (dGPU) の間でシームレスに切り替えるサポートを提供する自動ディスプレイ切り替え (ADS) 機能について説明します。 ADS はオプションの WDDM 機能で、Windows 11 バージョン 24H2 更新プログラム 2025.01D (WDDM 3.2) 以降でサポートされています。

この記事の内容:

• GPU0 は、統合パネルが現在接続されている GPU を指します。
• GPU1 は、パネルが切り替えられる GPU を指します。

概要

一部のリリースされたノート パソコンにはマルチプレクサー (多重化) デバイスがあり、内蔵パネルを統合 GPU (iGPU) とディスクリート GPU (dGPU) 間で切り替えることができます。 グラフィックス ドライバーは現在、OS の知識がなくてもこれらのノート パソコンで切り替えをトリガーして実行するため、望ましくないユーザー エクスペリエンスが発生します。

ADSを使用すると、OSはシステム内のマルチプレクサーデバイスを制御して、内部パネルにスキャンアウトする際に、iGPUとdGPUを切り替えることができます。 そのため、OS は、より優れたユーザー エクスペリエンスを提供できます。

ADS の初期バージョンでは、iGPU と dGPU 間での内部パネルの切り替えのみがサポートされています。 将来的には、この機能が拡張され、ノート パソコンでの外部コネクタの多重化もサポートされる場合があります。

概要設計

一般に、システムは切り替えの進行中に内部パネルの内容のちらつきや誤作動がない状態で表示されるようにする必要があります。 OS では、この機能を特定のディスプレイ プロトコルに制限しません。 この記事では、eDP で ADS を実装する方法に焦点を当てていますが、使用できる業界標準 (MIPI や DSI など) が増えています。 他の OS を変更しなくても同じエクスペリエンスを実現できる場合、プラットフォームの設計では、別のディスプレイ接続プロトコルを自由に使用できます。

このセクションのサブセクションでは、機能の設計面を特定し、各側面の高度なアプローチについて詳しく説明します。

マルチプレクサー デバイスの制御

マルチプレクサーは、iGPU と dGPU のグラフィックス ドライバー間の依存関係を減らすために、グラフィックス ドライバーに依存せずに OS が制御できる独立したデバイスとして公開されます。 この方法の利点は次のとおりです。

1. ドライバーがOEMによって使用される可能性があるすべての異なるマルチプレクサの制御方法を知る必要がないため、グラフィックスドライバーの複雑さが軽減されます。
2. これにより、グラフィックス ドライバー間の依存関係が削減または排除され、ドライバーの更新が減り、OEM が GPU と多重化を簡単に選択できるようになります。
3. もしグラフィックスドライバーが利用できない場合、OSはマルチプレクサを切り替えることができます。

マルチプレクサー デバイスの公開

このソリューションは内部 iGPU と dGPU 間の多重化を目的としているため、ACPI 経由で多重化を公開することは理にかなっています。

マルチプレクサー ドライバーの機能

マルチプレクサードライバーは、以下の高レベルの機能要件を満たす必要があります。

1. ドライバーは、マルチプレクサーの状態、現在どのターゲットが内部パネルを制御しているか、また、機能制限がある場合はその制限を提供する必要があります。
2. 切り替えを開始し、切り替えの状態を報告する方法を指定する必要があります。

マルチプレクサー ACPI デバイスとそのメソッドの詳細については、「ACPI」をご覧ください。

シームレスに切り替えを実行するには、マルチプレクサ デバイスで GPU 切り替え中に常に次の条件が必要です。

1. パネルの電源。 マルチプレクサーには常時、いずれかの GPU によってパネルの電力を供給する必要があります。 両方の GPU で同時にパネル電源を提供しても問題ありません。
2. 切り替え時の両方の GPU からの明るさ対応の制御信号。
3. 切り替え時の両方の GPU からの明るさレベル (パルス幅変調)。

マルチプレクサは、2つのGPUとパネルの間で次の情報を切り替えます。

1. 明るさ対応の制御信号
2. 明るさレベル (パルス幅変調)
3. DisplayPort (DP) AUX ライン
4. ホット プラグ検出 (HPD) ライン
5. DP データ ライン

マルチプレクサーは、パネルがアクティブでないときに切り替える機能を供えている必要があります。 少なくとも、内部パネルの切り替えでは、マルチプレクサが切り替え時に GPU への HPD 信号をトリガーしないようにする必要があります。

GPU ドライバーからはマルチプレクサー ACPI メソッドを呼び出さないようにします。

自動ディスプレイ切り替え (DDI)

マルチプレクサーの要件を満たすために、いくつかの DDI が追加されています。 OS は、次の関数を使用して、多重化スイッチ中にドライバーの DDI を呼び出す 5 つの異なるポイントがあります。 さまざまな呼び出しは、切り替えの段階と、ドライバーが現在ディスプレイを制御している GPU を制御しているかどうかによって異なります。

DDI	説明
DxgkDdiDisplayMuxPreSwitchAway	ディスプレイに現在接続されているドライバーを呼び出します。 この呼び出しは、システムがディスプレイを別の GPU (GPU0 から GPU1) に切り替える予定であることをドライバーに通知します。
DxgkDdiDisplayMuxPreSwitchAwayGetPrivateData	パネルに現在接続されているドライバー (GPU0 から) からプライベート スイッチ データを収集する呼び出し。
DxgkDdiDisplayMuxPreSwitchTo	ディスプレイに現在接続されていないドライバーを呼び出します。 この呼び出しは、OS がこの GPU (GPU1) にディスプレイを切り替える予定であることをドライバーに通知します。
DxgkDdiDisplayMuxSwitchCanceled	切り替えが完了する前に切り替えシーケンスが取り消されたことを示すドライバーを呼び出します。
DxgkDdiDisplayMuxPostSwitchAway	マルチプレクサースイッチの切り替えが完了し、GPU0のドライバーはディスプレイに接続されなくなりました。
DxgkDdiDisplayMuxPostSwitchToPhase1	mux スイッチが完了し、GPU1 のドライバーがディスプレイに接続されました。 このドライバーは、フェーズ 1 のタスクを実行する必要があります。
DxgkDdiDisplayMuxPostSwitchToPhase2	mux スイッチが完了し、GPU1 のドライバーがディスプレイに接続されました。 このドライバーは、フェーズ 2 のタスクを実行する必要があります。
DxgkDdiDisplayMuxUpdateState	アダプターの起動時に呼び出され、電源状態を D0 に戻して、現在のマルチプレクサーの状態をドライバーに通知します。

ドライバーが各ステージで完了する必要がある明示的なアクションがあります。 これらのアクションは、この記事の後半で説明します。

ADS 関連の DDI 更新に関する完全な一覧については、「WDDM DDI の変更および自動表示切り替え」を参照してください。

GPU0 と GPU1 間でデータを共有する

より優れたユーザー エクスペリエンスを構築できる場合があります。

• GPU0 と GPU1 は同じ IHV から取得されます。
• GPU0 は、OS に不透明なディスプレイ構成に関する情報を GPU1 に渡すことができます。

データ BLOB は、GPU1 のドライバーがデータ BLOB を理解しているかどうかを迅速に識別できる GUID によって記述されます。 大まかに言えば、OS は GPU0 を呼び出して、スイッチ前に blob GUID とデータを取得し、それをディスプレイの HPD に要求される前に GPU1 に渡します。

GPU1 のドライバーは次のことを担当します。

• BLOB の GUID を理解しているか確認します。
• BLOB 内の形式に誤りがあるデータによる有害な影響を回避するために、BLOB 内のデータの各要素を検証します。

ドライバーの相互運用性

WDDM ドライバーが ADS をサポートしている場合は、実行されている OEM システムやシステム上の他の GPU に関係なく ADS をサポートする必要があります。

切り替えシーケンス

技術的には、その GPU のドライバーが停止したときに GPU から切り替えることができますが、このシナリオは現在サポートされていません。 したがって、切り替えは、両方の GPU に、切り替える DDI をサポートするドライバーが読み込まれている場合にのみ実行されます。

次の順番は、パネルがアクティブな場合の切り替えシーケンス全体の概要です。ここでは、GPU0 と GPU1 はそれぞれ iGPU と dGPU として表示されています。 現在、GPU0 がマルチプレクサーを介して内部パネルに接続されていますが、GPU1 に切り替えてパネルにスキャン アウトしたいと考えています。

1. 切り替え呼び出しは API レベルで行われます。
2. OS は、現在の内部パネル状態 (HDR、モード、リフレッシュ レートなど) の属性を収集し、一時的なディスプレイ モードを確認します。
3. OS では、システム内の任意の GPU からの HPD が原因で、表示トポロジの実行が無効になります。
4. OS は GPU1 ドライバーの DxgkDdiDisplayMuxPreSwitchTo を呼び出し、現在の明るさレベルを渡します。 ドライバーは、蓋が開いている場合にのみ、次の操作を行う必要があります。
   • パネルの電源を入れる。
   • 輝度を有効にする信号を設定します。
   • OS が渡した明るさレベルを設定する。
5. マルチプレクサーが切り替えるまで、カバーのホット プラグ検出による切り替えが処理されないようにするために、OS は GPU0 での DxgkDdiQueryConnectionChange の呼び出しを無効にします。
6. OS は GPU0 ドライバーの DxgkDdiDisplayMuxPreSwitchAway DDI を呼び出します。 ドライバーは次の手順を実行する必要があります:
   • 蓋がアクティブな場合は、パネルで PSR1 (パネルの自己更新 1) を有効にし、この順番で、OS が後で無効化を要求するまで無効になっていないことを確認します。
   • 接続変更リストにパケットを追加します。このとき、DXGK_CONNECTION_CHANGE の ConnectionStatus を MonitorStatusDisconnected に、MonitorConnect.MonitorConnectFlags.DisplayMuxConnectionChange を 1 に設定します。
   • GPU0 では、リッド ターゲットの接続変更パケットをキューに追加できません。 そうすると、OS がバグ チェックを実行します。
   • プライベート ADS データ BLOB (GUID とデータ) のサイズを OS に返します。 GPU0 ドライバーがこの呼び出しに失敗した場合は、キューに配置された ADS 接続状態パケットが、戻る前に削除されていることを確認する必要があります。
7. GPU0 のドライバーから 0 以外のプライベート データ サイズが返された場合、OS はそのサイズを割り当てて GPU0 の DxgkDdiDisplayMuxPreSwitchAwayGetPrivateData コールバックに渡してプライベート スイッチ データを取得します。
8. OS は、GPU0 から GPU1 に切り替えるために、マルチプレクサの ACPI メソッドを呼び出します。
9. OS により、GPU0 の DxgkDdiQueryConnectionChange が再度呼び出されます。
10. OS は GPU0 の DxgkDdiQueryConnectionChanges を呼び出して、DisplayMuxConnectionChange が 1 に設定された MonitorStatusDisconnected 接続パケットを処理します。
11. OS は GPU0 の DxgkddiSettimingsfromvidpn を呼び出して、切り替え元となるディスプレイのパスを無効にします。 GPU0 のドライバーは次の手順を実行する必要があります。
    • パネルの電源をオフにする。
    • 明るさ信号を無効にする。
    • 明るさレベルをマルチプレクサへの送信を停止します。
12. OS はディスプレイの発信を処理します。 不要なトポロジの変更を回避するために、トポロジの変更はトリガーされません。
13. OS は GPU1 の DxgkDdiDisplayMuxPostSwitchToPhase1 コールバックを呼び出し、GPU0 から取得した ADS プライベート BLOB を渡します。 ドライバーは次の手順を実行する必要があります:
    • 蓋の開閉状態を確認します。
    • DXGK_CONNECTION_CHANGE の接続変更リストにパケットを追加します。
      • MonitorConnect.MonitorConnectFlags.DisplayMuxConnectionChange ビットが設定されます。
      • ConnectionStatus は、蓋が開いている場合に MonitorStatusConnected に設定され、蓋が閉じている場合は MonitorStatusDisconnected に設定されます。
    • 蓋が閉じている場合は、電源をオフにし、そしてパネルの明るさを有効にする信号をオフにします。
14. GPU1 の内部ターゲットとして DXGKQAITYPE_INTEGRATED_DISPLAY_DESCRIPTOR2 が指定された DxgkDdiQueryAdapterInfo の呼び出しを OS がまだ実行していない場合に、これを実行します。 この呼び出しの結果、OS は DxgkDdiQueryDeviceDescriptor も呼び出します。
15. OS は GPU1 の DxgkDdiQueryConnectionChange を呼び出して、接続変更リストのイベントを処理します。 この呼び出しの結果として、ホット プラグ検出で認識された新しいモニターに対して DxgkDdiQueryDeviceDescriptor が呼び出されます。
16. OS では、HPD による表示トポロジの変更が有効になります。
17. OS は、DisplayMuxConnectionChange が 1 に設定されている状態で、GPU0 と GPU1 からの接続パケットを非同期的に処理します。
18. GPU1 が MonitorStatusConnected にキューされている場合:
    • OS は GPU1 の DWM 関数を呼び出してモードを列挙します。
    • DxgkddiSettimingsfromvidpn は、ディスプレイ パスを有効にするために、GPU1 で呼び出されます。
    • DWM は GPU1 上のディスプレイ パスにフレームをレンダリングして表示します。
    • OS は、最初のフレームが表示されるまで待機します。
19. OS は GPU1 の DxgkDdiDisplayMuxPostSwitchToPhase2 コールバックを呼び出します。このコールバックでは、MonitorStatusConnected が GPU1 によってキューに登録されている場合、ドライバーはディスプレイの PSR1 をオフにする必要があります。それ以外の場合は、何も行う必要はありません。
20. OS は GPU0 の DxgkDdiDisplayMuxPreSwitchAway を呼び出します。 ドライバーから予期されるアクションはありませんが、この呼び出しは、切り替えに関連するドライバーのクリーンアップまたはブックキーピングに役立ちます。
21. OS は、現在の内部パネル状態の属性を収集します。 パネルの状態が以前に保存されたものと異なる場合、OS によってテレメトリがトリガーされます。

この切り替えシーケンスは、GPU->dGPU と dGPU->iGPU と同じです。 パネルが非アクティブの場合、マルチプレクサーが切り替えられることがあります。 その場合、このシーケンスは必要なく、OS はマルチプレクサに対して ACPI メソッドを呼び出して切り替えることができます。

ほとんどの OS では、ドライバーが PSR モードであることを認識していません。 その結果、ドライバーは依然として Vsync の同期を生成し、フリップを完了したと報告する必要があります。それにもかかわらず、これらの動作はユーザーには表示されません。

復旧プロセス

切り替えシーケンスのいずれかの段階でエラーが発生した場合は、次のクリーンアップが実行されます。

1. GPU0 の DxgkDdiDisplayMuxPreSwitchAway が正常に呼び出されたが DxgkDdiDisplayMuxPostSwitchAway は呼び出されていない場合、OS が GPU0 の DxgkDdiDisplayMuxSwitchCanceled を呼び出します。
2. GPU1 の DxgkDdiDisplayMuxPreSwitchTo が正常に呼び出されたが DxgkDdiDisplayMuxPostSwitchToPhase2 は呼び出されていない場合、OS が GPU1 の DxgkDdiDisplayMuxSwitchCanceled を呼び出します。
3. OS が無効になっている場合は、表示トポロジの変更を再度有効にします。
4. 無効になっている場合、OS は GPU0 で DxgkDdiQueryConnectionChange の呼び出しを再度有効にします。
5. OS は、カバーが接続されている GPU でカバーの接続状態をポーリングします。
6. OS によって、set display configuration (SDC) Reset がトリガーされます。 マルチプレクサーを介してパネルが接続されている (DxgkDdiDisplayMuxSwitchCanceled から返されます) ドライバーは、PSR が無効になっていることを確認する必要があります。

切り替え中に発生する可能性がある異常なイベント

• 外部ユーザーによるモニターの接続または取り外し

  切り替えシーケンスの一部として、OS の HPD イベントの処理を無効にします。 このようにして、カバーの接続と共にホット プラグ検出があれば、1 つのアトミック操作でキューに登録されて処理されます。

• 切り替え中に別のアプリが SDC を呼び出す

  切り替え中、SDC への呼び出しはブロックされ、切り替え処理後に実行されます。

• 切り替え中にドライバーが無効になる

  ドライバーが停止すると、切り替えシーケンスの呼び出しは失敗し、回復順がアクティブになります。 PnPStop セクション では、画面が常に表示されるようにする方法についても詳しく説明します。

カバーを閉じるシナリオ

ドライバーは一般に、次のいずれかの方法を使用して、蓋の開閉イベントを検出できます。

• カバーの状態を、DxgkDdiNotifyAcpiEvent (DxgkPowerStateEvent、 PO_CB_LID_SWITCH_STATE) から追跡します
• カバーの状態を、PoRegisterPowerSettingCallback (GUID_LIDSWITCH_STATE_CHANGE) コールバックから追跡します。
• プラットフォームに依存する別の方法。

ただし、WDDM の場合は通常、ドライバーでは DxgkDdiNotifyAcpiEvent による方法を使用する必要があります。この場合は Dxgkrnl 状態が許容され、ドライバーの状態が同期されるためです。切り替えシーケンスで iGPU と dGPU の両方を GPU1 にできるため、カバーが切り替えによって切断されるときに、すべての ADS ドライバーでカバーの状態を追跡できます。

OS が GPU0 からの DisplayMuxConnectionChange イベントを処理すると、GPU0 は蓋の状態を所有しなくなったと見なされるため、蓋が切り替わるまで GPU0 はそのターゲットの接続状態パケットをそれ以上報告できません。 GPU0 が報告する場合、OS はバグ チェックを行います。 OS が GPU1 から DisplayMuxConnectionChange を処理すると、GPU1 が蓋状態の所有者であると見なされます。 GPU1 は蓋の状態を認識し、適切な DisplayMuxConnectionChange パケットを報告することが期待されるため、これら 2 つのイベントの間では開閉イベントはすべて無視できます。

ドライバーがパネルを所有していると OS が判断した場合

次の表では、OS がパネルを所有する GPU と見なす順番について説明します。 所有 GPU は、切り替えシーケンスを使用して接続の変更を報告できます。 ステップ番号は、前述の切り替えシーケンスの番号です。

ステージング元	ステージング先	の GPU がパネル を制御します。
切り替え前	手順 5.	GPU0
手順 6.	手順 12	GPU なし
手順 13	切り替え後	GPU1

OS バグは、GPU がパネルを制御していない場合に、ドライバーのキューに多重化ターゲットの接続変更パケットが表示されるかどうかを確認します。

パネルのセルフ リフレッシュ (PSR) の制御

ADS 機能は、移行中の障害を回避するために PSR を使用します。 具体的には、PSR1 (全画面表示の更新モード) が使用されるため、GPU0 と GPU1 で使用する PSR モードをネゴシエートする必要はありません。

PSR1 内でも、パネルでサポートする必要があるオプションの機能があります。

シンク機能	詳細	シンク公開経路
DPCD & eDP バージョン	eDP v1.3 以上を公開します。	DPCD
PSR の機能とバージョン	シンクはバージョン 1 をサポートする必要があります。	DPCD 00070h ビット 7:0
PSR 状態を伝達するための VSC SDP をサポートする	PSR の場合のみ。シンクは、PSR 状態と CRC 値を伝達するために、最大 8 の有効なバイトのリビジョン 2 をサポートする必要があります。	DPCD 170
シンクは、PSR 関連の状態を適切に報告する必要があります	シンクは状態を公開する必要があります。たとえば、リンク CRC エラー、RFB ストレージ エラー、シンク デバイスの自己更新状態、最大再同期フレーム数、シンクでの最後の実際の同期待機時間、最後に受信した PSR SDP などです。	DPCD 2008h、2009h、200Ah はシンクの正しい状態を反映しなければなりません。

GPU1 が OS からの DxgkddiSettimingsfromvidpn 呼び出しの一部としてリンク トレーニングを実行する場合、ドライバーは GPU0 が使用する DP レーンと帯域幅の設定を認識しないため、高速リンク トレーニングではなくフル リンク トレーニング シーケンスを実行する必要があります。 OS は GPU 間で PSR ポリシーをネゴシエートしないため、パネルでは、GPU が使用するすべての PSR バージョンと機能をサポートする必要があります。 たとえば、パネルでは、GPU0 が PSR2 を一部のセット機能と共に使用し、PSR1 が切り替えに使用され、GPU1 が異なる機能セットで PSR2 を使用するシナリオをサポートする必要があります。

スイッチ中にパネルが確実に PSR に留まるようにする

GPU1 がパネルにモードを設定する際、パネルが PSR モードの間に GPU1 が設定したリンク属性が PSR エントリモードと一致する保証はありません。 たとえば、リフレッシュ レートやアクティブ サイズが変更される場合があります。 現在、DP やその他の業界標準には、リンク属性が変更されている間にパネルを PSR に保持できることをパネルが報告する方法がありません。 長期的には、この機能を DP 仕様に追加できるように取り組みたいと考えています。 ADS に対応したシステムの場合、OEM はそれまでの間に、EDID で公開されている任意の組み合わせの間でリンク属性 (例: リフレッシュ レート、アクティブ サイズ) が変化する間、PSR を維持できる TCon、パネル、マルチプレクサーの組み合わせを選択する必要があります。 この方法により、切り替え中に PSR をアクティブに保つことができます。

ADS HLK テストで、切り替え処理中に PSR が維持されていることを確認するために、GPU1 でモードをテストした後に PSR がアクティブでなかったかどうかを OS が認識できるようにしたいと考えています。 課題は、リンク トレーニング全体で PSR をサポートできない場合にパネルがどのように反応するかが定義されていないことです。

DxgkDdiDisplayMuxPostSwitchToPhase2の一部として、ドライバーは pWasPanelInPSR において、パネルが PSR になかったことを検出したかどうかを示すブール値を返し、それを OS に通知します。

内部パネルの EDID

異なるモニターが接続されているディスプレイ モードとトポロジを選択するときに OS が予期される動作を実行するには、両方の GPU が内部ディスプレイの EDID/DisplayId を報告する必要があります。 この要件により、ディスプレイ モードとトポロジを格納する CCD データベースは、どの GPU が内部ディスプレイを制御しているかに関係なく、同じ設定を選択できます。

ドライバーが OS に報告する EDID は、変更なしで aux コマンドを使用するパネルから照会される EDID である必要があります。

現在、OS は、内部パネルを報告するドライバーを起動するときに DxgkDdiQueryAdapterInfo (DXGKQAITYPE_INTEGRATED_DISPLAY_DESCRIPTOR2) を呼び出します。 統合されたターゲットからマルチプレクサーが切り離されると、ドライバーはパネルと通信して必要な情報を収集することができなくなります。 解決策は、ドライバーが起動され、mux が内部ターゲットから切り替わると、mux が最初に内部ターゲットに切り替わるようになるまで、OS は DxgkDdiQueryAdapterInfo(DXGKQAITYPE_INTEGRATED_DISPLAY_DESCRIPTOR2) の呼び出しを遅らせるということです。

システムで ADS 機能が有効になっていて、切り替えが許可されているかどうかを OS が判断する方法

OS は、次のチェックの一覧を実行して、ADS がシステムで使用可能かどうかを判断します。 ADS をサポートするには、すべてのチェックが True である必要があります。

1. 統合ハイブリッド (DXGK_DRIVERCAPS.HybridIntegrated) としてマークされている GPU があります。これは以下のことを実行します。
   • そのドライバーは、DXGK_DISPLAYMUX_INTERFACE インターフェイスを実装します。
   • DxgkDdiDisplayMuxGetDriverSupportLevel から返される ADS サポート レベルを確認します。
   • DxgkDdiDisplayMuxGetRuntimeStatus からのランタイム ADS ステータスを確認します。
   • ドライバーは、次の DDI をサポートする必要があります。
     • DxgkddiSettimingsfromvidpn
     • DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3
     • DxgkDdiDisplayDetectControl
     • DxgkDdiQueryConnectionChange
     • DxgkDdiNotifyAcpiEvent
   • DXGK_CHILD_CAPABILITIES.HpdAwareness を HpdAwarenessInterruptible に、DXGK_CHILD_DESCRIPTOR.ChildDeviceType を TypeIntegratedDisplay に設定して、内部モニターのターゲットを公開します。
   • 内部モニターの ACPI 名前空間の下には、マルチプレクサの ACPI 名を正常に返す DMID メソッドがあります。
   • GPU ACPI デバイスには、依存関係として正しい多重化 ACPI 名を返す '_DEP' ACPI メソッドがあります。
2. ディスクリート ハイブリッド (DXGK_DRIVERCAPS.HybridDiscrete) としてマークされたGPUがあります。
   • そのドライバーは、DXGK_DISPLAYMUX_INTERFACE インターフェイスを実装します。
   • DxgkDdiDisplayMuxGetDriverSupportLevel から返される ADS サポート レベルを確認します。
   • ドライバーは、次の DDI をサポートする必要があります。
     • DxgkddiSettimingsfromvidpn
     • DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3
     • DxgkDdiDisplayDetectControl
     • DxgkDdiQueryConnectionChange
     • DxgkDdiNotifyAcpiEvent
   • DXGK_CHILD_CAPABILITIES.HpdAwareness を HpdAwarenessInterruptible に、DXGK_CHILD_DESCRIPTOR.ChildDeviceType を TypeIntegratedDisplay に設定して、内部モニターのターゲットを公開します。
   • 内部モニターの ACPI 名前空間の下には、マルチプレクサの ACPI 名を正常に返す DMID メソッドがあります。
   • GPU ACPI デバイスには、依存関係として正しい多重化 ACPI 名を返す '_DEP' ACPI メソッドがあります。
3. 手順 1 と 2 で ACPI DMID メソッドによって返されるマルチプレクサーの ACPI 名が一致します。
4. ACPI 多重化デバイスには、ACPI DMQU、DMCF、DMSL メソッドがあります。
5. マルチプレクサー ACPI DMQU メソッドは、いずれかの GPU からの内部パネル ターゲットの ACPI 名を返します。
6. ADS は現在、1 つの内部パネルを持つシステムのみをサポートしています。
7. 次のいずれかとなります。
   1. GPU0、GPU1、Mux ACPI はすべて、完全な ADS サポートを報告します。
   2. GPU0、GPU1、Mux ACPI はすべて、試験的または完全な ADS サポートを報告し、EnableMDMExperimentalFeature レジストリ キーが設定されています。

条件 1 と 2 は、マルチプレクサーを切り替えるために両方のアダプターが起動される必要があることを意味します。

ADS 機能ロールアウトの品質を制御する

ADS が優れたユーザー エクスペリエンスを提供するには、次のすべてのコンポーネントが完璧に連携されている必要があります。

1. OS のディスプレイ マルチプレクサー機能。
2. MUX切り替え用のプラットフォームACPIメソッド。
3. iGPU ドライバーと dGPU ドライバーのディスプレイ マルチプレクサー スイッチング機能。

IHV/OEM がリリースで非シップ品質コードを使用できるように、次のいずれかのレベルの ADS サポートを公開できます。

• サポートなし: ドライバーは ADS 機能をサポートしていません。
• 開発サポート: ドライバーは ADS をサポートしていますが、ドライバーの実装はまだ開発中であるため、この目的以外の使用は控えてください。
• 試験的なサポート: このドライバーは ADS をサポートしていますが、まだ出荷品質ではありません。 OS は既定では ADS を有効にしませんが、有効にするように構成できます。
• 完全なサポート: ドライバーは、製品レベルでADSをサポートしています。 OS では、ドライバーが ADS をサポートしていると見なされます。

ディスプレイの切り替え後に同じままにする必要があるディスプレイ属性

ディスプレイ切り替えは、次のディスプレイ属性を変更するべきではありません。

1. デスクトップの解像度
2. VidPn パス (VidPn ソース モード、ターゲット モード、スケーリングなどを含む)
3. DPI
4. 夜間照明の設定
5. Gamma
6. ディスプレイ トポロジー
7. HDR のオン/オフ
8. SDR ホワイト レベル
9. カラー プロファイル
10. モニターの OPM ターゲット・タイプ
11. ディスプレイの輝度

シームレスな切り替え体験を実現する GPU キャップの照合

ユーザーにシームレスな切り替え体験を提供するには、切り替え後に、切り替え前と同じディスプレイを構成する必要があります。 この動作を実現するために、両方の GPU で同じサポートが必要な特定の GPU 機能があります。 たとえば、1 つの GPU が HDR をサポートしていて、もう一方が HDR をサポートしていない場合、1 つの GPU で HDR が有効になっている間の切り替えはシームレスになりません。

次の表に、GPU のディスプレイ機能と特性を示し、2 つの GPU 間の配置要件について説明します。

機能	シームレスなサポートを用意する必要がある GPU
HDR	パネルが HDR をサポートしている場合、両方の GPU で fp16 HDR をサポートするか、HDR をサポートしないかのいずれかである必要があります。
ハードウェア カーソル	いいえ。 OS は、ユーザーに目に見える中断なしに、さまざまなカーソル機能に適応します。
MPO	いいえ。 OS は、ユーザーに目に見える中断なしに、さまざまな MPO 機能に適応します。
PSR	どちらの GPU でもこの機能をサポートする必要があります。
EDID/DisplayID	どちらの GPU も同じ EDID/DisplayId を公開する必要があります。
明るさの上限	どちらの GPU も、同じ明るさインターフェイスと明るさキャップをサポートする必要があります。
Brightness Level (明るさのレベル)	どちらの GPU も、同じ明るさレベルと間隔を公開する必要があります。
解像度	どちらの GPU も、同じソース モードとターゲット解決をサポートする必要があります。
リフレッシュ レート	GPU0がパネルをで駆動しているリフレッシュレートをGPU1がサポートしていない場合については、の問題を参照してください。
動的リフレッシュ レート	いいえ。 OS は、さまざまな仮想リフレッシュ レートのサポートに適応します。
可変リフレッシュ レート	GPU0がパネルをで駆動しているリフレッシュレートをGPU1がサポートしていない場合については、の問題を参照してください。

GPU0 でパネルに使用されるリフレッシュ レートを GPU1 がサポートしていない場合の問題

GPU1 が GPU0 と同じモードをサポートしていない場合、縮小モードは表示トポロジ データベースに格納される場合があります。 その後、システムが GPU0 に切り替わると、縮小モードが設定されます。 たとえば、GPU0 が 120Hz をサポートし、GPU1 でサポートされるのは 60Hz のみの場合、次のシーケンスが発生する可能性があります。

1. GPU0 がディスプレイを制御し、モードが 120Hz になるようにシステムを構成します。
2. ユーザーは手動で GPU1 に切り替えます。
3. 表示トポロジ データベースにはディスプレイ用に 120Hz が格納されていますが、GPU1 ではサポートされていないため、OS は 60Hz を選択します。
4. 60Hz が設定され、表示トポロジ データベースに格納されます。
5. ユーザーは手動で GPU0 に切り替えます。
6. 表示トポロジ データベースは、データベースから 60Hz を読み取ります。

最適なエクスペリエンスを提供するために、OEM は、内部パネルの最大リフレッシュ レートをサポートする iGPU と dGPU を選択する必要があります。 それが不可能で、1 つの GPU がパネルの最大リフレッシュ レートをサポートできない場合、パネルのリフレッシュ レートをサポートする GPU は、次のような範囲の Windows 動的リフレッシュ レート (DRR) 機能をサポートする必要があります。

• 他の GPU の最も高いリフレッシュ レート。
• 内部パネルの最も高いリフレッシュ レート。

たとえば、パネルが 300Hz をサポートでき、iGPU が 60Hz のみをサポートできる場合、dGPU は少なくとも 60Hz から 300Hz の範囲の VRR をサポートする必要があります。

要約すると、リフレッシュ レートの ADS 要件は次のいずれかです。

1. iGPU と dGPU では、内部パネルの最大リフレッシュ レートがサポートされます。
2. 内部パネルの最大リフレッシュ レートをサポートする GPU は、他の GPU がサポートできる最大リフレッシュ レートから内部パネルの最大リフレッシュ レートまでの範囲で DRR をサポートする必要があります。

HDR と Dolby Vision

スイッチの後、GPU1 の内部パネルに、スイッチの前に GPU0 の内部パネルに設定されていたのと同じ HDR/Dolby ビジョン状態を OS が設定します。 ユーザーは変更に気付くべきではありません。

常夜灯

夜間照明は、WDDM ガンマまたはカラー マトリックス DDI を使用して実装されます。 どちらの場合も、OS は切り替え後に GPU1 を経由で夜間照明レベルを設定します。これは、切り替え前の GPU0 の場合と同じです。

カラー プロファイル

OS は、切り替え前に適用されたのと同じカラー プロファイルを切り替え後のパネルに適用します。

バグ チェック画面を表示する

現在、OS では、POST 以外のデバイスでのバグ チェック画面を表示することがサポートされています。 OS でバグ チェックが発生した場合:

• マルチプレクサーを切り替えません。
• 現在の OS サポートを使用すると、バグ チェック画面が表示されます。

潜在的なターゲットを評価し、バグチェックを表示するとき、OS は、別のターゲットに切り替えられたマルチプレクサに接続されているすべてのターゲットをスキップします。

GPU0 から離れた HPD が処理された時と、GPU1 からの HPD がまだ完全に処理されていない時の間には多少の時間差があります。 この期間中にバグ チェックが発生した場合、ユーザーにはバグ チェックは表示されません。 PSR がまだ有効な期間にバグ チェックが発生した場合、OS が DxgkDdiSystemDisplayEnableを呼び出すとき、ディスプレイを制御するドライバーは、パネルが PSR モードでないことを確認する必要があります。

コンテンツに応じた自動調整輝度アルゴリズム

理想では、両方の GPU で使用されるコンテンツ アダプティブ アルゴリズムが同じ効果を出す必要があります。 ただし、同じ効果が得られない場合が多く、内部パネルが切り替わると、ユーザーが違いに気付く場合があります。

明るさデータ

切り替えによって、ユーザーが明るさの変更に気づかないようにするには、GPU0 と GPU1 によって公開されるすべての明るさ属性を同じにする必要があります。 この要件により、GPU0 の切り替え前の明るさレベルが、切り替え後の GPU1 でサポートされるようになります。

そのためには、GPU0 と GPU1 のドライバーで次の操作を行う必要があります。

1. バージョン 3 が強く推奨される DXGK_BRIGHTNESS_INTERFACE_2 または DXGK_BRIGHTNESS_INTERFACE_3 のいずれかの同じ明るさインターフェイスを使用します。
2. 明るさ v3 インターフェイスでは、両方のドライバーがニトベースの明るさまたは調整されていない明るさに対応している必要があります。
3. brightness v2 インターフェイスの場合、どちらのドライバーも GetPossibleBrightness からまったく同じ明るさレベルを返す必要があります。
4. brightness v3 インターフェイスの場合、どちらのドライバーも、がまったく同じ範囲を返す必要があります。つまり、各ドライバーは、GetNitRanges から、同一の DXGK_BRIGHTNESS_GET_NIT_RANGES_OUT 構造体を返す必要があります。
5. ドライバーが OS 指定の明るさレベルをパネル固有の設定に変換するために使用する内部テーブルは同じである必要があります。

ほとんどのノート パソコンでは、GPU ドライバーは、プラットフォームからこの明るさレベルのデータの一部またはすべてを非標準の方法で取得します。 これらの要件を満たすには、このプラットフォームから GPU へのデータ交換を拡張する必要がある可能性があります。

明るさインターフェイスはアダプターの起動時に照会されますが、内部パネルが HPD になるまで、OS は明るさインターフェイスの DDI を呼び出しません。 ホット プラグ検出はマルチプレクサーが GPU に切り替わった後に発生するため、ドライバーはその時点で内部パネルの EDID にアクセスできます。

ドライバーが PWM をサポートしていないパネルのパネルの明るさを設定するための IHV 固有の方法があることを理解しています。 ただし、この方法では、マルチプレクサ経由で接続されている GPU に応じて、異なる IHV 固有の方法で明るさを取得するサポートが必要になる可能性があるため、TCon の複雑さが増します。

マルチプレクサーのブート構成

システム ファームウェアは、システムの起動時に内部パネルに接続されている GPU を制御します。 OS には、パネルを制御する最後の GPU が格納されます。 その後、ブート シーケンス中に、OS は必要に応じてmuxを切り替え、適切なGPUがパネルを制御するようにします。

多重化切り替えが必要な場合にブート イメージを保持するには、次の場合にのみ切り替えが実行されます。

• 両方の GPU の電源がオンになっている。
• OS は、出力を制御するブート グラフィックスから、出力を制御する DWM/シェルに移行しました。

したがって、内部パネルを制御するGPUのDxgkddiSettimingsfromvidpn呼び出しの後に、切り替えが発生し、スイッチ中にパネルがPSR状態にある間、ユーザーは画面がフリーズすることを経験します。

ドライバーにマルチプレックス情報を提供する

この機能は、ドライバーがいつでも呼び出すことができるコールバックを提供するのではなく、OS がドライバーを呼び出して情報を提供するように意図的に設計されています。 このメソッドは、切り替えシーケンス中に OS の状態を照会する場合に、ドライバーが混乱しないようにします。

次の場合、OS はドライバーの DxgkDdiDisplayMuxUpdateState DDI を呼び出して、ドライバーに対して現在のマルチプレクサ状態を提供します。

1. ドライバーの起動時。これにより、パネルが接続されていない場合にドライバーはタイムリーなポーリング シーケンスを回避できます。
2. Dxから D0 に戻る際に。 一部の電源状態 (休止状態など) から復帰する場合、ファームウェアで多重化をリセットする必要がある場合があります。そのため、ドライバーは状態を認識しません。

このような場合、切り替えシーケンスに関係する通常の DDI と併せて、GPU がアクティブなときは常にマルチプレクサーの切り替え方向をドライバーが判別できるようになります。

この機能の最初のバージョンでは、内部パネルがアクティブでないときにマルチプレクサを切り替える予定はないため、すべてのスイッチは同じシーケンスをたどります。

アダプターの開始時刻

ドライバーが起動すると、OS からのポーリング要求に応答する必要があります。 ドライバーが通信を試みることでマルチプレクサーが切り替えわるかどうかの検出を試みることは可能でしたが、時間がかかるか、信頼性が低い可能性がありました。 GPU 開始シーケンスの一部として、OS は、マルチプレクサーに接続されている各ターゲットに対して DxgkDdiDisplayMuxUpdateState DDI を呼び出して、そのターゲットに切り替えられていることを示します。

ドライバーが起動すると、OS からのポーリング要求に応答する必要があります。 ドライバーは、OS と通信して、多重化装置 (MUX) が自分のGPUに切り替わっているかどうかを確認しようとすることができますが、それには時間がかかるか、信頼性が低い可能性があります。

その代わりに、GPU の起動シーケンスの一部として、マルチプレクサーに接続されている各ターゲットに対して OS が DxgkDdiDisplayMuxUpdateState を呼び出し、マルチプレクサーがそのターゲットに切り替わるかどうかを示します。 OS は、ポーリング DDI を呼び出す前に、MUX がドライバーの GPU に切り替えられているかどうかをドライバーに報告します。

ADS ドライバーは、内部パネルを OS に報告し続けます。これは、OS が内部パネルの詳細を照会するために、DxgkDdiQueryAdapterInfo（DXGKQAITYPE_INTEGRATED_DISPLAY_DESCRIPTOR2）を呼び出すことで行います。 ドライバーは、マルチプレクサーに接続されているすべてのターゲットで DXGK_CHILD_CAPABILITIES.HpdAwareness が HpdAwarenessInterruptible に設定されていることを確認する必要があります。

D0 遷移

接続されたマルチプレクサを備えた GPU が低電力状態から電源オン状態に戻されるたびに、OS は DxgkDdiDisplayMuxUpdateState を呼び出して、マルチプレクサがターゲットに接続されているか、またはもう一方の GPU に切り替えられているかをドライバーに通知します。

ブート シーケンス

次のブート シーケンスでは、ADS 固有の側面が強調表示されています。 このシーケンスでは、システムは次の状態で起動します。

• マルチプレクサーに接続されている iGPU。
• 再起動前のユーザーの最後の構成は、マルチプレクサが dGPU に接続されていることでした。

ブート シーケンスは本質的に非同期であるため、このシーケンスは例を提示する目的のみに使用します。

1. システムの電源がオンになり、iGPU はマルチプレクサーを介してパネルに接続されます。
2. iGPU はパネルにブート画面を表示します。
3. 3Windows は、ブート アニメーションを読み込んで内蓋に表示します。
4. iGPU と dGPU の両方における _DEP のため、OSのマルチプレクサードライバーがどちらのGPUドライバーよりも先に起動されます。 多重化ドライバーは、ACPI 呼び出しを使用して、多重化が正しく構成されていることを確認します。 多重化ドライバーは、ACPI 多重化実装が ADS 要件を満たしていることを確認します。
5. Dxgkrnl は iGPU に対して DxgkDdiAddDevice を呼び出します。
6. Dxgkrnl は iGPU に対して DxgkDdiQueryInterface (DXGK_DISPLAYMUX_INTERFACE) を呼び出します。 現在のシステムが ADS をサポートしていない場合でも、ADS をサポートしている場合、ドライバーはそのインターフェイスを返します。
7. Dxgkrnl は、DxgkDdiDisplayMuxGetDriverSupportLevel を呼び出して、ドライバーの ADS サポート レベルを取得します。
8. Dxgkrnl は、機能している ADS マルチプレクサーがシステムに存在することを iGPU に知らせるために DxgkDdiDisplayMuxReportPresence (TRUE) を呼び出します。
9. Dxgkrnl は の DxgkDdiStartDevice を呼び出します。 iGPU ドライバーは、内部パネルの VidPn ターゲットを含む子の数を返します。
10. Dxgkrnl は、DxgkDdiDisplayMuxGetRuntimeStatus を呼び出して、iGPU が ADS をサポートしているか、ドライブが必要なすべての情報をシステムから取得しているかを確認します。
11. Dxgkrnl は、 iGPU が公開する個別の子に対して DxgkDdiQueryChildStatus を呼び出します。
12. Dxgkrnl は、マルチプレクサに接続されているとiGPUから報告された子を見つけた場合、DxgkDdiDisplayMuxUpdateState を呼び出して、そのマルチプレクサがターゲットに接続されていることをiGPUに通知します。
13. iGPU は接続された内部モニターを公開しているため、Dxgkrnl は、DxgkddiSettimingsfromvidpn を使用して iGPU のモードを設定します。
14. Dxgkrnl は、dGPU ドライブを起動し、dGPU に対して手順 5 ～ 12 を繰り返します。
15. Dxgkrnl は、iGPU、dGPU、そしてマルチプレクサがすべて正しく構成されていることを検出し、マルチプレクサのペアとそのペア用のPnPデバイスインターフェイスプロパティを作成します。
16. Dxgkrnl はレジストリから最後の多重化構成を読み取ります。 最後の構成が dGPU だったため、Dxgkrnl は、前述のマルチプレクサー切り替えシーケンスを開始してマルチプレクサーから dGPU に切り替えます。

パネル ドライバー

モニター パネル ドライバーは、EDID から生成された PnP ハードウェア ID に基づいて読み込まれます。 EDID が同じままであることを考えると、いずれかの GPU が内部パネルを制御しているときに、パネル ドライバーが読み込まれます。 どちらのドライバーも、同じ明るさの機能を公開します。 したがって、読み込みによって問題が発生することはありません。また、パネル ドライバーは、どの GPU がマルチプレクサを制御しているのかを把握する必要はありません。

マルチプレクサが制御するターゲットを特定する

OS がドライバーを起動すると、ドライバーの DxgkDdiQueryChildRelations を呼び出して、報告された子に関する情報を照会します。 ドライバーは、個々の子の DXGK_CHILD_DESCRIPTOR 構造に値を入力します。 AcpiUid メンバーは、ACPI 名前空間内のその子の _ADR メソッドによって返される値として定義されます。これにより、OS はその子の ACPI 名を検索できます。

ADS の場合、ターゲットの子 ACPI 名前空間の下にある必要がある ACPI DMID メソッドを定義します。 この DMID メソッドは、多重化デバイスの ACPI 名を返します。 これにより、OS はターゲットのマルチプレクサ ACPI 名を検索できます。

ターゲットにスキャンアウトしているアダプターを停止する PnP

OS は、内部パネルにスキャンアウトしている GPU が停止しても、マルチプレクサーを切り替えません。 次のシナリオでは、GPU が停止したときにさまざまなケースが発生します。

1. GPU0 はポストです。 内部パネルに接続され、停止します。

   この場合、Basic Display Driver (BDD) は GPU0 で現在アクティブなモードを引き継ぎ、画面の更新を続行します。

2. GPU0 はポストですが、GPU1 は内部パネルに接続されています。 GPU0 が停止しました。

   現在の OS 設計により、GPU0 で BDD が開始され、ゴースト モニターが報告され、ディスプレイ CPL に表示されます。

3. GPU1 はポストではなく、内部パネルに接続されています。 GPU1 が停止しました。

   現在の OS 設計により、BDD は GPU1 で起動されないため、ユーザーはパネルを表示できません。

4. GPU1 が、ポストではありません。 GPU0 は内部パネルに接続され、GPU1 は停止します。

   切り替えはされず、何も起こりません。 GPU0 は引き続きパネルに表示されます。

シナリオ 2 と 3 では、ユーザーにとって不適切なエクスペリエンスが作成されます。 ADS 機能は、この 2 つのケースを修正するために動作を変更します。

プラグイン/外部 GPU はサポートされていません

プラグイン GPU でこの機能のユース ケースがあるとは考えられません。

ADS は 1 つの内部パネルのみに制限されます

ADS の最初のバージョンでは、1 つの内部パネルのみがサポートされます。 ただし、この機能は、ドライバーの変更を最小限に抑えながら、外部および複数の内部ディスプレイ (OS でサポートされている場合) の多重化をサポートできるように設計されています。

現在の POST アダプター ポリシーの変更

以前、OS には POST アダプターに関するいくつかのポリシーがありました。 たとえば、POST アダプターは、内部ターゲットを公開できる唯一のアダプターでした。 このような制限は、ADS の導入により OS から削除されます。

モニターでの視覚効果を無効にする

Windows 11 でモニターが接続されている場合、シェル/DWM にはアニメーション シーケンスがあります。 このアニメーションは、ディスプレイ切り替えのシナリオでは無効になっています。

PnP bonk を無効にする

モニターが追加または削除されると、PnP システムはユーザーに通知する "bonk" サウンドを再生します。 この問題は、ディスプレイ切り替えのシナリオでは発生しません。

アプリケーション通知

ディスプレイが切り替えられると、システムは通常の HPD の削除および HPD 到着コード・パスを通過します。 すべての通常のアプリケーション通知は通常どおりトリガーされます。たとえば、HPD出力とHPD入力のPnP通知やWM_DISPLAYCHANGEウィンドウメッセージがあります。

切り替えを開始する API

この計画では、OS および IHV コントロール パネルが切り替えを開始できるように、パブリック API を用意します。

関連する API と Win + P 動作を表示する

内部パネルが 1 つの GPU にのみ接続されていることを考えると、ディスプレイ API は Win + P 機能と共に期待どおりに動作します。

HLK テスト

GPU ドライバーまたは ACPI ファームウェアが完全な ADS サポートを報告する場合は、ADS 対応システムで ADS HLK テストに合格する必要があります。

マルチプレクサーが GPU から切り替えられるときに内部パネルのホット プラグ検出を行う GPU

マルチプレクサーがドライバーから切り離されるときに、内部パネルが接続されていることがドライバーから報告されると、OS はバグ チェックを開始します。

AC/DC 変換

ADS 機能の最初のバージョンでは、OS は AC と DC の多重化設定を格納せず、AC <-> DC 遷移で多重化切り替えをトリガーしません。

システム電源の遷移

電源切り替えに関する主な懸念は、ファームウェアがマルチプレクサの状態をリセットしてしまう場合（たとえば、休止状態など）であり、その結果、電源が再開されるときに、マルチプレクサが元のパネルに切り替わっていないことです。

最初のアプローチは、iGPU と dGPU の両方の電源をオンにした後、マルチプレクサを dGPU に切り替えていました。 この方法の問題は、異なる非同期イベントによっては、結果として複数のモード変更になる可能性があるということです。

ユーザー エクスペリエンスを合理化するための更新されたアプローチは、iGPU と dGPU の両方がスリープ状態になっている間に、システムがマルチプレクサを予期されたターゲットに切り替え、複数のモード変更を回避することです。

電源切り替えシーケンス

次の例では、ADS システムでの休止状態の電力遷移について説明します。

1. システムがdGPUに接続されたマルチプレクサで構成されています。
2. システムが休止状態に入ります。
3. iGPU と dGPU の両方が D3 電力に遷移します。
4. システムの電源がオフになります。
5. ユーザーがシステムの電源をオンにします。
6. ファームウェアは、マルチプレクサーを内部パネルでの iGPU と iGPU のディスプレイ ブート シーケンスに設定します。
7. Dxgkrnl が、最後の多重化構成 (この場合は dGPU) を読み取り、ACPI (この場合は iGPU) を使用して現在の多重化位置と比較します。 Dxgkrnl は、次に、ACPI を呼び出してマルチプレクサーを dGPU に切り替えます。
8. Dxgkrnl は iGPU を D0 に遷移し、次に iGPU の DxgkDdiDisplayMuxUpdateState を呼び出して、マルチプレクサーが接続されていないことをドライバーに通知します。
9. Dxgkrnl は dGPU を D0 に遷移し、次に dGPU の DxgkDdiDisplayMuxUpdateState を呼び出して、マルチプレクサーが接続されていることをドライバーに通知します。
10. dxgkrnl は dGPU にモードを設定します。

オール イン ワン システム (AIO)

ADS をサポートする AIO システムでは、両方の GPU で内部ターゲットの種類として内部パネルが公開されている必要があります。

マルチプレクサー ACPI デバイス

OEM は、ACPI 名前空間に多重化デバイスを追加し、多重化を操作するために必要なメソッドを提供します。

多重化デバイスは ACPI ツリー内の任意の場所に配置できるため、GPU ドライバーで多重化の ACPI メソッドを呼び出さないでください。 両方のGPUにとって最も近い共通の祖先の下にマルチプレクサを設置することをお勧めします。

現在のマルチプレクサ デバイスでは 2 つの入力のみがサポートされており、今後の多重化ではそれ以上のサポートは期待されないため、設計では 2 つの入力と各マルチプレクサへの 1 つの出力を想定しています。

システムが稼働している間は、マルチプレクサー デバイスを停止することはできません。 隠しシステムデバイスです。

マルチプレクサー デバイスの ACPI メソッド

ACPI デバイスのドライバー スタックのみが、デバイスの ACPI メソッドを評価するために呼び出すことができます。 したがって、多重化デバイス メソッドを呼び出して多重化を切り替えるには、OS に多重化デバイス用のドライバーが読み込まれている必要があります。 このため、OS は、すべてのディスプレイスイッチ多重化装置に対してディスプレイ多重化ドライバーをドライバーとして提供するようになりました。

マルチプレクサデバイスには、次のメソッドが必要です。

• _HID は、ハードウェア ID によって多重化デバイスを識別します。 ACPI ディスプレイ マルチプレクサ用に 'MSFT0005' を予約しました。
• DMQU (Display Mux Query) は、マルチプレクサの現状を返します。
• DMCF（ディスプレイ・マルチプレクサ・コンフィギュア）は、マルチプレクサを設定します。

Method _HID (ハードウェア ID)

引数:

None

戻り値:

ハードウェア ID を含む ASCII 文字列。つまり。"MSFT0005"。

メソッド DMQU (Display Mux Query)

今後のリリースでは、クエリに追加情報を追加する予定です。 今後、追加のクエリを有効にするには、Arg0 を使用してクエリの種類を示します。 DMQU メソッドがクエリの種類を把握していない場合は、サポートされていないメソッドとして失敗するはずです。

引数:

Arg0: クエリの種類を指定する整数。 次の表に、クエリの種類の値とその意味を示します。

クエリの種類の値	意味
1	現在の切り替え状態を照会する
2	mux ADS サポート レベルのクエリを実行する
3	`MUX`が接続されている最初のGPU子をクエリする
4	マルチプレクサが接続されている2番目のGPU子デバイスに対してクエリを実行する

戻り値:

メソッドが指定したクエリの種類を理解している場合は、次の表に示すように、適切なデータを返す必要があります。 メソッドが指定されたクエリの種類を理解していない場合は、空の文字列を返す必要があります。

クエリの種類の値	データを返します
1	現在マルチプレクサが切り替えているGPU子デバイスのACPI名を含むASCII文字列。
2	ADS サポート レベルを表す整数。 詳細については、次の表を参照してください。
3	マルチプレクサーが接続されている最初の GPU 子デバイスの ACPI 名を格納する ASCII 文字列。
4	マルチプレクサーが接続されている 2 番目の GPU 子デバイスの ACPI 名を格納する ASCII 文字列。

次の表に、クエリの種類が 2 の場合の ADS サポート レベルの値とその意味を示します。

返されるデータ	意味
0	サポートなし
1	開発サポート。 お客様のシステムでは ADS が既定で無効にされるため、HLK テストに合格することなく、これが設定された状態でシステムを出荷できます。
2	試験的なサポート。 お客様のシステムでは ADS が既定で無効にされるため、HLK テストに合格することなく、これが設定された状態でシステムを出荷できます。
3	完全にサポートされます。 ADS は、サポートされている完全なグラフィックス ドライバーとペアリングされている場合、このシステムで既定で有効になります。 システムは、出荷するために ADS HLK テストに合格する必要があります。

メソッド DMCF (Display Mux Configure)

引数:

Arg0: マルチプレクサが切り替えるべき ACPI GPU 子デバイスの ASCII 表記の名前。

戻り値:

整数 0 は成功を意味します。0 以外は失敗を示します。 OEM は、診断を向上するために 0 以外の値を定義できます。

GPU デバイス ACPI メソッド

GPU のグラフィックス ドライバーを起動する前に、システムは多重化 ACPI デバイスが動作しているかどうかと、その現在の状態を認識する必要があります。 そのためには、ACPI マルチプレクサデバイスのドライバーが既に起動されている必要があります。 システムは、各 GPU の ACPI 名前空間の下で ACPI _DEP メソッドを使用して、デバイスの関係を保証します。

GPU に既に _DEP メソッドがある場合は、返される依存関係リストに多重化デバイスの ACPI 名を追加する必要があります。 GPU に _DEP メソッドがまだない場合は、追加する必要があります。

OS が ADS をサポートしている場合にのみ、ACPI ファームウェアがマルチプレクサに対するGPUの依存関係を宣言できるように、ACPI _OSI クエリを追加します。 ACPI ファームウェアでは、このクエリを使用して ADS のサポートを確認できます。 ADS をサポートする OS バージョンでは、_OSI(“DisplayMux”) ACPI コマンドに True を返すことでサポートが報告されます。

GPU 子デバイス ACPI メソッド

接続されたすべてのマルチプレクサ（MUX）ターゲットに対して、その子のACPIデバイスは、接続されているマルチプレクサデバイスのACPI名を返すACPIメソッドを公開します。 詳細については、「マルチプレクサが制御するターゲットを特定する」を参照してください。

メソッド DMID (Display Mux Identifier)

引数:

None

戻り値:

この出力が接続されている ACPI 多重化デバイスの ACPI 名を含む ASCII 文字列

例

次の例では、2 つの GPU (GPU0 と GPU1) と多重化を備えたシステムを ACPI フレームワーク内で設定および管理する方法を示します。

• マルチプレクサー デバイスの ACPI 名は "SB.MUX1" です。

• GPU0 場合:

  • GPU0 の ACPI 名は、'SB.PCI0.GFX0' です。
  • これは VidPn ターゲット 0x40f04 を公開します。これにより DXGK_CHILD_DESCRIPTOR.AcpiUid 値 0x400 が報告されます。
  • マルチプレクサーに接続されているターゲットに対応する ACPI 子デバイス名は "SB.PCI0.GFX0.DD1F" です。
  • ACPI メソッド _ADR は 'SB.PCI0.GFX0.DD1F' の下にあり、0x400 を返します。 この戻り値は、この ACPI デバイスが VidPn target 0x40f04 に対応することを OS が認識する方法です。
  • 'SB.PCI0.GFX0.DD1F'のACPIメソッドDMIDは「SB.MUX1」を返します。

• GPU1 場合:

  • GPU1 の ACPI 名は、'SB.PCI0.PEG0.PEGP です。
  • これは VidPn ターゲット 0x1103 を公開します。これにより DXGK_CHILD_DESCRIPTOR.AcpiUid 値 0x100 が報告されます。
  • ターゲットが接続されているマルチプレクサーに対応する ACPI 子デバイス名は 'SB.PCI0.PEG0.PEGP.EDP1' です。
  • ACPI メソッド _ADR は 'SB.PCI0.PEG0.PEGP.EDP1' の下で 0x100 を返します。 この戻り値は、この ACPI デバイスが VidPn target 0x1103 に対応することを OS が認識する方法です。
  • 'SB.PCI0.PEG0.PEGP.EDP1' の ACPI メソッド DMID は 'SB.MUX1' を返します。

• OS は、GPU0 ターゲット 0x40f04 と GPU1 ターゲット 0x1103 が、ACPI 名 'SB.MUX1' の同じマルチプレクサーに接続されていることを認識しています。

• GPU1が現在パネルに接続されている場合、OSは'DMCF'メソッドを'SB.MUX1'で呼び出し、'SB.PCI0.GFX0.DD1F'を渡すことで、MUXをGPU0に切り替えることができます。

次の ACPI コンピューター言語コードは、この例の関連部分を対象としています。 プラットフォーム ロジックの擬似コードは、<> で囲まれています。

DefinitionBlock
{
    Device (MUX1) // This is _SB_.MUX1
    {
        Name (_HID, "MSFT0007")  // _HID: Hardware ID

        Method (DMQU, 1, Serialized)  // DMQU: Display Mux Query
        {
            Switch (ToInteger(Arg0))
            {
                Case (1)
                {
                    If (<Mux is in error>)
                    {
                        Return ("")
                    }
                    If (<Mux switched to GPU0>)
                    {
                        Return ("_SB_.PCI0.GFX0.DD1F")
                    }
                    Else
                    {
                        Return ("_SB_.PCI0.PEG0.PEGP.EDP1")
                    }
                }
                Case (2) 
                {
                    Return (1)  // Mux only has developmental support
                }
                Case (3)
                {
                    If (<Mux is in error>)
                    {
                        Return ("")
                    }
                    Return ("_SB_.PCI0.GFX0.DD1F")
                }
                Case (4)
                {
                    If (<Mux is in error>)
                    {
                        Return ("")
                    }
                    Return ("_SB_.PCI0.PEG0.PEGP.EDP1")
                }

            }
            // Unknown type
            Return ("")
        }

        Method (DMCF, 1, Serialized)  // DMCF: Display Mux Configure
        {
            If (<Arg0 does not match either of the GPU children this mux is connected to>)
            {
                Return (1) // Failure, use 1 to indicate this particular failure
            }

            // Switch the mux

            If (<Mux switch was successful>)
            {
                Return (0) // Success
            }
            Else
            {
                Return (2) // Failure, use 2 to indicate this particular failure
            }
        }
    }

    Scope (_SB_.PCI0.GFX0) // ACPI Device for GPU0
    {
        Method (_DEP, 0, NotSerialized)  // _DEP: Dependency on Mux device
        {
            If (_OSI(“DisplayMux”))
            {
                Return (Package {"_SB_.MUX1"})
            }
            Else
            {
                Return (Package (0x00){})
            }
        }

        Device (DD1F) // SB.PCI0.GFX0.DD1F which is child of GPU that is connected to the Mux
        {
            Name (_ADR, 0x400)  // _ADR: Matches the AcpiUid driver reports for the target connected to mux
            Method (DMID, 0, NotSerialized)  // DMID: ACPI name of the mux this target is connected to
            {
                Return ("_SB_.MUX1")
            }
        }
    }

    Scope (_SB_.PCI0.PEG0.PEGP) // ACPI Device for GPU1
    {
        Method (_DEP, 0, NotSerialized)  // _DEP: Dependency on Mux device
        {
            If (_OSI(“DisplayMux”))
            {
                Return (Package {"_SB_.MUX1"})
            }
            Else
            {
                Return (Package (0x00){})
            }
        }

        Device (EDP1) // SB.PCI0.PEG0.PEGP.EDP1 which is child of GPU that is connected to the Mux
        {
            Name (_ADR, 0x100)  // _ADR: Matches the AcpiUid driver reports for the target connected to mux
            Method (DMID, 0, NotSerialized)  // DMID: ACPI name of the mux this target is connected to
            {
                Return ("_SB_.MUX1")
            }
        }
    }
}

API の変更

ADS 機能により、次のパブリック API 機能が追加されます。

1. システム内のマルチプレクサー デバイスを列挙します。
2. マルチプレクサーに関する情報を問い合わせます。たとえば、どのターゲットに接続されているか、現在どのターゲットに切り替えられているかなどです。
3. マルチプレクサーの切り替えをトリガーします。
4. マルチプレクサがいつ切り替えられたかを検知する方法。

システム内のマルチプレクサー デバイスを列挙する

アプリケーションは、汎用のプラグアンドプレイAPIを利用して、動作するディスプレイマルチプレクサを表すデバイスインターフェイスを見つけることができます。 ユーザー モード コンポーネントでは、Windows.Devices.Enumeration.DeviceInformation を使用できます。 これらの API で C# または C++ を使用すると、多重化デバイスを列挙できます。

// Display Mux device interface
// {93c33929-3180-46d3-8aab-008c84ad1e6e}
DEFINE_GUID(GUID_DEVINTERFACE_DISPLAYMUX, 0x93c33929, 0x3180, 0x46d3, 0x8a, 0xab, 0x00, 0x8c, 0x84, 0xad, 0x1e, 0x6e);

IDisplayMuxDevice インターフェイス

マルチプレクサー デバイスを表示するために IDisplayMuxDevice インターフェイスが追加されています。

次のコードは、Windows Runtime API を使用して、ディスプレイ多重化デバイスの列挙、状態の照会、アクティブなディスプレイ ターゲットへの切り替え、状態の変更への対応を行う方法を示しています。

#include <winrt/Windows.Foundation.h>
#include <winrt/Windows.Devices.Enumeration.h>
#include <winrt/Windows.Foundation.Collections.h>
#include <winrt/Windows.Devices.Display.Core.h>

#include <string>
#include <sstream>
#include <iomanip>
#include <windows.h>

namespace winrt
{
using namespace winrt::Windows::Foundation;
using namespace winrt::Windows::Foundation::Collections;
using namespace winrt::Windows::Devices::Enumeration;
using namespace winrt::Windows::Devices::Display;
using namespace winrt::Windows::Devices::Display::Core;
} // namespace winrt

void SwitchDisplayMuxTarget()
{
    // PnP device interface search string for Mux device interface
    std::wstring muxDeviceSelector = L"System.Devices.InterfaceClassGuid:=\"{93c33929-3180-46d3-8aab-008c84ad1e6e}\" AND System.Devices.InterfaceEnabled:=System.StructuredQueryType.Boolean#True";

    // Execute the device interface query
    winrt::DeviceInformationCollection deviceInformations = winrt::DeviceInformation::FindAllAsync(muxDeviceSelector, nullptr).get();
    if (deviceInformations.Size() == 0)
    {
        printf("No DisplayMux devices\n");
        return;
    }
    printf("%ld display mux devices found\n\n", deviceInformations.Size());

    // Only one mux in first release but here is generic code for multiple
    for (unsigned int i = 0; i < deviceInformations.Size(); i++)
    {
        printf("Display Mux device %ld :\n", i);

        // Get the device interface so we can query the info
        winrt::DeviceInformation deviceInfo = deviceInformations.GetAt(i);

        // Get the device id
        std::wstring deviceId = deviceInfo.Id().c_str();
        printf("    Device ID string : %S \n", deviceId.c_str());

        // Create the DisplayMuxDevice object
        auto displayMuxDevice = winrt::DisplayMuxDevice::FromIdAsync(deviceId).get();
        if (!displayMuxDevice)
        {
            printf("Failed to create DisplayMuxDevice object");
            continue;
        }

        // Check if DisplayMux is active
        auto displayMuxActive = displayMuxDevice.IsActive();
        printf("    DisplayMux state : %s \n", displayMuxActive ? "Active" : "Inactive");
        if (!displayMuxActive)
        {
            continue;
        }

        // Register for call back when the state of the DisplayMux changes
        UINT changeCount = 0;
        auto token = displayMuxDevice.Changed([&changeCount](auto, auto Args) -> HRESULT {
            changeCount++;
            return S_OK;
        });

        // Find targets connected to the DisplayMux and the current target
        auto targetsList = displayMuxDevice.GetAvailableMuxTargets();
        winrt::DisplayTarget currentTarget = displayMuxDevice.CurrentTarget();

        // Switch the display mux to the other target
        // NOTE SetPreferredTarget() is a sync method so use .get() to wait for the operation to complete
        printf("\n");
        if (currentTarget == targetsList.GetAt(0))
        {
            printf("DisplayMux currently connected to first target\n");
            displayMuxDevice.SetPreferredTarget(targetsList.GetAt(1)).get();
            printf("Calling SetPreferredTarget to switch DisplayMux to second target\n");
        }
        else if (currentTarget == targetsList.GetAt(1))
        {
            printf("DisplayMux currently connected to second target\n");
            displayMuxDevice.SetPreferredTarget(targetsList.GetAt(0)).get();
            printf("Calling SetPreferredTarget to switch DisplayMux to first target\n");
        }
        else
        {
            printf("Could not find current target in target list\n");
        }

        // Now read the current position
        currentTarget = displayMuxDevice.CurrentTarget();
        targetsList = displayMuxDevice.GetAvailableMuxTargets();
        if (currentTarget == targetsList.GetAt(0))
        {
            printf("DisplayMux is now currently connected to first target\n");
        }
        else if (currentTarget == targetsList.GetAt(1))
        {
            printf("DisplayMux is now currently connected to second target\n");
        }
        else
        {
            printf("Could not find current target in target list\n");
        }

        // Now unregister for change callback and display the
        displayMuxDevice.Changed(token);
        printf("DisplayMux state change callback was called %ld times\n\n", changeCount);
    }
}

自動ディスプレイ切り替えに対して WDDM DDI を変更する

このセクションでは、ADS をサポートするために WDDM DDI に加えられた追加と変更について説明します。 これらの変更は、Windows 11 バージョン 24H2 更新プログラム 2025.01D (WDDM 3.2) 以降で使用できます。

KMD の ADS サポート インターフェイスをクエリする

DXGK_DISPLAYMUX_INTERFACE_2 インターフェイス構造を追加しました。 ADS バージョン 2 をサポートするために必要な OS からドライバーへの呼び出しが含まれています。 OS は、ドライバーの起動時に、ドライバーがサポートするADSインターフェイスをクエリし、InterfaceTypeはGUID_WDDM_INTERFACE_DISPLAYMUX_2に設定されます。

(DXGK_DISPLAYMUX_INTERFACE には、ADS 機能のバージョン 1 をサポートするために必要な OS からドライバーへの呼び出しが含まれています。このバージョンは、ADS のプレリリース中に使用されました。)

ADS をサポートする KMD 関数

KMD では、ADS をサポートするために次の関数が実装されています。 Dxgkrnl は、KMD の DxgkddiQueryInterfaceを呼び出して KMD の ADS 機能インターフェイスを取得します。

ドライバーからのADS機能報告の能力

ドライバーは、OS が DxgkDdiDisplayMuxGetDriverSupportLevel DDI を呼び出すと、ADS サポートのレベルを報告します。 ドライバーが DXGK_DISPLAYMUX_INTERFACE インターフェイスを実装していない場合、OS はサポート レベルをDXGK_DISPLAYMUX_SUUPORT_LEVEL_NONE と見なします。

ドライバーは、実行されているシステムに関係なく、ADS サポート レベルを報告するはずです。 ドライバーが報告するサポート レベルは、ドライバーのみに基づく必要があります。 ドライバーは、ADS サポート レベルを報告するときに、次の条件を考慮しません。

1. システム OEM。
2. システム内の他の GPU。
3. ACPI マルチプレクサー デバイスの有無。
4. GPU の ACPI ノードにある ACPI エントリの有無。

アダプターの起動時にターゲットを報告するための更新プログラム

アダプターが起動すると、DxgkDdiQueryChildRelations DDI 経由ですべての子デバイスが報告されます。 このレポートには、マルチプレクサーに接続されている内部ターゲットが含まれます。 内部ターゲットには、DXGK_CHILD_CAPABILITIES.Type.IntegratedDisplayChild.DescriptorLength フィールドが含まれます。

アダプターの起動時にマルチプレクサが他の GPU に切り替えられた場合、問題が発生します。 この状況では、ドライバーは内部パネルと通信して EDID/DisplayId サイズをクエリできません。 このため、GUID_WDDM_INTERFACE_DISPLAYMUX_2 インターフェイスを公開するドライバーは、マルチプレクサーが現在そのドライバーの GPU に切り替えられている場合、アダプターの起動時に DXGK_CHILD_CAPABILITIES.Type.IntegratedDisplayChild.DescriptorLength をゼロに設定する必要があります。 それ以外の場合、OS はアダプターの起動に失敗します。

OS は、最初の多重化切り替え操作で内部記述子のサイズに関する内部情報を更新します。

接続変更に関する更新

前述したように、自動ディスプレイ切り替えシーケンス中に内部パネルの状態をレポートする ADS 固有の方法があります。 接続変更パケットが ADS 切り替えシーケンスの一部であることを示すために、DisplayMuxConnectionChange フラグが DXGK_CONNECTION_MONITOR_CONNECT_FLAGS に追加されます。 DisplayMuxConnectionChange が設定されている場合、それは MonitorStatusConnected または MonitorStatusDisconnected 接続状態が自動ディスプレイ切り替えに関連付けられていることを示します。

DisplayMuxConnectionChange は ADS 切り替え中にのみ使用する必要があり、他の目的には使用しないでください。 これは、以下の ADS の場合に使用する必要があります。

• ドライバーが の処理を行っている間に DxgkDdiDisplayMuxPreSwitchAwayを実行しています。

  内部パネルが接続されている場合、ドライバーは DXGK_CONNECTION_CHANGE パケットを接続変更リストに追加する必要があります。このとき、DXGK_CONNECTION_CHANGE.ConnectionStatus を MonitorStatusDisconnected に、DXGK_CONNECTION_CHANGE.MonitorConnect.MonitorConnectFlags.DisplayMuxConnectionChange を 1 に設定します。 これらの設定は、ドライバーが内部パネルの制御を解放したことを OS に示します。

• ドライバーが DxgkDdiDisplayMuxPostSwitchToPhase1を処理している間。

  • ドライバーは、最初に内部パネルが接続されているかどうかを判断する必要があります。
  • パネルが接続されている場合、ドライバーは DXGK_CONNECTION_CHANGE パケットを接続変更リストに追加し、DXGK_CONNECTION_CHANGE.ConnectionStatus を MonitorStatusConnected に設定し、DXGK_CONNECTION_CHANGE.MonitorConnect.MonitorConnectFlags.DisplayMuxConnectionChange を 1 に設定する必要があります。
  • パネルが接続されていない場合、ドライバーは DXGK_CONNECTION_CHANGE パケットを接続変更リストに追加する必要があります。このとき、DXGK_CONNECTION_CHANGE.ConnectionStatus を MonitorStatusDisconnected に設定し、DXGK_CONNECTION_CHANGE.MonitorConnect.MonitorConnectFlags.DisplayMuxConnectionChange を 1 に設定します。

• ドライバーが DxgkDdiDisplayMuxSwitchCanceled を処理している間。

  • ドライバーによって DxgkDdiDisplayMuxSwitchCanceled に追加されるすべての変更パケットで、DXGK_CONNECTION_CHANGE.MonitorConnect.MonitorConnectFlags.DisplayMuxConnectionChange を 1 に設定する必要があります。

• * 切り替え中にターゲット ポーリング要求を受信した場合、DxgkDdiDisplayMuxPreSwitchAway、DxgkDdiDisplayMuxPostSwitchToPhase1、または DxgkDdiDisplayMuxSwitchCanceled から追加された接続変更パケットには DisplayMuxConnectionChange のみを追加する必要があります。

DxgkDdiSystemDisplayEnable に関して更新されたガイダンス

ADS ドライバーの DxgkDdiSystemDisplayEnable(/windows-hardware/drivers/ddi/dispmprt/nc-dispmprt-dxgkddi_system_display_enable) DDI が呼び出されたとき、ドライバーは、DxgkDdiSystemDisplayEnable DDI 呼び出しの最後に PSR が無効化されることを確認する必要があります。

OEM ガイダンス

ADS 機能には、プラットフォームで OS が制御するレベルを下回るいくつかの側面があります。 OEM が適切に動作することを確認することは、不可欠です。 次の一覧では、OEM が考慮する必要がある重要なポイントをいくつかまとめました。

• ハイブリッド統合ドライバーとハイブリッド ディスクリート ドライバーの両方で ADS をサポートする必要があります。
• プラットフォーム用に選択されたマルチプレクサは、ACPI を介して制御できます。
• 多重化デバイスの _HID、DMQU および DMCF メソッドと、内部ターゲットの GPU 子 ACPI デバイスが実装され、DMID ACPI メソッドが使用できるようになります。
• 両方の GPU の ACPI デバイスには、mux ACPI デバイスへの依存を示す _DEP が必要です。
• 両方の GPU が公開する明るさインターフェイス/キャップ/範囲は正確に一致します。
• [明るさデータ] セクションで詳述されているように、brightness v3 インターフェイスは、brightness v2 インターフェイスよりも強く推奨されます。
• モニター パネル ドライバーを使用する場合、コードは GPU に依存しない必要があります。つまり、いずれかの GPU がパネルを制御している場合も、同じロジックを使用できます。
• 少なくとも内部多重化の場合、多重化を切り替える動作によって HPD イベントが生成されることはありません。
• OEM がシステムで多重化を無効にする必要がある場合、ARG0 を 2 に設定して呼び出されたときに DMQU ACPI メソッドは 0 を返す必要があります。
• ドライバーが低電力の場合でも、マルチプレクサはGPUを切り替えられる必要があります。 その場合は、PSR は使用されません。
• GPU 間でマルチプレクサーが切り替えられるとき、明るさが急激に変化しないように、パネルの明るさが維持される必要があります。 これを行うには、次の方法を含む複数の方法があります。 OEM は、切り替え中にシステムが明るさを維持することを保証する責任があります。
  • DisplayPort Aux Nits に基づく明るさ制御を利用します。
  • 明るさの不具合を避けるために、PWM再構成を利用してTconを使用してください。
• 切り替え前リンク構成と切り替え後リンク構成が EDID によって公開され、iGPU と dGPU の両方でサポートされている場合に、使用されるパネルと Tcon は、セルフリフレッシュ (eDP の場合は PSR1) を維持できます。 たとえば、次のようなものが挙げられます。
  • [更新頻度]
  • 有効サイズ
  • 使用されている eDP レーンの数とレーン帯域幅
  • eDP DSC の設定
  • 使用されている eDP VSC SDP バージョン
  • 切り替え以外のシナリオで使用される PSR のバージョンと機能