JP5427187B2 - 複数のグラフィックサブシステムおよび低電力消費モードを有するコンピューティングデバイス用ドライバアーキテクチャ、ソフトウェアおよび方法 - Google Patents

Description

［関連出願への相互参照］
本願は、２００７年１２月１３日出願の、発明者フィル ムマーおよびポール ブリンザーによる、本願の譲受人と所有者共通の米国仮特許出願第６１／０１３，５２７号（「複数のグラフィックサブシステムおよび低減電力消費モードを有するコンピューティングデバイス用ドライバアーキテクチャ、ソフトウェア、および方法」）の利益を要求し、そのすべてを参照して、ここに援用する。また、本願は、２００６年５月３０日出願の米国特許出願第１１／４２１，００５号および２００７年５月３０日出願の米国特許出願第１１／７５５，６２５号にも関連し、その両者の内容を参照して、ここに援用する。

本発明は、一般に、コンピューティングデバイスに関し、より詳細には、複数のグラフィックサブシステムを有するデバイス、および関連するソフトウェアドライバに関する。また、一態様において、本発明はこのようなデバイスにおいて電力消費を低減させるための方法を対象としている。

従来のコンピューティングデバイスなどの多くの電子デバイスは現在、二次元および三次元グラフィックのレンダリング、動画ビデオのデコーディングおよびエンコーディングなどが可能なグラフィックサブシステムを備える。このような機能と望ましい処理速度を提供するために、最近のグラフィックサブシステムは搭載されるトランジスタ数がますます増えている。当然、トランジスタ数の増加に伴い、呼応してグラフィックサブシステムの電力消費が増大している。

この結果、最速かつ最も機能が豊富なグラフィックサブシステムは、ほとんどの場合、高い所要電力を満たすことができるデバイスのためのものとなっている。ラップトップ、個人情報端末、ビデオおよびオーディオプレーヤ、携帯電話などといったポータブルコンピューティングデバイスは多くの場合、機能が限られているが、電気効率の高い（すなわち低電力の）部品を装備している。

このようなグラフィックサブシステムは多くの場合、プロセッサ相互接続回路（多くの場合「チップセット」と呼ばれる）などの他のコンピューティング部品に搭載されている。

近年、固定型コンピュータに匹敵するグラフィック機能と性能をポータブルデバイスに提供しようという傾向がある。これは、多くの場合、ポータブルデバイスに、任意選択の強力な外部グラフィックサブシステムを追加可能とすることによって行われる。例えば、ＰＣＩ Ｅｘｐｒｅｓｓ（ＰＣＩｅ）規格は、ラップトップコンピュータへの外付け部品として、グラフィックサブシステムを備えるＰＣＩ Ｅｘｐｒｅｓｓ準拠グラフィックカードの相互接続を想定している。

複数のグラフィックサブシステムが存在する場合、特定のグラフィックサブシステムを使用するために、コンピューティングデバイスを再起動（例えば、リブート）せずに、コンピューティングデバイスの動作状態を切り替えることが求められることが多い。

しかし、一部のオペレーティングシステムのソフトウェアアーキテクチャは、１つのグラフィックドライバの使用しか想定していない。このため、複数のグラフィックサブシステムが存在する場合は、この１つのドライバが、複数のサブシステムの全ての動作を制御する必要がある。これは、特に、異なる製造業者によってサブシステムが供給される場合には、非現実的となることがある。

したがって、複数のグラフィックドライバの使用を可能にするソフトウェアおよびデバイスが依然として求められている。

現在、多くのコンピューティングデバイスが２つ以上のグラフィックサブシステムを備えることがある。複数のグラフィックサブシステムは、能力が異なり、電力消費量が異なることがあり、例えば、あるサブシステムが別のサブシステムよりも多くの平均電力を消費することがある。電力消費の高いグラフィックサブシステムがデバイスに結合されて、低電力消費グラフィックサブシステムの代わりに、またはこれに追加して使用されることがあるが、性能向上と付加の能力が得られるが、全体的な電力消費が増大してしまう。電力消費の高いグラフィックサブシステムを低電力消費モードに設定しつつ、電力消費の高いグラフィックサブシステムの使用から低電力消費グラフィックサブシステムへ切り替えることによって、全体的な電力消費が低減される。

プロセッサがアプリケーションソフトウェアおよびドライバソフトウェアを実行する。前記ドライバソフトウェアは、前記第１のグラフィックサブシステムの動作を制御する第１のドライバコンポーネントと、前記第２のグラフィックサブシステムの動作を制御する第２のドライバコンポーネントとを含む。第１のグラフィックシステムおよび第２のグラフィックシステムのいずれが使用中であるかに応じて、別のプロキシドライバコンポーネントが、アプリケーションソフトウェアから、第１のドライバコンポーネントおよび第２のドライバコンポーネントのいずれかにコール（例えばＡＰＩ／ＤＤＩコール）を転送する。

このプロキシドライバコンポーネントは、オペレーティングシステムとアプリケーションに１つのインタフェースを提示する一方で、２つの別のドライバコンポーネントを使用できるようにし、利便性が高い。プロキシドライバコンポーネントは、Ｗｉｎｄｏｗｓ Ｖｉｓｔａのユーザモードドライバ（ＵＭＤ）コンポーネントおよび／またはカーネルモードドライバ（ＫＭＤ）コンポーネントなどである。

本発明の別の態様によれば、電子デバイスが提供される。前記電子デバイスは、グラフィックをレンダリングするように動作可能な第１のグラフィックサブシステムと、グラフィックをレンダリングするように動作可能な第２のグラフィックサブシステムと、前記第１のグラフィックサブシステムおよび前記第２のグラフィックサブシステムの少なくとも一方と通信している少なくとも１台のディスプレイと、アプリケーションソフトウェアおよびドライバソフトウェアを実行するプロセッサとを備え、前記ドライバソフトウェアは、前記第１のグラフィックサブシステムの動作を制御するための第１のドライバコンポーネントと、前記第２のグラフィックサブシステムの動作を制御するための第２のドライバコンポーネントと、前記第１のグラフィックシステおよび前記第２のグラフィックシステムのいずれが使用中であるかに応じて、前記アプリケーションから、前記第１のドライバコンポーネントおよび前記第２のドライバコンポーネントのいずれかにコールを転送するプロキシドライバコンポーネントとを含む。

本発明の別の態様によれば、グラフィックサブシステムが提供され、前記グラフィックサブシステムは、グラフィックをレンダリングするように動作可能な第１のグラフィックサブシステムと、グラフィックをレンダリングするように動作可能な第２のグラフィックサブシステムと、前記第１のグラフィックサブシステムおよび前記第２のグラフィックサブシステムの両方と通信しているディスプレイと、アプリケーションソフトウェアおよびドライバソフトウェアを実行するプロセッサとを備え、前記ドライバソフトウェアは、前記第１のグラフィックサブシステムの動作を制御するための第１のユーザモードドライバコンポーネントと、前記第２のグラフィックサブシステムの動作を制御するための第２のユーザモードドライバコンポーネントと、前記第１のグラフィックシステおよび前記第２のグラフィックシステムのいずれが使用中であるかに応じて、前記アプリケーションから、前記第１のユーザモードドライバコンポーネントおよび前記第２のユーザモードドライバコンポーネントのいずれかにコールを転送するユーザモードプロキシドライバコンポーネントと、前記第１のグラフィックサブシステムの動作を制御するための第１のカーネルモードドライバコンポーネントと、前記第２のグラフィックサブシステムの動作を制御するための第２のカーネルモードドライバコンポーネントと、前記第１のグラフィックシステムおよび第２のグラフィックシステムのいずれかが使用されているかに応じて、前記ユーザモードドライバコンポーネントのいずれかから、前記第１のカーネルドライバコンポーネントおよび前記第２のカーネルドライバコンポーネントのいずれかにコールを転送するためのカーネルモードプロキシドライバコンポーネントとを含む。

本発明の更に別の態様によれば、グラフィックをレンダリングするように動作可能な第１のグラフィックサブシステムと第２のグラフィックサブシステムとを有するコンピューティングデバイスを動作させる方法が提供される。前記方法は、前記電子デバイスで実行しているソフトウェアアプリケーションまたはオペレーティングシステムからドライバコールを受け取るステップと、前記第１のグラフィックシステおよび前記第２のグラフィックシステムのいずれが使用中であるかに応じて、ソフトウェアアプリケーションから、前記第１のグラフィックサブシステムの動作を制御する第１のソフトウェアドライバコンポーネントおよび前記第２のグラフィックサブシステムの動作を制御する第２のソフトウェアドライバコンポーネントのいずれかに前記ドライバコールを転送するステップとを含む。

本発明のほかの態様および特徴は、添付の図面を参照して、以下の本発明の特定の実施形態の説明を検討すれば、当業者にとって明らかとなるであろう。

本発明の実施形態の例示的なコンピューティングデバイスのブロック図。 本発明の実施形態の例示的なコンピューティングデバイスのブロック図。 従来のソフトウェアの機能ブロック図。 本発明の実施形態の例示的なドライバソフトウェアを有する図２のコンピューティングデバイスの例示的なソフトウェアの機能ブロック図。 本発明の実施形態の例示的な図２のデバイスのソフトウェアによって実行されるステップの詳細を示すフローチャート。 図４のソフトウェアにおけるＡＰＩ／ＤＤＩコールを模式的に示す図。 本発明の実施形態の例示的な図２のデバイスのソフトウェアによって実行されるステップの詳細を示すフローチャート。 図２のコンピューティングデバイスの一部の別のブロック図。 本発明の実施形態の例示的な図２のデバイスのソフトウェアによって実行されるステップの詳細を示すフローチャート。 本発明の別の実施形態の例示的なコンピューティングデバイスの一部の別のブロック図。 本発明の実施形態の例示となる、図１０のデバイスのソフトウェアによって実行されるステップの詳細を示すフローチャート。 図１０のデバイスの動作を示すブロック図。 図１０のデバイスの動作を示すブロック図。 本発明の別の実施形態の例示的なコンピューティングデバイスの一部の別のブロック図。

図面において、本発明の実施形態を、例示のみを目的として図示する。

図１は、２つのグラフィックサブシステム３０および４０とディスプレイ２６とを備える電子デバイス１０の簡略高水準ブロック図である。明らかとなるように、各グラフィックサブシステム３０，４０は、２Ｄグラフィック、３Ｄグラフィック、デコードされた動画ビデオなどのうちの１つ以上の形態でコンピュータグラフィックをレンダリングすることが可能な専用電子回路を備える。

一方のグラフィックサブシステム４０は、もう一方のグラフィックサブシステム３０よりも高い平均電力を消費しうる。一般に、平均電力消費の高いグラフィックサブシステム４０は、グラフィックサブシステム３０よりも優れたグラフィックレンダリング機能を有する。例えば、グラフィックサブシステム４０は、平均電力消費の低いグラフィックサブシステムよりも高いフレームレートで２Ｄまたは３Ｄのグラフィックをレンダリングすることが可能である。同様に、グラフィックサブシステム３０，４０が同じ能力を有している必要はない。グラフィックサブシステム４０は一般にグラフィックサブシステム３０よりも多くの機能ブロックを備える。

グラフィックサブシステム３０，４０はいずれも、レンダリングされたグラフィックが表示される同じディスプレイ２６に物理的または論理的に結合されうる。本発明の実施形態の例示的なデバイス１０は、ディスプレイ２６へのグラフィックが高電力消費のグラフィックサブシステム４０によってレンダリングされる高電力消費モードから、ディスプレイ２６へのグラフィックが低電力消費のグラフィックサブシステム３０によってレンダリングされ、かつグラフィックサブシステム４０が部分的、完全、または実質的に無効にされる低電力モードに切り替わることができる。

高電力モードから低電力モードへの移行は、デバイス１０に電力サイクル（すなわち電源切断および再始動）を要求することなく動的に行われ、かつソフトウェアの制御下でプロセッサ１２によって行うことができ、利便性が高い。この文脈において、ソフトウェアには、アプリケーションソフトウェア、ファームウェア、デバイスドライバ、ＢＩＯＳなどが含まれてもよい。

本発明は、２つのグラフィックサブシステムを備える実質的にあらゆる電子デバイスの一部を構成しうる。このように、デバイス１０は、デスクトップコンピューティングデバイス、ポータブルコンピューティングデバイス（ラップトップコンピュータ、ＰＤＡ、携帯電話、ビデオまたはオーディオプレーヤ、メディアセンタなどを含む）の形態を取ることができる。

以下に説明する例示的な実施形態では、本発明の実施形態はモバイル（ラップトップ）コンピューティングデバイスの一部を構成するものとして開示される。

具体的には、図２は、本発明の実施形態の例示的な特定のモバイルコンピューティングデバイス１０の簡略ブロック図である。図１に示す図示のデバイス１０は、従来のインテル（Ｉｎｔｅｌ）ｘ８６コンピュータアーキテクチャに基づくコンピューティングデバイスである。しかし当業者は、本発明がＰｏｗｅｒＰＣアーキテクチャ、ＡＭＤｘ８６または他の公知のアーキテクチャなどの他のアーキテクチャを有するコンピューティングデバイスにおいて実装されてもよいことを容易に認めるであろう。

図に示すように、例示のデバイス１０は、中央処理装置（ＣＰＵ）として形成されたプロセッサ１２、ホストメモリ１４および周辺機器を備え、これらはすべて、一体型インタフェース回路１６，１８（ノースブリッジ１６およびサウスブリッジ１８とも呼ばれる）によって相互接続されている。これらはすべてマザーボード上に形成することができる。

インタフェース回路１６は、高速インタフェースであり、ＣＰＵ１２、メモリ１４および周辺機器を高速拡張バス２０経由で相互接続している。インタフェース回路１６は更に、ＣＰＵ１２を低速インタフェース回路１８に相互接続している。１つ以上の周辺機器拡張スロット２２が高速拡張バス２０経由でインタフェース回路１６と相互接続されうる。例示的な高速拡張バス２０は、ギガバイト／秒範囲の帯域幅を有するＰＣＩ Ｅｘｐｒｅｓｓ（ＰＣＩｅ）バスであり、この帯域幅でのデータ転送リード／ライトを可能にする。

インタフェース回路１６は更に、モニタ、ＬＣＤパネル、テレビなどの形態をとりうるディスプレイ２６での表示のためのビデオ信号の生成に適した一体型グラフィックプロセッサ（ＩＧＰ）として実装された第１のグラフィックサブシステム３０を備える。

追加の第２のグラフィックサブシステム４０がデバイス１０の一部を形成している。例示的な実施形態では、グラフィックサブシステム４０は周辺拡張カード４６に形成された外部グラフィックプロセッサとして実装されている。また、周辺拡張カード４６は拡張バス２０の拡張スロット２２を経由してインタフェース回路１６に接続される。以下で明らかとなるように、第２のグラフィックサブシステム４０を設けることにより、デバイス１０は、デバイス１０が本来備えない拡張グラフィック機能を提供することができる。第２のグラフィックサブシステムによってフレームバッファとして使用するために、グラフィックメモリ５０が周辺拡張カード４６に備えられうる。同様に、グラフィックサブシステム４０と通信している電力コントローラ６０が任意選択で拡張カード４６に形成され、グラフィックサブシステム４０の動作を制御することができる。具体的には、電力コントローラ６０は、グラフィックサブシステム４０の部品によって使用されるメモリクロックおよびピクセルクロックなどのクロックを調節する、グラフィックサブシステム４０の機能ブロックを無効に（または切断）する、グラフィックサブシステム４０の各部分に印加される電圧を下げる、あるいは別の方法で電力消費が低減される１つ以上のモードにサブシステム４０を公知のように設定することができる。

任意選択の別の電力コントローラ７０が第１のグラフィックサブシステム３０と通信していてもよく、グラフィックサブシステム３０の部品によって使用されるメモリクロックおよびピクセルクロックなどのクロックを調節する、グラフィックサブシステム３０の機能ブロックを無効に（または切断）する、グラフィックサブシステム３０の各部分に印加される電圧を下げる、あるいは別の方法で電力消費が低減される１つ以上のモードにサブシステム３０を公知のように設定することができる。

例示的なグラフィックサブシステム４０は周辺拡張カード４６に形成されているが、当業者はグラフィックサブシステム４０がデバイス１０のマザーボードに、または他の場所にも同様に簡単に形成できることを容易に認めるであろう。

インタフェース回路１８は、光ディスクドライブ２８などの低速周辺機器および相互配線、ならびにハードディスクドライブの形態の持続型記憶メモリ３４を一体型ＩＤＥ／ＳＡＴＡポート（図示せず）経由で、ならびにプリンタおよび他の周辺機器をパラレルまたはＵＳＢポート（図示せず）経由で相互接続する。更に他の周辺機器が、例えば公知のＰＣＩまたはＩＳＡ規格に準拠した低速拡張バス２４によって相互接続されうる。サウンドカードおよびネットワークインタフェース（図示せず）などの他の部品も同様に低速拡張バス２４経由で、または別様にインタフェース回路１８と相互接続されうる。

上で説明したように、デバイス１０は、ラップトップまたは小型コンピューティングデバイスの形態のポータブルコンピューティングデバイスとして好適に形成することができる。このため、１つのハウジングがＤＣ電源３８、ディスプレイ２６、および上述のマザーボードおよび部品を収容してもよい。第２のグラフィックサブシステム４０は、コンピューティングデバイスの他の部分を収容する１つのハウジングに追加されても、またはデバイス１０が物理的に相互接続された時にのみデバイス１０の一部を構成するドッキングステーションの一部を形成してもよい。

デバイス１０は、少なくとも２つの電力消費モード、すなわち、高電力消費モードと低電力消費モードで動作することができる。図に示した実施形態では、デバイス１０の高電力モードとは、デバイス１０がＡＣ（主）電源に接続された電源によって給電されている時に入るモードであり、低電力消費モードとは、デバイス１０が１つ以上のバッテリ、燃料電池などを使用するＤＣ電源３８によって給電されている時に入るモードでもよい。別例では、電力消費モードが、例えばユーザの好み、実行中のソフトウェアアプリケーションのタイプ、バッテリレベルなどに基づき、ユーザによって選択されるか、ソフトウェアによって制御されるか、または別の方法で選択されてもよい。

図に示した実施形態では、デバイス１０は、図４に図に示すように、システムメモリ内部に記憶されたソフトウェア２００を実行する。システムメモリは持続型記憶メモリ３４およびホストメモリ１４を含み（図２）、更にソフトウェア２００を記憶し実行するためにデバイス１０によって使用される追加のランダムアクセスメモリ、リードオンリーメモリおよびディスク記憶メモリの適切な組合せを含み得る。例示的なソフトウェア２００は、例えば、リードオンリーメモリに記憶されても、またはディスクドライブ２８（図１）などの外部周辺機器からロードされても、コンピュータネットワーク（図示せず）によってロードされてもよい。

例示実施形態において、ソフトウェア２００はＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ Ｖｉｓｔａプラットホームに基づく。しかし、デバイス１０を動作させるソフトウェアは、本発明の実施形態の例示的な様態において、このプラットホームに基づく必要はない。代わりに、例示的なソフトウェアは、Ｌｉｎｕｘ、ＭａｃＯＳＸなどの他の公知のコンピュータオペレーティングシステム、または他のオペレーティングシステムとともに動作することができる。オペレーティングシステムが異なる場合、ソフトウェアアーキテクチャが図４に図示したものと大きく変わることがある。

Ｗｉｎｄｏｗｓ Ｖｉｓｔａオペレーティングシステム環境では、グラフィックサブシステム３０，４０などのハードウェア部品の低レベル制御は一般に、ドライバと一般に呼ばれるソフトウェアコンポーネントによって実施される。各ハードウェア部品の動作は、１つ以上のこのようなコンポーネントによって制御される。

Ｗｉｎｄｏｗｓ Ｖｉｓｔａオペレーティングシステムの場合、ドライバアーキテクチャは、Ｗｉｎｄｏｗｓデバイスドライバ（ＷＤＤＭ）と呼ばれ、Ｍｉｃｒｏｓｏｆｔ ＷｉｎｄｏｗｓドライバキットＡＰＩに詳しく記載されている。詳細は、http://www.microsoft.com/whdc/devtools/WDK/AboutWDK.mspxおよびhttp://msdn2.microsoft.com/en-us/library/aa480220.aspxから入手することができ、その内容を参照によりここに援用する。

図４に示すソフトウェア２００の動作を説明する前に、従来のＷｉｎｄｏｗｓ Ｖｉｓｔａアーキテクチャを説明することが適切であろう。このために、図３は、Ｗｉｎｄｏｗｓ Ｖｉｓｔａオペレーティングシステムに基づく従来のソフトウェア２００’を示す。図に示すように、ソフトウェア２００’は、アプリケーションソフトウェア２０２’と、数個の汎用のオペレーティングシステムのグラフィックコンポーネント２０４’，２０６’，２０８’，２１０’（ランタイムコンポーネントと呼ばれる）と、サブシステム３０または４０などのグラフィックサブシステム用のデバイスドライバを定義する、数個のハードウェア固有のグラフィックデバイスドライバコンポーネント２２０，２２２，２２４とを含む。同様に、ディスプレイローダモジュール２１８’、Ｗｉｎｄｏｗｓ Ｖｉｓｔａカーネル２１６’、およびＷｉｎｄｏｗｓグラフィックデバイスインタフェース（ＧＤＩ）ソフトウェア２１４’も図示されている。

明らかとなるように、Ｗｉｎｄｏｗｓ Ｖｉｓｔａオペレーティングシステムの下のドライバソフトウェアは、ユーザモードまたはカーネルモードのいずれかで動作することができる。ユーザモードドライバ（ＵＭＤ）コンポーネントは、プロセッサ１２によってサポートされる非特権のモードで実行し、メモリ、レジスタへの限られたアクセスが許可される。図２では、コンポーネント２２０，２２２がＵＭＤコンポーネントである。アプリケーションソフトウェア２０２を含む他のソフトウェアもこのモードで実行する。ＵＭＤコンポーネント２２０，２２２とアプリケーションソフトウェア２０２’は、直接低レベルのシステムデータにアクセスすることができない。同様に、これらが、メモリのすべての領域、すべてのレジスタなどにアクセスできるとは限らない。しかし、これらは、カーネルモードで実行しているソフトウェアへのコールを行うことができる。

これに対し、カーネルモードドライバ（ＫＭＤ）コンポーネントは、オペレーティングシステムカーネルと同じプロセッサモードで実行し、このため、通常、デバイス１０のメモリ、レジスタやその他のリソースに無制限にアクセスすることができる。ＵＭＤコンポーネントはＫＭＤコンポーネントをコールし、コンピューティングデバイス１０のリソースへの低レベルのアクセスを得ることができる。コンポーネント２２４はＫＭＤコンポーネントである。ＫＭＤドライバアーキテクチャは、２００６年５月１０日の「カーネルモードドライバフレームワークのためのサンプルドライバ（Sample Drivers for the Kernel Mode Driver Framework）」http://www.microsoft.com/whdc/driver/wdf/KMDF-samp.mspxと、「Introduction to WDM（ＷＤＭ入門）」http://msdn2.microsoft.com/en-us/library/aa490246.aspxに詳しく説明されている。

ＵＭＤコンポーネントとＫＭＤコンポーネントは、構造、エントリポイントおよびシステムインタフェースが異なる。デバイスが、ＵＭＤ、ＫＭＤのいずれを必要とするかは、デバイスの種類と、デバイス用にオペレーティングシステムに既に提供されているサポートとに応じて決まる。グラフィックサブシステム３０，４０などのグラフィックサブシステム用のドライバは、通常、カーネルモードで動作している少なくとも１つのコンポーネントを含む。更に、Ｗｉｎｄｏｗｓ Ｖｉｓｔａオペレーティングシステムでは、ＫＭＤコンポーネントはシステムの初期化（すなわち電源投入時）にロードされるが、ＵＭＤコンポーネントは、必要なときにオンデマンドでロードされうる。

より詳細には、Ｗｉｎｄｏｗｓ Ｖｉｓｔａアーキテクチャでは、グラフィックサブシステム用のＵＭＤコンポーネントが、グラフィックサブシステムが使用するリソースに低レベルでアクセスするために、対応するＫＭＤコンポーネントと通信を行なう。一般に、各ＫＭＤコンポーネントは、デバイスドライバインタフェース（ＤＤＩ）を提供し、これを対応するＵＭＤコンポーネントが認識している。ＤＤＩには、関数呼出し、オブジェクト（メソッドを含む）、入出力制御（ＩＯＣＴＬ）コール、および関連するデータ構造が含まれうる。明らかとなるように、関数呼出しは、多くの場合このようなデータ構造として構成される関数／メソッドのパラメータを介して、データを受け取る。データ構造の厳密な特徴は、ＤＤＩ定義に規定されている。

図に示した実施形態では、オペレーティングシステムグラフィックコンポーネント２０４’，２０６’，２０８’は、オペレーティングシステムの製造業者（この場合マイクロソフト）が供給するランタイムコンポーネントである。一方、ＵＭＤコンポーネントとＫＭＤコンポーネントの形のハードウェア固有ドライバコンポーネント２２０，２２２，２２４は、サードパーティの製造業者（例えばグラフィックサブシステム３０または４０の製造業者）によって提供されうる。

オペレーティングシステムグラフィックコンポーネントは、ランタイム三次元グラフィックランタイムコンポーネント２０４’（Ｄｉｒｅｃｔ ３Ｄランタイム）と、ハードウェア高速化グラフィックインタフェースランタイムコンポーネント（ＤＸＶＡ）２０６’と、３Ｄオープンフラフィックスライブラリ（ＯｐｅｎＧＬ）ランタイムグラフィックコンポーネント２０８’とを有する。対応するハードウェア固有のＵＭＤコンポーネント２２０，２２２は、Ｄｉｒｅｃｔ ３Ｄ、ＤＸＶＡ、およびＯｐｅｎＧＬ ＡＰＩに対応するＡＰＩハードウェアコールのハードウェア固有の実装を提供する。

ランタイムコンポーネント２０４’，２０６’，２０８’とＵＭＤコンポーネント２２０，２２２は、アプリケーションソフトウェア２０２およびオペレーティングシステムのほかの部分が使用する、一元化されたグラフィックアプリケーションプログラマインターフェース（ＡＰＩ）を提供する。より詳細には、マイクロソフトが詳細に説明しているように、ＡＰＩは、ＵＭＤコンポーネント２２０’，２２２’またはランタイムコンポーネント２０４’，２０６’，２０８’内のドライバソフトウェアルーチン（例えば関数またはメソッド）を実行させる関数呼出し、オブジェクトなどを提供する。ＡＰＩコールは、アプリケーションソフトウェア２００’、オペレーティングシステムの一部（例えばモジュール２０４’，２０６’，２０８’）、または他のドライバによって行われうる。これに対して、ＵＭＤコンポーネント２２０，２２２は、このＡＰＩコールに対応するソフトウェアコードを（通常は関数またはオブジェクトメソッドの形で）実行する。Ｄ３Ｄ、ＤＸＶＡおよびＯｐｅｎＧＬのＵＭＤコンポーネント２２０，２２２によって提供される関数およびコールバックは、マイクロソフトデベロッパーズネットワーク（ｗｗｗ．ｍｓｄｎ．ｃｏｍ）から入手可能な「Windows Driver Kit: Display Devices Windows Vista Display Driver Model Reference」に詳しく記載されている。

より詳細には、ＵＭＤコンポーネント２２０，２２２またはＫＭＤコンポーネント２２４がロードされると、オペレーティングシステムのロードルーチンが、ドライバコンポーネントのエントリポイントをみつけ、この名前は、ＤｒｉｖｅｒＥｎｔｒｙ（）（カーネルモードドライバ用）、あるいはＵＭＤコンポーネント２２０，２２２ではＤｌｌＭａｉｎ（）やその他（例えばＯｐｅｎＡｄａｐｔｅｒ（））である。ＵＭＤ／ＫＭＤコンポーネント２２０，２２２，２２４は、ＯＳから周知の構造体を受け取る関数を有し、この構造体を、ＵＭＤ／ＫＭＤコンポーネント２２０，２２２，２２４のエントリポイントのコードが、所期の挙動を実装するＵＭＤ／ＫＭＤコンポーネント２２０，２２２，２２４内の関数をポイントするように埋める。この名前は、ＤＤＩ仕様によって定義されており、いわゆる定義ファイルによって実装される。

例えば、ＫＭＤコンポーネント２２４は、ＤＤＩのドライバ実装関数セットの一部であるさまざまな動作のための関数ポインタのセットを含むＤＲＩＶＥＲ＿ＩＮＩＴＩＡＬＩＺＡＴＩＯＮ＿ＤＡＴＡ構造体を受け取る。必要に応じて、ＵＭＤコンポーネント２２０，２２２の残りの部分が、これらの関数をコールしてドライバの適切な動作を開始し、これにより、必ずしもすべての場合ではないが多くの場合、（通常、別の何らかのＫＭＤドライバの内部関数を呼び出すことによって）ハードウェアアクセスが発生する。

ＵＭＤコンポーネント２２０，２２２は、ダイナミックリンクライブラリ（ＤＬＬ）として作成されてもよく、ＷＤＤＭに準拠する。このように、各ＵＭＤコンポーネント２２０，２２２は、ＷＤＤＭに準拠した関数およびオブジェクト、ＩＯＣＴの集合を提供する。概して、各ドライバコンポーネントは、定義済みのエントリポイントであるＤｒｉｖｅｒＥｎｔｒｙ（）、定義済みのオブジェクトクラス、ドライバエントリポイント、定義済みの関数およびコールバックを有する。各ドライバがロードされると、そのエントリポイントのソフトウェアコードが実行され、ＤｒｉｖｅｒＥｎｔｒｙ（）および定義済みのドライバルーチンが、所期の構造体に登録される。

ＤｌｌＭａｉｎ（）エントリポイントは、ＵＭＤコンポーネントの基本的なデータ構造を割り当てて初期化するため、あるいはＵＭＤのアンロード時に、これを制御されたメカニズムで破棄するために使用される。

ＷＤＤＭ ＵＭＤコンポーネントの場合、ＯｐｅｎＡｄａｐｔｅｒ（）コールは、ＫＭＤコンポーネントのＤｒｉｖｅｒＥｎｔｒｙ（）コールと同様に動作する。すなわち、ＯｐｅｎＡｄａｐｔｅｒ（）コールは、関数ポインタのセットを含むデータ構造を受け取り、ＵＭＤコンポーネント２２０，２２２が、ＵＭＤコンポーネント内の適切な関数を示すようにこのデータ構造を埋める。

このため、この構造体により、ＵＭＤ内のサポートされる関数／オブジェクトおよび関連するコードの名前およびアドレスが、オペレーティングシステムのほかの部分に戻される。この場合も、Ｄ３Ｄ、ＤＸＶＡおよびＯｐｅｎＧＬのＵＭＤコンポーネント２２０，２２２によってサポートされるＵＭＤ関数および構造体は、マイクロソフトデベロッパーズネットワークから入手可能な上記の「Windows Driver Kit: Display Devices Windows Vista Display Driver Model Reference」に詳しく記載されている。

このため、各ＵＭＤコンポーネント２２０，２２２のロードを終了した時点で、ＡＰＩ関数／オブジェクトおよびＩＯＣＴＬが、アプリケーション２０２’とオペレーティングシステムソフトウェアの残りに認識されている。特定されたアドレスでオブジェクトのインスタンスを生成することにより、アプリケーションソフトウェア２００によってＡＰＩオブジェクトがインスタンス生成されうる。関数／メソッドとＩＯＣＴＬが、その対応するアドレスで実行されうる。

また、オペレーティングシステムグラフィックモジュールは、カーネルモードグラフィックコアソフトウェアコンポーネント２１０’（Ｗｉｎｄｏｗｓ Ｖｉｓｔａオペレーティングシステムでは「ＤｉｒｅｃｔＸ Ｃｏｒｅ」と呼ばれる）とＫＭＤコンポーネント２２４も含む。グラフィックコアソフトウェアコンポーネント２１０’は、ＵＭＤコンポーネント２２０，２２２のために、これらがデバイス１０のリソースにカーネルモードでアクセスできるようにするためのＡＰＩを提供する。グラフィックコアソフトウェアコンポーネント２１０’は、ビデオメモリマネージャ、スケジューラ、互換性のために特定のＡＰＩ／ＤＤＩ要求を変換する（または「サンク」する）ルーチンを更に含む。上で詳細に説明したように、ＫＭＤコンポーネント２２４は、Ｗｉｎｄｏｗｓドライバモデル、すなわちＷｉｎｄｏｗｓドライバフレームワークに準拠しうる。このように、ＫＭＤコンポーネント２２４は定義済みのオブジェクトクラス、関数、および構造体を含み、ＤＤＩを提供する。

ＵＭＤコンポーネント２２０，２２２と同様に、ＫＭＤコンポーネント２２４は、初期化ルーチンであるＤｒｉｖｅｒＥｎｔｒｙ（）を有し、このルーチンは、通常、名前とメモリアドレスによって、オブジェクトクラス、関数および構造体の識別子を返し、ＫＭＤコンポーネント２２４のための必要なＤＤＩを提供する。上で説明したように、ＫＭＤコンポーネント２２４は通常、システム起動時にロードされ（初期化される）。

また、ＫＭＤコンポーネント２２４は、オペレーティングシステムのほかの部分には特に認識されず、報告もされないが、相補的なＵＭＤドライバ２２０または２２２には認識されているＤＤＩも有しうる。

ソフトウェア２００は階層構造を有しており、上位レベルのレイヤが、特定の機能を提供するために下位レイヤを使用する。このため、アプリケーションソフトウェア２０２は、通常、ランタイムオペレーティングシステムグラフィックモジュール２０４’，２０６’，２０８’、あるいはＵＭＤコンポーネント２２０，２２２またはＧＤＩ２１４’に対してコールを行うことによって、グラフィックをレンダリングする。グラフィックモジュール２０４’，２０６’，２０８’は、全てのサードパーティのビデオドライバに共通の、汎用のハードウェアに依存しないコードのみを含む。このため、ランタイムコンポーネント２０４’，２０６’，２０８’は、ＵＭＤコンポーネント２２０，２２２にＡＰＩ／ＤＤＩコールを行いうる。データ構造内に定義した既知のパラメータが、例えば生成した構造体を指す適切なポインタによって、ＵＭＤコンポーネント２２０，２２２に渡される。ＵＭＤコンポーネント２２０，２２２は、ハードウェア固有のコードと構造体を含む。しかし、上で説明したように、ＵＭＤコンポーネント２２０，２２２はユーザレベルのアクセスしか持たない。ＵＭＤコンポーネント２２０，２２２は、ＫＭＤコンポーネント２２４によって提供される公知のＡＰＩ／ＤＤＩを直接使用することにより、あるいはカーネルモードグラフィックコアソフトウェアコンポーネント２１０’を介して、ＫＭＤコンポーネント２２４と通信する。

ＫＭＤコンポーネント２２４は、下層のハードウェア（例えばグラフィックサブシステム３０または４０）に、適切な低レベル命令を渡すことができる関数、オブジェクトなどを有する。ＫＭＤコンポーネント２２４への複数のコールがキューイングされうる。これに対して、低レベル命令が、下層のハードウェアによって実行されうる。例えば、低レベル命令には、グラフィックプロセッサ実行可能命令などが含まれうる。

多くの他の公知のオペレーティングシステムとは異なり、Ｗｉｎｄｏｗｓ Ｖｉｓｔａでは、１つのディスプレイドライバＫＭＤコンポーネント２２４’のロードしか許可されない。別の補助アプリケーションが、ディスプレイドライバローダ２１８’として動作する。ローダ２１８’は、一般に、起動時に実行されるが、起動後に実行されてもよい。ローダ２１８’は、グラフィックコアソフトウェアコンポーネント２１０がアクセスするために、サードパーティのＫＭＤコンポーネント（例えばＫＭＤコンポーネント２２４’）をロードして、これを初期化する。ローダ２１８は、ＫＭＤコンポーネント２２４’などのカーネルモードドライバコンポーネントのロード／アンロードに使用されうるが、グラフィックＫＭＤコンポーネントをロードするには、別のドライバをアンロードする必要がある。

ここで、サブシステム３０，４０（図１）などの２つのグラフィックサブシステムが存在する場合、ＵＭＤコンポーネント２２０，２２２とＫＭＤコンポーネント２２４は、この両者のグラフィックサブシステムの動作を制御し、２つのグラフィックシステム間を選択的に切り替え可能にする。ドライバコンポーネント２２０，２２２，２２４へのＡＰＩコールが、複数のサブシステムのうちのいずれが指定されているかを特定しうる。しかし、１つのＵＭＤ／ＫＭＤが、複数のグラフィックサブシステムをサポートしなければならことが制限となる。例えば、１つのドライバが多数の異なるアダプタをサポートすることは、非現実的なことがある。この問題は、サブシステムが異なる製造業者によって供給される場合は更に悪くなる。

図４は、本発明の実施形態の例示的なソフトウェアとグラフィックモジュールとを示す。この場合も、例示的なソフトウェアを、Ｗｉｎｄｏｗｓ Ｖｉｓｔａ環境を例に挙げて説明する。このため、オペレーティングシステムの一部を形成するモジュールおよびコンポーネントは図３に示したものと同じであり、図４では「’」を付けずに同じ参照番号で示し、詳細に説明することはない。

しかし、着目すべきは、ＵＭＤコンポーネント２２０，２２２とＫＭＤコンポーネント２２４（図３）がそれぞれ、プロキシドライバコンポーネント、すなわちＵＭＤプロキシコンポーネント３２０，３２２とＫＭＤプロキシコンポーネント３２４に置き換わっている。明らかとなるように、ＵＭＤプロキシコンポーネント３２０，３２２とＫＭＤプロキシコンポーネント３２４は、オペレーティングシステムのほかの部分に、ＡＰＩ／ＤＤＩの１つのセットを提供し、１つのグラフィックドライバとして認識される。このため、ランタイムコンポーネント２０４，２０６，２０８；アプリケーションソフトウェア２０２；およびオペレーティングシステムのほかの部分は、図３のグラフィックＡＰＩ関数／オブジェクトを呼び出し（またはコール）しうる。

追加の電力制御アプリケーション２０１も、機能的に図示されている。明らかとなるように、電力制御アプリケーションは図１のグラフィックサブシステム３０，４０全体の電力消費状態を制御しうる。電力制御アプリケーション２０１は、スタンドアロンのアプリケーションでも、ＡＴＩ／ＡＭＤ Ｉｎｃ．から入手可能なＣａｔａｌｙｓｔ Ｃｏｎｔｒｏｌ Ｃｅｎｔｅｒアプリケーションなどの全般的なユーザ／グラフィックサブシステム制御および構成アプリケーションの一部であってもよい。

これに対し、ＵＭＤプロキシコンポーネント３２０，３２２とＫＭＤプロキシコンポーネント３２６は、このようなグラフィック関数のコールを、複数の個々のハードウェア固有のＵＭＤグラフィックドライバコンポーネント３４０，３４２；３５０，３５２；およびＫＭＤグラフィックドライバコンポーネント３７０，３７２のいずれかに、転送する。詳細には、下で詳細に説明するように、ＵＭＤプロキシコンポーネント３２０は、ＵＭＤコンポーネント３４０または３４２にコールを転送し、ＵＭＤプロキシコンポーネント３２２は、ＵＭＤコンポーネント３５０または３５２にコールを転送し、ＫＭＤプロキシコンポーネント３２４はＫＭＤプロキシコンポーネント３６０またはＫＭＤプロキシコンポーネント３６２にコールを転送する。

ＵＭＤコンポーネント３４０，３５０および３４２，３５２は、ＵＭＤコンポーネント２２０と同様に、グラフィックサブシステム３０，４０のハードウェアにそれぞれ固有の関数、オブジェクト、ＩＯＣＴＬなどを含む、グラフィックサブシステム３０，４０に対応するハードウェア固有のＵＭＤコンポーネントである。ＫＭＤコンポーネント３６０，３６２は、同じように、ＫＭＤコンポーネント２２４と同様であり、カーネルモードでグラフィックサブシステム３０，４０と対話するように設計された関数、オブジェクト、ＩＯＣＴＬなどを含む。

例えば、ＵＭＤコンポーネント３４０，３５０とＫＭＤコンポーネント３６０は、第１のグラフィックサブシステム３０用のユーザモードＤｉｒｅｃｔＸドライバソフトウェア、ＯｐｅｎＧＬドライバソフトウェア、およびカーネルモードドライバソフトウェアコンポーネントをそれぞれ提供し、ＵＭＤコンポーネント３４２，３５２とＫＭＤコンポーネント３６２は、第２のグラフィックサブシステム４０用のユーザモードＤｉｒｅｃｔＸドライバソフトウェア、ＯｐｅｎＧＬドライバソフトウェア、およびカーネルモードドライバソフトウェアコンポーネントをそれぞれ提供しうる。コンポーネント３４０，３５０，３６０（またはコンポーネント３４２，３５２，３６２）は、グラフィックＵＭＤ／ＫＭＤコンポーネント２２０，２２２，２２４の代わりに、図３に示すようにオペレーティングシステムによって直接ロードされうるという点で従来と同じであり、利便性が高い。

このようにして、グラフィックＵＭＤ／ＫＭＤコンポーネント３４０，３４２；３５０，３５２；３６０，３６２のそれぞれは、低レベルグラフィック機能を実行し、含まれるグラフィックハードウェアに固有の方法でグラフィックハードウェアにアクセスしうる。

ＵＭＤプロキシドライバコンポーネント３２０，３２２とＫＭＤプロキシドライバコンポーネント３２４は、一方では、オペレーティングシステムのほかの部分および他のアプリケーションに、一意のＡＰＩ／ＤＤＩを提示し、他方では、ハードウェア固有のＵＭＤ／ＫＭＤドライバコンポーネント３４０，３５０，３６０または３４２，３５２，３６２に、コール、ＩＯＣＴＬ、要求、現在のオブジェクトなど（集合的に「ＡＰＩ／ＤＤＩコール」と呼ぶ）を転送し、利便性が高い。

動作時に、ＵＭＤプロキシドライバコンポーネント３２０，３２２とＫＭＤプロキシドライバコンポーネント３２４が、オペレーティングシステムのほかの部分によってロードされる。

ＵＭＤプロキシドライバコンポーネント３２０または３２２がロードされると、そのエントリルーチン（例えばＤＩＩＭａｉｎ（）／ＯｐｅｎＡｄａｐｔｅｒ（））が実行される。明らかとなるように、ＵＭＤプロキシドライバコンポーネント３２０，３２２のエントリルーチンは、ＵＭＤコンポーネント２２２，２２４と同様に、ＵＭＤコンポーネント３４０，３４２の一方または両方をロードし、Ｖｉｓｔａオペレーティングシステムのほかの部分に、ＵＭＤプロキシドライバコンポーネント３２０，３２２内のサポートされるＡＰＩ／ＤＤＩコールを識別している、所期のデータ構造を提供する。この場合も、所期のＡＰＩ／ＤＤＩのアドレスが、所期の構造体によって関数、オブジェクト、ＩＯＣＴＬへのアドレスの形で提供される。

図５のブロックＳ５００により詳細に示すように、ＵＵＭＤプロキシドライバコンポーネント３２０内のソフトウェアコードによって、ＭＤコンポーネント３４０，３４２がロードされる。詳細には、ブロックＳ５０２において、ＵＭＤコンポーネント３４０または３４２などのＵＭＤドライバコンポーネントが、通常は、動的にリンクされたライブラリとしてロードされる。次に、ＵＭＤプロキシドライバコンポーネント３２０によって、新たにロードされたＵＭＤコンポーネント３４０または３４２のドライバ初期化ルーチンＤＩＩＭａｉｎ（）／ＯｐｅｎＡｄａｐｔｅｒ（）などがコールされうる。ブロックＳ５０４において、新たにロードされたＵＭＤコンポーネント３４０または３４２のドライバ初期化ルーチンが、（ＵＭＤコンポーネント２２０，２２２が名前、アドレスなどを返すのと同様に）サポートされる関数の名前およびアドレス、ＩＯＣＴＬなどを、ＵＭＤプロキシコンポーネント３２０に返す。次に、ブロックＳ５０８において、ＵＭＤプロキシドライバコンポーネント３２０は、ロードされたＵＭＤコンポーネント３４０または３４２によってサポートされるオブジェクトクラス、関数、ＩＯＣＴＬ等の間の一致を表すデータ構造を作成する。

例えば、ＵＭＤプロキシドライバコンポーネント３２０が、ＤＸＶＡの関数呼出しおよびオブジェクトをサポートするように設計され、このため、公知のＤＸＶＡの関数呼出しおよびオブジェクトと、ロードされたＵＭＤコンポーネント３４０または３４２内のそのエントリポイント間の一致が作成される。ブロックＳ５０６の終了時点で、ＵＭＤプロキシドライバコンポーネント３２０は、メモリ内に、ＵＭＤプロキシドライバコンポーネント３２０によってサポートされるＤＸＶＡの関数、オブジェクト、ＩＯＣＴＬなどのそれぞれに対応する、ＵＭＤコンポーネント３４０または３４２内のアドレスを提供する構造体を作成しうる。

特定のＵＭＤコンポーネント３４０または３４２；３５０または３５２が、プロキシドライバコンポーネント３２０，３２２によってロードされても、必要に応じて動的にロードされてもよい。つまり、グラフィックサブシステム３０または４０のいずれかが使用中ではない場合、これに対応するＵＭＤドライバコンポーネントはロードする必要がない。

ブロックＳ５００に対応するソフトウェアが、ＵＭＤプロキシドライバコンポーネント３２０によってロードされるＵＭＤドライバ３４０，３４２ごとに実行されうる。ステップＳ５００は、ＵＭＤコンポーネント３５０，３５２のためのプロキシドライバコンポーネントとして動作するＵＭＤプロキシドライバコンポーネント３２２によっても同様に実行される。

同様に、ブロックＳ５００は、ＫＭＤプロキシドライバコンポーネント３２４の初期化時（通常はシステムの起動時）にも実行されうる。ＫＭＤプロキシドライバコンポーネント３２４は、ＫＭＤドライバ３６０，３６２の初期化ルーチン（例えばＯｐｅｎＡｄａｐｔｅｒ（））を実行する。

サポートされる各ドライバコンポーネント（例えばＵＭＤコンポーネント３４０，３４２；ＵＭＤコンポーネント３５０，３５２；およびＫＭＤコンポーネント３６０，３６２）について、ＵＭＤプロキシドライバコンポーネント３２０，３２２とＫＭＤプロキシドライバコンポーネント３２４のそれぞれにより、ブロックＳ５００（またはその均等物）が実行されると、ＵＭＤ／ＫＭＤプロキシドライバコンポーネント３２０，３２２，３２４が、グラフィックサブシステム３０，４０に固有のＵＭＤ／ＫＭＤコンポーネントをロードしており、ロードされたＵＭＤコンポーネント３４０，３４２；３５０，３５２；およびＫＭＤコンポーネント３６０，３６２内のサポートされる関数、ＩＯＣＴＬの対応するメモリアドレス／エントリポイントを確認している。

オペレーティングシステムのほかの部分にシステムリソース情報を提供するために、ＫＭＤプロキシコンポーネント３２４のみが、グラフィックサブシステム３０，４０の両者について直接認識可能であり、インストール可能である。グラフィックサブシステム３０，４０の両者のドライバ固有のレジストリエントリがマージされ、プロキシドライバコンポーネントが、これらのレジストリエントリを読み出し、ＵＭＤコンポーネント３４０，３５０；３４２，３５２に公開しうる。

また、ＵＭＤコンポーネント３４０，３４２；３５０，３５２は、複数のプロパティも返すが、返されるプロパティが、複数のグラフィックサブシステムとの対話に使用される１つのドライバと矛盾しないことを保証するために、ＵＭＤプロキシコンポーネント３２０，３２２によってプロパティが収集され、調整される必要がある。このようなプロパティは、ＵＭＤプロキシコンポーネント３２０，３２２によって、オペレーティングシステムに渡されうる。例えば、ビデオメモリヒープ、ＧＰＵエンジンのプロパティ、ＤＭＭトポロジなどを、ＵＭＤプロキシコンポーネント３２０，３２２によってマージする必要がある。

ＵＭＤ／ＫＭＤコンポーネント３４０，３４２；３５０，３５２；および３６０，３６２をロードする代りに、これらが、ビルド時に、ＵＭＤプロキシドライバコンポーネント３２０，３２２；およびＫＭＤプロキシコンポーネント３２４に静的にリンクされてもよい。これを行うには、当然、ＵＭＤ／ＫＭＤコンポーネント３４０，３４２；３５０，３５２；および３６０，３６２、またはリンク可能オブジェクトモジュールのソースコードにアクセスできる必要がある。

ＵＭＤプロキシコンポーネント３２０，３２２；およびＫＭＤプロキシコンポーネント３２４がドライバＵＭＤコンポーネント３４０，３４２；３５０，３５２；３６０，３６２をロード／リンクする結果、ＵＭＤプロキシドライバコンポーネント３２０，３２２；およびＫＭＤプロキシ３２４は、アプリケーションソフトウェア２０２またはオペレーティングシステムのほかの部分によって、グラフィックサブシステム３０または４０のいずれが指定されているかに応じて、ＵＭＤ／ＫＭＤプロキシコンポーネント３２０，３２２，３２４へのＡＰＩ／ＤＤＩコールを、個々のＵＭＤ／ＫＭＤコンポーネント３４０または３４２；３５０または３５２；および３６０または３６２に転送しうる。これは図６にも図式的に示されている。

ＵＭＤプロキシ３２０，３２２；およびＫＭＤプロキシ３２４によってサポートされるＡＰＩ／ＤＤＩコールの詳細が、実際にはＵＭＤコンポーネント３４０，３４２；３５０，３５２；およびＫＭＤコンポーネント３６０，３６２が実行する、サポートされるＡＰＩ／ＤＤＩコール用の転送ルーチンの詳細を設定したデータ構造を生成することによって、アプリケーションおよびオペレーティングシステムの残りの部分に公開されうる。

ＡＰＩ／ＤＤＩコールは、このような転送関数（またはオブジェクト）によって、ＵＭＤ／ＫＭＤプロキシドライバコンポーネント３２０，３２２，３２４内に転送されうる。ＵＭＤ／ＫＭＤプロキシドライバコンポーネント３２０，３２２，３２４の各転送ルーチンまたはオブジェクトのアドレスが、転送される特定のＡＰＩ関数／コール／オブジェクト／ＩＯＣＴＬに従って、オペレーティングシステムおよび他のアプリケーションに公開されうる。これに対して、各転送ルーチンまたはオブジェクトは、プロキシドライバコンポーネントが代理しているＵＭＤ／ＫＭＤドライバコンポーネントのいずれかにコールを転送する。このようにして、プロキシドライバコンポーネント３２０，３２２，３２４へのＡＰＩ／ＤＤＩコールが、ＵＭＤドライバ３４０，３４２または３５０，３５２またはＫＭＤコンポーネント３６０，３６２内の対応するドライバ関数／コール／オブジェクト／ＩＯＣＴＬに転送されうる。

詳細には、図７に示すように、ブロックＳ７００において、ブロックＳ５０８で対応するエントリポイントが決定されたＵＭＤコンポーネント内の対応する関数／コール／オブジェクト／ＩＯＣＴＬのアドレスに基づいて、単にＵＭＤ／ＫＭＤプロキシドライバコンポーネント３２０、３２２または３２４によって、各ＡＰＩ／ＤＤＩコールが再転送されうる。詳細には、ステップＳ７００が実行されると、ブロックＳ７０２において、ＵＭＤ／ＫＭＤプロキシコンポーネント３２０，３２２またはＫＭＤプロキシコンポーネント３２４は、機能ＡＰＩ／ＤＤＩコールを処理すべきＵＭＤ／ＫＭＤコンポーネント（例えばＵＭＤコンポーネント３４０，３４２；３５０，３５２；またはＫＭＤコンポーネント３６０，３６２）を決定する。例えば、これは、ＡＰＩ／ＤＤＩコールまたは関連するデータを解析して関連するグラフィックサブシステムを特定するか、あるいは単に複数のグラフィックサブシステムのうち、現在使用中のものを特定することによって行うことができる。下で詳細に説明するように、現在使用中のグラフィックサブシステム３０または４０は、デバイス１０の電力消費モードに基づいて決まりうる。現在使用中のサブシステムは、通常は、表示中で、エンドユーザがみているグラフィック／ビデオをレンダリングしている。

関連するドライバが特定されると、ブロックＳ７０６において、ＵＭＤ／ＫＭＤプロキシコンポーネント３２０，３２２またはＫＭＤコンポーネント３２４は、ブロックＳ５０８で作成した一致構造体を参照して、ＡＰＩ／ＤＤＩコールのアドレスを決定する。アドレスが決定されると、関連するＵＭＤ／ＫＭＤコンポーネント３４０または３４２；３５０または３５２；３６０または３６２内のＡＰＩ／ＤＤＩコールが行われうる。次にＵＭＤ／ＫＭＤコンポーネントが、ＡＰＩ／ＤＤＩコールに対応するコードを実行する。

なお、ＵＭＤコンポーネント３４０，３４２または３５０，３５２に対するコールが、別のカーネルモードＡＰＩ／ＤＤＩコールを行ってもよい。この結果、ＫＭＤプロキシコンポーネント３２４に対するＡＰＩ／ＤＤＩコールが行われうる。ＫＭＤプロキシコンポーネント３２４は、ＵＭＤプロキシコンポーネント３２０，３２２と同様に、図７に詳細に示すように、ＤＤＩコールを適切なＫＭＤコンポーネント３６０，３６２に転送する。ＫＭＤプロキシコンポーネント３２４は、ＵＭＤプロキシコンポーネント３２０が行う評価と同じように、すなわち、コールの性質に応じて、あるいは現在アクティブなグラフィックサブシステムに応じて、カーネルモードＡＰＩ／ＤＤＩコールを転送すべきＫＭＤコンポーネント３６０，３６２を決定しうる。

（例えばオブジェクトの作成によって、または関数パラメータによって）データが付帯されるコールの場合、データへのポインタがＵＭＤコンポーネント３４０，３４２，３５０，３５２またはＫＭＤコンポーネント３６０，３６２に渡され、決定されたＵＭＤプロキシコンポーネント３２０，３２２またはＫＭＤプロキシコンポーネント３２４に渡されうる。データをポインタとして渡すことができない場合、対応するデータ構造を介してデータが渡されうる。

一部のＡＰＩ／ＤＤＩコールは、オペレーティングシステムのほかの部分に認識されておらず、初期化時に（例えばＤｌｌＭａｉｎ（）またはＡｄａｐｔｅｒＯｐｅｎ（）の実行時に）、ＵＭＤプロキシドライバコンポーネント３２０，３２２またはＫＭＤプロキシドライバコンポーネント３２４に戻されないことがある。これは、特に、例えば１社の製造業者／供給元によって提供されるＵＭＤコンポーネント３４０，３４２などの相補的なＵＭＤコンポーネントと対話する、ＫＭＤコンポーネント３６０または３６２などのＫＭＤコンポーネントについて当てはまる。ＤＤＩコールがサポートされていても、オペレーティングシステムに公開されているとは限らない。このようなコールは、知られていなければ、通常はＫＭＤプロキシドライバコンポーネント３２４によって転送できない。この事態を回避するために、各ＫＭＤコンポーネント３６０，３６２は、ドライバ初期化ルーチンの実行を受けて、例えば、オペレーティングシステムのスケジューラのコンテキスト切り替えおよびページング要求のために、一般的なオペレーティングシステムの通信に関与する、サポートされる全てのＡＰＩ／ＤＤＩを報告しなければならない。これが可能でない場合、ＫＭＤコンポーネント３６０，３６２は、ＫＭＤプロキシドライバコンポーネント３２４によって要求されうるＡＰＩ／ＤＤＩコールに関する情報を返すクエリルーチンを更に備える。

また、プロキシドライバコンポーネントは、グラフィックサブシステム３０，４０に影響しうる状態変化を確実に追跡できるように、ＡＰＩ／ＤＤＩコールに対して行われたＵＭＤ／ＫＭＤコンポーネントからのコールを受け取る必要がある。

図８は、図２のデバイス１０の一部の別の簡略ブロック図を示し、この図では、図４のソフトウェア２００（より詳細には、ＵＭＤプロキシコンポーネント３２０，３２２とＫＭＤプロキシコンポーネント３２４）が使用されうる。図に示すように、インタフェース回路１６は、中央プロセッサ１２とシステムメモリ１４とを相互接続している。グラフィックサブシステム３０（インタフェース回路１６上でグラフィックプロセッサとして実装）は、グラフィックエンジン３２、メモリコントローラ７２、ディスプレイインタフェース７４およびバスインタフェース７８を備える。

グラフィックエンジン３２は、２Ｄグラフィックまたは３Ｄグラフィックのレンダリング、ビデオのデコードなどが可能な機能ブロックである。理解されるように、グラフィックサブシステム３０は複数のグラフィックエンジンを備えうる。

メモリコントローラ７２は、グラフィックサブシステム３０がグラフィックメモリおよびホストメモリ１４にアクセスできるようにする。図に示した実施形態では、グラフィックサブシステム３０によって使用されるグラフィックメモリは、ホストメモリ１４の一部を構成している。しかし当業者は、グラフィックサブシステム３０が自身のローカルメモリを含むか、または自身のローカルメモリと通信することができることを容易に認めるであろう。バスインタフェース７８はサブシステム３０がバス２０によって通信できるようにする。

理解されるように、ディスプレイインタフェース７４は、ポート７８によって相互接続されたディスプレイデバイス２６に表示するために、バッファ内のデータを変換するためのいずれかの適切なインタフェースであってもよい。例えば、ディスプレイインタフェース７４は、ランダムアクセスメモリディジタルアナログコンバータ（ＲＡＭＤＡＣ）の形態を取ることができる。１つ以上のビデオコネクタが、グラフィックサブシステム３０を、ＬＣＤパネル、モニタ、テレビなどといった１つ以上のディスプレイデバイスと相互接続できるようにする。出力ポート７８は、ＶＧＡポート、コンポジットビデオポート、ＤＶＩポート、ＬＶＤＳポート、ＤＶＯポート、ＳＤＶＯポートなどの形態を取ることができる。

また、グラフィックサブシステム４０（図２の周辺拡張カード４６に形成）は、高速拡張バス２０の拡張スロット経由でインタフェース回路１６に接続されている。グラフィックサブシステム４０は、グラフィックエンジン４２、メモリコントローラ５２、バスインタフェース５８およびディスプレイインタフェース５４を備える。グラフィックサブシステム４０はグラフィックメモリ５０を備えるか、またはグラフィックメモリ５０と通信している。

グラフィックエンジン４２は、グラフィックエンジン３２と同様に、２Ｄグラフィックまたは３Ｄグラフィックのレンダリング、ビデオのデコードなどが可能な機能ブロックである。理解されるように、グラフィックサブシステムは複数のグラフィックエンジンを備えうる。場合によっては、グラフィックエンジン４２はグラフィックエンジン３２によってのみでは提供されない機能を提供することができる。

メモリコントローラ５２は、グラフィックサブシステム４０がメモリ５０およびホストメモリ１４にアクセスできるようにする。バスインタフェース５８はグラフィックサブシステム４０がバス２０によって通信できるようにする。

ディスプレイインタフェース５４は、メモリコントローラ５２経由でグラフィックメモリ５０のフレームバッファをサンプリングしビデオコネクタで画像を提示する。このようにして、外部グラフィックエンジン４２によってメモリ５０のフレームバッファにレンダリングされた画像が表示されうる。ビデオコネクタは、外部ディスプレイに直接、またはビデオ信号が一体型ディスプレイに送られる場合にはデバイス１０のマザーボードに、または外部ディスプレイをデバイス１０に接続するためのコネクタに接続されうる。この場合も、ディスプレイインタフェース５４は、ＲＡＭＤＡＣ、シングルエンドまたはディファレンシャル送信器などといった、ディスプレイデバイス３２に表示するためにバッファ内のデータを変換するための、いずれかの適切なインタフェースであってもよい。

上で説明したように、電力コントローラ６０がグラフィックサブシステム４０と通信しており、ディスプレイインタフェース５４、メモリコントローラ５２、グラフィックエンジン４２、バスインタフェース５８およびグラフィックメモリ５０のうちの１つ以上の各々またはその一部の電力消費を、これらの部品の全部または一部のクロックおよび電圧の調整、電源切断または別様な無効化などの従来の電力消費技術を用いて制御する。電力コントローラ６０は、バス２０上の信号によって、または別様に制御することができ、例えばＡＣＰＩ規格に準拠であってもよい。

グラフィックサブシステム３０はグラフィックサブシステム４０と全く同様に動作する。このように、グラフィックサブシステム３０は、メモリコントローラ７２を使用して、ホストメモリ１４またはグラフィックサブシステム３０のローカルなメモリに保持されているフレームバッファにアクセスする。このフレームバッファはディスプレイインタフェース７４によってサンプリングされ、画像が、ディスプレイに直接接続されうるビデオ出力コネクタに提示される。経済的な一体型部品を提供するために、グラフィックサブシステム３０は機能が限定されている。例えば、グラフィックサブシステム３０の解像度、メモリ、グラフィックプロセッサ速度、３Ｄグラフィック能力などが比較的制限されていてもよく、グラフィックサブシステム４０の外部グラフィックプロセッサ４２よりも低速に動作してもよい。

三次元グラフィック、ゲームグラフィックなどといった演算処理の多いグラフィックは、グラフィックサブシステム４０によって、より効果的に実行される。したがって、デバイス１０内部のアドオングラフィックサブシステム４０を使用することで、ゲーム、コンピュータ支援設計ソフトウェア、アニメーションソフトウェア、レンダリングソフトウェアなどといったグラフィック集約的アプリケーションの最新機能をエンドユーザが体感できるようになる。アドオングラフィックサブシステム４０は、エンドユーザによって選択され、必要に応じて交換されて、最新のものを使用することができ、利便性が高い。従来は、追加のグラフィック計算能力は、ワークステーション演算装置でしか利用できなかった。モバイルコンピューティングデバイスの拡張スロットの登場により、今では、このような計算能力がラップトップなどのポータブルコンピューティングデバイスの所有者も利用できるようになっている。当然、グラフィックサブシステム４０で高性能の（または異なる性能の）グラフィックエンジン４２を使用すると、デバイス１０全体の電力消費が増大する。この増大した電力消費は、バッテリ電源によって給電されるコンピューティングデバイスでは支えきれないこともある。

同時に、グラフィックエンジン４２を備えたアドオングラフィックサブシステム４０が存在する場合に、グラフィックサブシステム３０は冗長となりうる。例えば、複数台の物理的ディスプレイがデバイス１０に接続されていない場合、グラフィックサブシステム３０は役割を果たさないこともある。このため、グラフィックサブシステム３０は無効にされうる。一方、グラフィックサブシステム３０の動作を制御する電力コントローラ７０が存在する場合、グラフィックサブシステム３０は、非使用中時に低電力モードに設定されうる。この場合も、電力コントローラ７０は、グラフィックサブシステム３０の一部を無効にするかまたは切断するか、またはグラフィックサブシステム３０の一部のクロックまたは電圧を調整しうる。

本発明の実施形態の例示的なソフトウェア２００（図４）は、サブシステム３０が存在する場合に、デバイス１０が一方の高電力グラフィックサブシステム４０を選択的に無効化できるようにする働きをする。

このため、図８に図に示すように、コンピューティングデバイス１０はスイッチ５６を更に備える。スイッチ５６はサブシステム４０およびサブシステム３０によって生成されたビデオ信号を第１の入力と第２の入力とで受信する。スイッチ５６は、マルチプレクサなどのいずれかの適切なビデオスイッチでもよく、その２つの信号入力の従来のビデオ信号の一方を、そのビデオ出力コネクタに提示するように動作可能である。スイッチ５６の入力に提示されるビデオ信号は、（ＬＶＤＳまたはＴＭＤＳフォーマットなどの）ディジタル信号または（ＶＧＡフォーマットなどの）アナログ信号などの従来のビデオ信号であってもよい。スイッチ５６がディジタル入力信号とアナログ入力信号の両方を受信するか、またはどちらか一方の出力でビデオを供給するように構成されている場合、スイッチ５６はフォーマットコンバータを含み得る。また、スイッチ５６は、ディジタルまたはアナログディスプレイデバイス３２の一方または両方を接続できるようにするために１つ以上のビデオ出力を備えうる。

スイッチ５６は制御入力（ＣＮＴＲＬ）を更に含む。この制御入力は、スイッチ５６のビデオ出力にいずれの信号入力が供給されるかを制御する。図に示した実施形態では、制御入力は、デバイス１０の電力モードの変更が必要であるか、またはこれが望ましいことを検出または決定すると、汎用入出力（ＧＰＩＯ）インタフェース（図示せず）経由で、プロセッサ１２によって切り替えられる。明らかとなるように、スイッチ５６は、デバイス１０が低電力消費モードで動作している場合には、グラフィックサブシステム３０によって生成された従来のビデオ信号が選択されるように構成されている。逆に言えば、デバイス１０が高電力消費モードで動作している場合、高性能の外部グラフィックサブシステム４０によって生成されたビデオ信号が表示用に選択される。同様に、グラフィックサブシステム４０またはグラフィックサブシステム３０に供給される電力が低減されるか、または無効にされうる。この切り替えは、コンピューティングデバイス１０の使用中に、デバイス１０に再始動（すなわちコールドスタートまたはウォームスタート）を要求とせずに、動的に行なうことができる。

これを行うために、コンピューティングデバイス１０は、上述した少なくとも１つの電力コントローラ６０も備えうる。図に示した実施形態では、電力コントローラ６０は、グラフィックサブシステム４０を搭載している周辺拡張カード４６の一部を形成する。しかし電力コントローラ６０が、コンピューティングデバイス１０のマザーボードの一部として、またはインタフェース１６の一部として形成されてもよい。電力コントローラ６０は、拡張カード４６の一部を形成する場合、サブシステム４０の動作をより柔軟に制御することができる。電力コントローラ６０がコンピューティングデバイス１０の一部を形成する場合、グラフィックサブシステム４０への電力を無効にする能力しか有さないこともある。

システムメモリ１２内部のソフトウェア２００は、スイッチ５６および電力コントローラ６０を構成し制御するために使用される。このため、図９は、本発明の実施形態の例示において、２つの利用可能な電力消費モード間でデバイス１０を切り替えるための例示的なソフトウェアブロックＳ９００を例示するフローチャートである。

ここで、本発明の実施形態の例示では、デバイス１０が最初に電源投入された時に、デバイス１０の電力状態が評価される。電力制御アプリケーション２０１は、必要に応じて、以下に詳述するように、グラフィックサブシステム３０および４０ならびにスイッチ５６を構成する。

本発明の実施形態の例示的なソフトウェアブロックＳ９００は、システムメモリ１０内部の電力制御アプリケーション２０１の制御下でプロセッサ１２によって実行されうる。ブロックＳ１１００はデバイス１０が状態変化を受けるたびに実行され、これに対して、サブシステム３０，４０を相応に構成する必要がある。図に示すように、ブロックＳ９０２において、電力制御アプリケーション２０１は、デバイス１０が高電力消費モードまたは低電力消費モードのいずれを取るべきかを判定する。

アプリケーション２０１（図４）は、固有のグラフィック電力状態に対して、いずれのグラフィックサブシステム３０，４０が好適なデバイスであるかを示すテーブルを保持しうる。各ユーザ電力状態は、グラフィックサブシステム３０，４０と、そのサブシステムの対応する状態にマップされる。個々のグラフィックサブシステム３０，４０の電力状態とは、現在アクティブなグラフィックサブシステム３０または４０のクロック速度、メモリ速度、ピクセルクロック速度、レンダリング性能などの動作パラメータなどである。

例示の実施形態では、デバイス１０がＡＣ電源３６から動作している場合は、高電力消費モードが使用され、デバイス１０がＤＣ電源３８経由で動作している場合、ＤＣ電源３８が低い場合などは、低電力消費モードが使用されうる。高電力消費モードでは、グラフィックサブシステム４０がアクティブである。低電力消費モードでは、グラフィックサブシステム３０がアクティブである。

デバイス１０が高電力消費モードを再開（またはこれに移行）すべき場合、ブロックＳ９０４〜Ｓ９１０が実行される。ブロックＳ９０４において、サブシステム４０は、まだフル動作（高電力消費）モードに設定されていなければ、高電力消費モードに設定される。これは、適したドライバコールによって、プロセッサ１２によって、電力コントローラ６０に適切な信号を供給することにより実行することができる（ＡＭＤまたはＡＴＩグラフィックサブシステムでは、従来のＡＴＰＸ ＡＣＰＩメソッドが使用され、他の製造業者のグラフィックサブシステムでは、同様のメソッドまたは関数が使用されうる）。次に、ブロックＳ９０６において、サブシステム４０が有効にされる。これは、構成マネージャのＷｉｎｄｏｗｓ ＰｎＰコールを使用してサブシステム４０を有効にすることによって行うことができる。このサブシステムが有効にされたら、オペレーティングシステムは新しいデバイス名を得るために、すべてのデバイスを列挙しうる。このために、ＷｉｎｄｏｗｓのＥｎｕｍＤｉｓｐｌａｙＤｅｖｉｃｅｓ（）ＡＰＩ関数が使用されうる。その後、ＷｉｎｄｏｗｓのＣｈａｎｇｅＤｉｓｐｌａｙＳｅｔｔｉｎｇｓＥＸ（）ＡＰＩコールを使用して、２台のデバイスを有する拡張デスクトップが作成されうる。ここで、アプリケーション２０１は、（例えば、ＷＭ＿ＤＩＳＰＬＡＹＭＯＤＥＣＨＡＮＧＥメッセージを受け取ることによって）アダプタが変更されていることを検知しうる。アプリケーション２１０は再起動コマンドを発行しうる。ブロックＳ９０６において、ＣＷＤＤＥＤＩ（ＡＴＩ／ＡＭＤグラフィックサブシステム用のドライバ用の関数）を使用するか、あるいは他の製造業者のグラフィックサブシステムのドライバでは同様の関数を使用して、ディスプレイが電源切断され、制御メソッドコールを使用して一体型Ｉ^２Ｃコントローラを無効にして、Ｉ^２Ｃバッファを無効にする。Ｓ９０８ブロックにおいて、例えば、ＡＴＩ／ＡＭＤグラフィックサブシステムの場合はＡＴＰＸ ＡＣＰＩメソッドを使用するか、あるいは他の製造業者のグラフィックサブシステム用のドライバの場合は同様の関数を使用して、グラフィックサブシステム４０からの出力を選択するように、スイッチ５６が構成されうる。ブロックＳ９１０において、新たに有効にされたグラフィックサブシステム４０が論理的に有効にされ、オペレーティングシステムのほかの部分から認識可能となる。これは、ＷｉｎｄｏｗｓのＣｈａｎｇｅＤｉｓｐｌａｙＳｅｔｔｉｎｇｓＥＸ（）ＡＰＩコールを使用して行うことができる。同様に、グラフィックサブシステム３０を、表示されているデスクトップから取り外すことによって、このサブシステムが論理的に無効にされうる。これは、ＷｉｎｄｏｗｓのＣｈａｎｇｅＤｉｓｐｌａｙＳｅｔｔｉｎｇｓＥＸ（）ＡＰＩコールを使用して行うことができる。オペレーティングシステムによって問い合せが行われたときに、一体型ディスプレイを隠すために、別のプライベートＡＰＩ（エスケープ）コールがドライバ対してに行われてもよく、無効にされたグラフィックサブシステムを隠すことができる。

説明したように、Ｖｉｓｔａでは、１つのグラフィックＫＭＤのみがアクティブとなる。通常は２つの異なるデバイスドライバによって制御される２つのグラフィックサブシステム３０，４０をサポートするために、ＫＭＤプロキシコンポーネント３２４が、２つのグラフィックサブシステム３０，４０のカーネルモードドライバとして動作する。同様に、ＵＭＤプロキシコンポーネント３２０，３２２は、１つのＵＭＤとして動作する。

デバイス１０が低電力消費モードに移行するか、このモードを再開した場合、ブロックＳ９１２〜Ｓ９１８が実行される。大まかに言って、グラフィックサブシステム４０が無効にされ低電力消費モードに設定される一方、グラフィックサブシステム３０が有効にされる。このために、ブロックＳ９１２，Ｓ９１４において、グラフィックサブシステム３０が有効にされる。この場合も、このことは、ブロックＳ８０４において、グラフィックサブシステム３０’に関連する、相互接続されたディスプレイを論理的に無効にし、ブロックＳ８０８において、グラフィックサブシステム４０’と接続されたディスプレイを論理的に有効にすることによって実行することができる。ブロックＳ９１２およびＳ９１４は、上記のＥｎｕｍＤｉｓｐｌａｙＤｅｖｉｃｅｓ（）コールおよびＣｈａｎｇｅＤｉｓｐｌａｙＳｅｔｔｉｎｇｓＥＸ（）コールなどの適切なオペレーティングシステムＡＰＩコールによってか、またはハードウェアとの直接通信によって実行することができる。

ディスプレイが論理的に無効にされた後、ブロックＳ９１８において、ＫＭＤコンポーネント３６０，３６２へのＡＰＩ呼出しが使用され、グラフィックサブシステムが低電力モードに物理的に設定されうる。このために、プロセッサ１２は電力コントローラ６０に適切な信号を供給し、グラフィックサブシステム４０を低電力状態に設定する。最も単純な形態では、電力コントローラ６０がグラフィックサブシステム４０への電力を遮断するか、またはグラフィックサブシステム４０を低電力スリープモードに設定する。一方、電力制御アプリケーション２０１は、グラフィックサブシステム４０をＡＣＰＩ仕様によって規定されるデバイス電力状態の１つなどの低電力スリープモードに設定するように、電力コントローラ６０に指示しうる。いずれにせよ、この低電力消費モードでは、電圧が抑えられるか、グラフィックサブシステム４０の全部または一部が電源切断されるか、グラフィックサブシステム４０が使用する選択されたクロックが減速されるか、この組み合わせが行われる。

グラフィックサブシステム３０，４０の特定の１つが、論理的および物理的に有効にされると、ＵＭＤプロキシコンポーネント３２０，３２２；およびＫＭＤプロキシコンポーネント３２４に、現在アクティブなサブシステムの指標が提供され、グラフィックサブシステムに対するＡＰＩ／ＤＤＩコールが、前述のように現在有効なグラフィックサブシステム３０，４０に対応して、適宜ＵＭＤ／ＫＭＤコンポーネント３４０，３５０，３６０または３４２，３５２，３６２に転送される。

スイッチ５６が適切に設定されることを保証するために、デバイス１０用のＢＩＯＳは、ユーザが、起動時にアクティブにすべきデバイスを選択できるようにしる。

スイッチ５６ならびにグラフィックサブシステム４０およびグラフィックサブシステム３０を上で説明したように構成することにより、電力消費を低減し、デバイス１０に２つのグラフィックプロセッサの一方のみに必要な電力を消費させ、これによって全体的なエネルギー消費を低減し、バッテリ寿命を温存でき、有利である。例えば、ポータブルコンピューティングデバイスは、通常、出張者によりバッテリ動作モード（ＤＣ電力）で使用される。このようなユーザの出張中の典型的な使用パターンは、文書処理、プレゼンテーションおよび電子メールアプリケーションなどであると考えられる。これらのアプリケーションは、外部グラフィックサブシステム４０によって提供される高負荷のグラフィックの高速化を必要としない。第２の（例えば外部）グラフィックサブシステム４０の使用から、平均電力消費の低い第１の（例えば一体型）グラフィックサブシステム３０の使用へ移行することにより、システム全体の性能を犠牲にすることなく、高性能のグラフィック処理と低電力消費との間でバランスを取ることができるようになる。

図９は、本発明の別の実施形態の代表的なコンピューティングデバイス１０’の一部の例の代表的な簡略ブロック図である。コンピューティングデバイス１０’はコンピューティングデバイス１０とほぼ同様である。したがって、デバイス１０の部品と機能的に同等のデバイス１０’の部品はプライム記号（’）を付しており、詳細には説明しない。しかし簡単に説明すると、デバイス１０’は２つのグラフィックサブシステム３０’，４０’を備える。この場合も、グラフィックサブシステム３０’は、グラフィックエンジン３２’、メモリコントローラ７２’、ディスプレイインタフェース７４’およびバスインタフェース７８’を備える。第２のグラフィックサブシステム４０’は、高速バス２０’経由でグラフィックサブシステム３０’と通信している。グラフィックサブシステム４０’は、自身のグラフィックエンジン４２’、メモリコントローラ５２’、ディスプレイインタフェース５４’を備える。グラフィックサブシステム４０’は更にグラフィックメモリ５０’と通信している。特に言えば、デバイス１０’は、グラフィックサブシステム３０’およびグラフィックサブシステム４０’のいずれがディスプレイ２６’に相互接続されるかを制御するために使用されるスイッチを含まない。この代わりに、明らかとなるように、サブシステム４０’は、バス２０’を介してメモリ１４’にグラフィックをレンダリングするように適合されている。

デバイス１０’の動作を制御するソフトウェアの構成はデバイス１０と同様である。しかし、デバイス１０’が高低電力消費と低電力消費状態間で移行する際にデバイス１０’の動作を制御するソフトウェアの一部は、デバイス１０のものとは異なる。

詳細には、図１１は、デバイス１０’のシステムメモリ内部のソフトウェアの制御下でプロセッサ１２’によって実行されうる本発明の実施形態の例示的なソフトウェアブロックＳ１１００’を示す。この場合も、ブロックＳ１１００はデバイス１０’が状態変化を受けるたびに実行され、これに対して、サブシステム３０’，４０’を相応に構成する必要がある。図に示すように、ブロックＳ１１０２において、ソフトウェアは、デバイス１０’が高電力消費モードまたは低電力消費モードのいずれを取るべきかを判定する。

デバイス１０’が高電力消費モードを再開（またはこれに移行）すべき場合、ブロックＳ１１０４〜Ｓ１１１０が実行される。ブロックＳ１１０４において、グラフィックサブシステム４０’は、まだフル動作（高電力消費）モードに設定されていなければ、高電力消費モードに設定される。このことは、グラフィックサブシステム４０’を制御するドライバを介して、電力コントローラ６０’に適切な信号を供給することによって実行することができる。次に、ブロックＳ１１０６，Ｓ１１０８において、グラフィックサブシステム４０’が有効にされる。この場合も、このことは、ブロックＳ１８０４において、グラフィックサブシステム３０’に関連する、相互接続されたディスプレイを論理的に無効にし、ブロックＳ１１０８において、グラフィックサブシステム４０’と接続されたディスプレイを論理的に有効にすることによって実行することができる。この場合も、ブロックＳ１１０６，Ｓ１１０８は、上記のＥｎｕｍＤｉｓｐｌａｙＤｅｖｉｃｅｓ（）コールおよびＣｈａｎｇｅＤｉｓｐｌａｙＳｅｔｔｉｎｇｓＥＸ（）コールなどの適切なオペレーティングシステムＡＰＩコールによってか、またはハードウェアとの直接通信によって実行することができる。

特に言えば、グラフィックサブシステム４０’に接続されている物理的ディスプレイは存在しない。（デバイス１０（図４）の）スイッチ５６がない場合、グラフィックサブシステム４０’の動作を制御しているドライバソフトウェアは、ステップＳ１１１０において、関連するメモリ５０’内部の代わりに、グラフィックサブシステム３０’のバッファ１４’に画像をレンダリングするように構成される。（例えば、ＰＣＩｅバスとして実装された）高速バス２２が存在している場合、このようなレンダリングが、一部には、このバスによって実現される転送速度のおかげで、バス２２’を介して可能となり、利便性が高い。

同様に、グラフィックサブシステム３０’用のドライバは更に、グラフィックサブシステム４０’によってメモリ１４’内のフレームバッファにレンダリングされた画像を、相互接続されたディスプレイ２６’で提示するために、グラフィックサブシステム３０’のディスプレイインタフェース７４’に、メモリ１４’のフレームバッファをサンプリングさせるように構成されている。同時に、グラフィックサブシステム３０’のドライバは、グラフィックサブシステム３０’のグラフィックエンジン３２’に対し、実質的に活動停止状態またはアイドル状態に留まるように指示することができる。この動作モードは、図１２Ａに模式的に示されており、グラフィックサブシステム４０’およびグラフィックサブシステム３０’のアクティブなブロックのみが網掛けされている。

明らかとなるように、図１２Ａの実施形態では、メモリ５０’とディスプレイインタフェース５４’は使用されていない。このため、これらの機能ブロックはサブシステム４０’から削除することができ、コスト低減が可能となる。このようなグラフィックサブシステムを作成することは、サブシステム３０’によって提供される機能をサブシステム４０’が補完するように作成されうるため、有益であろう。例えば、サブシステムは、３Ｄグラフィックまたはビデオのデコーディング機能を提供するグラフィックエンジン４２’を提供してもよい。グラフィックエンジン３２’はこれらの機能を搭載していなくてもよい。同時に、グラフィックエンジン３２’によって提供される２Ｄグラフィック機能を、サブシステム４０’に搭載する必要はない。消費者は、追加の機能が必要な場合にのみグラフィックサブシステム３０’を追加してもよい。

デバイス１０’が低電力消費モードに移行するか、このモードを再開した場合、ブロックＳ１１１２〜Ｓ１１１８が実行される。概説すると、グラフィックサブシステム４０’は、部分的または完全に無効にされて低電力消費モードに設定され、この場合も、レンダリングがグラフィックサブシステム３０’によって実行される。これを行うため、ブロックＳ９１２’において、グラフィックサブシステム３０’に関連する、相互接続されたディスプレイが有効にされ、ブロックＳ１１１４において、グラフィックサブシステム４０’と物理的に接続されたあらゆるディスプレイが論理的に無効にされる。次に、グラフィックサブシステム３０’の動作を制御するドライバソフトウェアが、グラフィックサブシステム３０’にメモリ１４’に画像をレンダリングさせるように再度構成される。ディスプレイインタフェース７４’は、ポート７８’と相互接続されたディスプレイ２６’で画像を提示するために、メモリ１４’をサンプリングし続ける。同様に、ブロックＳ８１８において、プロセッサ１２’は最初に電力コントローラ６０’に適切な信号を供給し、グラフィックサブシステム４０’を低電力状態に設定する。最も単純な形態では、電力コントローラ（図示なし）がグラフィックサブシステム４０’への電力を遮断するか、またはグラフィックサブシステム４０’を低電力スリープモードに設定する。この場合も、この低電力消費モードでは、電圧が抑えられるか、グラフィックサブシステム４０’の全部または一部が電源切断されるか、グラフィックサブシステム４０’が使用する選択されたクロックが減速されるか、この組み合わせが行われる。詳細には、グラフィックサブシステムのグラフィックエンジン４２’が、アイドル状態に留まるか、または実質的にアイドル状態に留まる（例えば低速化されるか、無効にされるか、または電源切断される）。この動作モードは、図１２Ｂに模式的に示されており、アダプタ４０’とグラフィックサブシステム３０’のアクティブな機能ブロックのみが網掛けされている。非作動状態／アイドル状態の機能ブロックは、完全に無効化されるか、または低電圧または低クロック速度で動作される。

任意選択で、グラフィックサブシステム３０’の一部が、グラフィックエンジン３２’の不使用時に無効にされてもよい。このことは、グラフィックサブシステム４０’が画像のレンダリングを担っている任意の時に、ＧＰＩＯまたは類似の回路によって無効にできる１つ以上のボルテージアイランド（voltage island）に、グラフィックエンジン３２’および他の部品を配置することによって容易に行うことができる。

他の変更例もまた明白であろう。例えば、図１２Ａに示す高電力モードにおいて、グラフィックサブシステム３０とグラフィックサブシステム４０’の両方が、メモリ１４またはメモリ５０’にレンダリングしてもよい。このようにして、２つのグラフィックサブシステム３０’，４０’が、それぞれメモリ１４’の交番フレームにレンダリングするか、またはメモリ１４’の各フレームの一部にレンダリングして、協調して動作することができる。

更に別の実施形態では、上で説明したように、追加ディスプレイをグラフィックサブシステム３０’，４０’に接続して、高電力消費モードでの複数台のディスプレイの同時使用を可能にすることができる。このようにして、ディスプレイインタフェース５４を、第２のディスプレイを駆動するために使用することができる。デバイス１０’を、低電力消費モードへの移行時に、図９Ｂに示すように動作するように構成してもよい。

同様に、デバイス１０’（または１０）は、バス２０’（または２０）に接続された複数の追加のグラフィックサブシステムを有してもよく、高電力消費モードにおいては、そのすべてがアクティブとなり、グラフィックサブシステム３０’のディスプレイインタフェース７４’を介してグラフィックをレンダリングしてもよい。低電力消費モードへの移行時に、このグラフィックサブシステムが無効化され、グラフィックサブシステム３０’のグラフィックエンジン３２’にレンダリングが任せられうる。

図１３に示す更に別の実施形態では、コンピューティングデバイス１０はダイレクトメモリアクセス（ＤＭＡ）コントローラ９０を備えてもよい。ＤＭＡコントローラ９０はデータをメモリ５０’からメモリ１４’に転送することができる。このように、デバイス１０’の高電力消費モードにおいて、グラフィックサブシステム４０’は画像をメモリ５０’にレンダリングしうる。レンダリングされたこれらの画像はその後、ＤＭＡコントローラ９０によってメモリ１４’内のフレームバッファに転送されうる。ＤＭＡコントローラ９０’は、（例えばグラフィックエンジン３２’または４２’のＤＭＡエンジンとして）グラフィックサブシステム３０’または４０’の一部を構成するか、またはコンピューティングデバイス１０’内に別の方法で配置されうる。データは、メモリ５０’からメモリ１４’に、バス２０’を介して転送されるか、または別の方法で直接転送されうる。ディスプレイインタフェース７４’は、上述のように動作を続け、レンダリングされた画像をディスプレイ２６’で提示するためにメモリ１４’のフレームバッファをサンプリングする。この場合も、高電力消費モードにある図１０のデバイス１３’のアクティブなブロックが、図１３で網掛けして図示されている。

当然、上記の実施形態は、例示のみを目的としており、限定を意図するものではない。本発明を実施する記載した実施形態は、形状、部品の配置、操作の詳細および順序がさまざまに変更される。むしろ、本発明は、請求の範囲によって規定される範囲に、このような変更のすべてを含むことを意図する。

Claims (15)

1. 電子デバイスであって、
   グラフィックをレンダリングするように動作可能な第１のグラフィックサブシステムと、
   グラフィックをレンダリングするように動作可能な第２のグラフィックサブシステムと、
   前記第１のグラフィックサブシステムおよび前記第２のグラフィックサブシステムの少なくとも一方と通信している少なくとも１台のディスプレイと、
   オペレーティングシステムソフトウェア、アプリケーションソフトウェアおよびドライバソフトウェアを実行するプロセッサとを備え、前記ドライバソフトウェアは、前記第１のグラフィックサブシステムの動作を制御するための第１のドライバコンポーネントと、前記第２のグラフィックサブシステムの動作を制御するための第２のドライバコンポーネントと、前記第１のグラフィックサブシステムおよび前記第２のグラフィックサブシステムのうちアクティブなグラフィックサブシステムと前記オペレーティングシステムおよび前記アプリケーションソフトウェアとをインターフェースで接続するために、前記オペレーティングシステムソフトウェアには１つのドライバとして見えるプロキシドライバコンポーネントであって、前記第１のグラフィックシステムおよび前記第２のグラフィックシステムのいずれが使用中であるかに応じて、前記アプリケーションから、前記第１のドライバコンポーネントおよび前記第２のドライバコンポーネントのいずれかにコールを転送するプロキシドライバコンポーネントとを有する、電子デバイス。
2. 前記プロセッサは、前記プロセッサに、前記第２のグラフィックサブシステムが前記ディスプレイにグラフィックをレンダリングする第１のモードから、前記第１のグラフィックサブシステムが前記ディスプレイにグラフィックをレンダリングするとともに、前記第２のグラフィックサブシステムが低電力消費モードに設定される第２のモードに前記電子デバイスを移行させる命令を実行させる、請求項１に記載の電子デバイス。
3. 前記第１のドライバコンポーネントおよび前記第２のドライバコンポーネントは前記プロセッサのユーザモードで実行しているドライバコンポーネントを含む、請求項１に記載の電子デバイス。
4. 前記第１のドライバコンポーネントおよび前記第２のドライバコンポーネントは前記プロセッサのカーネルモードで実行しているドライバコンポーネントを含む、請求項１に記載の電子デバイス。
5. 前記第１のグラフィックシステムおよび第２のグラフィックシステムのうちいずれが使用中であるかは前記電子デバイスの電力状態に依存する、請求項１に記載の電子デバイス。
6. 前記プロキシドライバコンポーネントは、前記第１のグラフィックシステおよび前記第２のグラフィックシステムのいずれが使用中であるかに応じて、前記デバイスのオペレーティングシステムから、前記第１のドライバコンポーネントまたは前記第２のドライバコンポーネントのいずれかにコールを転送する、請求項１に記載の電子デバイス。
7. 前記プロキシドライバコンポーネントは、前記転送を実行するために、前記第１のドライバコンポーネントおよび前記第２のドライバコンポーネント内の同等のドライバ関数を識別するデータ構造を作成する、請求項１に記載の電子デバイス。
8. 電子デバイスであって、
   グラフィックをレンダリングするように動作可能な第１のグラフィックサブシステムと、
   グラフィックをレンダリングするように動作可能な第２のグラフィックサブシステムと、
   前記第１のグラフィックサブシステムおよび前記第２のグラフィックサブシステムの両方と通信しているディスプレイと、
   オペレーティングシステムソフトウェア、アプリケーションソフトウェアおよびドライバソフトウェアを実行するプロセッサとを備え、前記ドライバソフトウェアは、
   前記第１のグラフィックサブシステムの動作を制御するための第１のユーザモードドライバコンポーネントと、前記第２のグラフィックサブシステムの動作を制御するための第２のユーザモードドライバコンポーネントと、前記第１のグラフィックサブシステムおよび前記第２のグラフィックサブシステムのうちアクティブなグラフィックサブシステムと前記オペレーティングシステムおよび前記アプリケーションソフトウェアとをインターフェースで接続するために、前記オペレーティングシステムソフトウェアには１つのユーザモードドライバコンポーネントとして見えるユーザモードプロキシドライバコンポーネントであって、前記第１のグラフィックシステムおよび前記第２のグラフィックシステムのいずれが使用中であるかに応じて、前記アプリケーションから、前記第１のユーザモードドライバコンポーネントおよび前記第２のユーザモードドライバコンポーネントのいずれかにコールを転送するユーザモードプロキシドライバコンポーネントと、
   前記第１のグラフィックサブシステムの動作を制御するための第１のカーネルモードドライバコンポーネントと、前記第２のグラフィックサブシステムの動作を制御するための第２のカーネルモードドライバコンポーネントと、前記第１のグラフィックサブシステムおよび前記第２のグラフィックサブシステムのうちアクティブなグラフィックサブシステムと前記オペレーティングシステムおよび前記アプリケーションソフトウェアとをインターフェースで接続するために、前記オペレーティングシステムソフトウェアには１つのカーネルモードドライバコンポーネントとして見えるカーネルモードプロキシドライバコンポーネントであって、前記第１のグラフィックシステムおよび第２のグラフィックシステムのいずれかが使用されているかに応じて、前記ユーザモードドライバコンポーネントのいずれかから、前記第１のカーネルドライバコンポーネントおよび前記第２のカーネルドライバコンポーネントのいずれかにコールを転送するためのカーネルモードプロキシドライバコンポーネントとを含む、電子デバイス。
9. グラフィックをレンダリングするように動作可能な第１のグラフィックサブシステムと、グラフィックをレンダリングするように動作可能な第２のグラフィックサブシステムと、前記第１のグラフィックサブシステムおよび前記第２のグラフィックサブシステムの両方と通信しているディスプレイと、プロセッサとを備えるコンピュータ装置で実行するためのドライバソフトウェアを記憶している計算機可読媒体であって、前記ドライバソフトウェアは、
   前記第１のグラフィックサブシステムおよび前記第２のグラフィックサブシステムのうちアクティブなグラフィックサブシステムと前記コンピュータ装置のオペレーティングシステムおよび前記コンピュータ装置のアプリケーションソフトウェアとをインターフェースで接続するために、前記オペレーティングシステムには１つのドライバコンポーネントとして見えるプロキシドライバコンポーネントであって、前記第１のグラフィックシステムおよび第２のグラフィックシステムのいずれかが使用されているかに応じて、前記アプリケーションソフトウェアから、前記第１のグラフィックサブシステムの動作を制御する第１のドライバコンポーネントまたは前記第２のグラフィックサブシステムの動作を制御する第２のドライバコンポーネントのいずれかにコールを転送するためのプロキシドライバコンポーネントを含む、計算機可読媒体。
10. 前記プロキシドライバコンポーネントは、前記転送を実行するために、前記第１のドライバコンポーネントおよび前記第２のドライバコンポーネント内の同等のドライバ関数を識別するデータ構造を作成する、請求項９に記載の計算機可読媒体。
11. 前記プロキシドライバコンポーネントは、前記第１のグラフィックシステおよび前記第２のグラフィックシステムのいずれが使用中であるかに応じて、前記デバイスのオペレーティングシステムから、前記第１のドライバコンポーネントまたは前記第２のドライバコンポーネントのいずれかにコールを転送する、請求項１０に記載の計算機可読媒体。
12. 前記第１のドライバコンポーネントおよび前記第２のドライバコンポーネントは前記プロセッサのユーザモードで実行しているドライバコンポーネントを含む、請求項９に記載の計算機可読媒体。
13. 前記第１のドライバコンポーネントおよび前記第２のドライバコンポーネントは前記プロセッサのカーネルモードで実行しているドライバコンポーネントを含む、請求項９に記載の計算機可読媒体。
14. グラフィックをレンダリングするように動作可能な第１のグラフィックサブシステムと第２のグラフィックサブシステムとを備える電子デバイスを動作させる方法であって、
    前記第１のグラフィックサブシステムおよび前記第２のグラフィックサブシステムのうちアクティブなグラフィックサブシステムとインターフェースで接続するために、オペレーティングシステムには１つのドライバコンポーネントとして見えるプロキシドライバコンポーネントにおいて、前記電子デバイスで実行しているソフトウェアアプリケーションまたは前記オペレーティングシステムからドライバコールを受け取るステップと、
    前記第１のグラフィックシステムおよび前記第２のグラフィックシステムのいずれが使用中であるかに応じて、ソフトウェアアプリケーションから、前記第１のグラフィックサブシステムの動作を制御する第１のソフトウェアドライバコンポーネントまたは前記第２のグラフィックサブシステムの動作を制御する第２のソフトウェアドライバコンポーネントのいずれかに前記ドライバコールを転送するために、前記プロキシドライバコンポーネントを実行するステップとを含む、方法。
15. 前記転送を実行するために前記第１のドライバコンポーネントおよび前記第２のドライバコンポーネント内の同等のドライバ関数を識別するデータ構造を作成するステップを更に含む、請求項１４に記載の方法。

Images