JP2014500535A - Ｇｐｕ利用可能仮想マシンの負荷分散技法 - Google Patents

Abstract

仮想マシンの間で３Ｄグラフィック演算装置の利用を調整するための例示的な技法が明細書において開示されている。例示的な実施形態では、仮想化プラットフォームが、仮想マシンに対してグラフィック描画モジュールのインスタンスをロードし、当該グラフィック描画モジュールを実行するためのＧＰＵを選択し、選択したＧＰＵに対して描画するように当該仮想マシンを構成することができる。上記に加えて、他の態様が発明を実施するための形態、特許請求の範囲、および図面に記載されている。

Description

本発明は、ＧＰＵ利用可能仮想マシンの負荷分散技法に関する。

仮想マシン・プラットフォームにより、各オペレーティング・システムをそれ自身の仮想マシン内部で実行することで、物理マシン上の複数のゲスト・オペレーティング・システムを同時に実行することができる。仮想マシン・プラットフォームにより提供できる１つの例示的なサービスは、仮想デスクトップ・セッションである。仮想デスクトップ・セッションは、基本的には、リモート・コンピュータに送信された自己のユーザ・インタフェースを有する、仮想マシン内部で実行されるパーソナル・コンピュータ環境である。本アーキテクチャはリモート・デスクトップ環境に似ているが、複数のユーザを同時にサーバ・クラスのオペレーティング・システムに接続させるのではなく、仮想デスクトップ・セッションにおいて各ユーザに対し、仮想マシンで実行されている各ユーザの汎用的なオペレーティング・システムへのアクセス権を付与する。

現代のオペレーティング・システムは、三次元（３Ｄ）アプリケーション／ビデオゲーム向けの３Ｄグラフィカル・ユーザ・インタフェースおよびそのオペレーティング・システム・ユーザ・インタフェースを描画する。ユーザは、３Ｄ環境との対話体験を楽しむので、３Ｄグラフィックを仮想デスクトップ・セッションでクライアントにストリーミング可能にすることが望ましいはずである。しかし、３Ｄグラフィックのストリーミングを可能とするのは多くの理由から困難である。例えば、３Ｄグラフィックをストリーミングする動作には、帯域幅および／または圧縮が必要である。さらに、仮想デスクトップ・サーバが、３Ｄ ＧＰＵ（ｇｒａｐｈｉｃ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ）を備える必要があるはずである。当該３Ｄ ＧＰＵは、３Ｄ機能を実施することができる。３Ｄグラフィック処理はリソース集約的であり、ＧＰＵは一般に数個の３Ｄグラフィック・ユーザ・インタフェースを一度に描画できるにすぎない。これらのＧＰＵは、あまりに多くのグラフィック・ユーザ・インタフェースを描画する必要がある場合、すぐに過負荷となるおそれがある。残念なことに、仮想デスクトップを配備する際は、ＧＰＵが多数の３Ｄグラフィック・ユーザ・インタフェースを同時に描画しなければならないことがある。これにより、１つまたは複数の操作がタイムアウトするおそれがあり、次いでグラフィック・ドライバがグラフィック演算装置をリセットし、それが３Ｄアプリケーションの停止の原因となる。したがって、ＧＰＵが過負荷となりクラッシュすることを防止するための技法が望ましい。

例示的な実施形態には、システムが含まれる。本例では、システムは、プロセッサと、コンピュータ・システムが動作するときに当該プロセッサと通信するメモリとを備えるが、これらに限らない。本例では、メモリはコンピュータ可読命令を含むことができる。当該コンピュータ可読命令は、実行時にプロセッサに、３Ｄグラフィックを第１の３Ｄグラフィック演算装置で描画するための１群の仮想マシンを割り当てさせ、当該第１の３Ｄグラフィック演算装置がオーバコミットされていることを当該第１の３Ｄグラフィック演算装置がコマンドへの応答に要した時間に少なくとも基づいて判定させ、少なくとも当該第１の３Ｄグラフィック演算装置がオーバコミットされているとの判定に応答して、第１の仮想マシンを当該１群の仮想マシンから第２のグラフィック演算装置に移動させる。上記に加えて、他の技法も特許請求の範囲、発明を実施するための形態、および図面に記載されている。

別の例示的な実施形態には、コンピュータ可読記憶媒体が含まれる。本例では、コンピュータ可読記憶媒体はコンピュータ可読命令を含む。当該コンピュータ可読命令は、実行時にプロセッサに、３Ｄグラフィックを第１の仮想マシンに対して描画するために利用したグラフィック・メモリの量を推定させ、グラフィックを当該第１の３Ｄグラフィック演算装置で描画するために割り当てた１群の仮想マシンが発行したダイレクト・メモリ・アクセスのトランザクションに関連する待ち時間の値が第１の閾値未満であり、３Ｄグラフィックの描画に利用したグラフィック・メモリの推定量が第２の閾値未満であると判定したことに応答して、当該第１の３Ｄグラフィック演算装置を複数の３Ｄグラフィック演算装置から選択させ、３Ｄグラフィックを当該第１の３Ｄグラフィック演算装置で描画するように当該第１の仮想マシンを割り当てさせる。上記に加えて、他の技法も特許請求の範囲、発明を実施するための形態、および図面に記載されている。

別の例示的な実施形態には、方法が含まれる。本例では、当該方法は、少なくともグラフィックを仮想マシンに対して描画するために利用したグラフィック・メモリの量を推定すること、グラフィック・メモリの推定量を、複数の３Ｄグラフィック演算装置が制御する利用可能なグラフィック・メモリの推定量と比較すること、当該比較に従って、３Ｄグラフィックを仮想マシンに対して描画するための３Ｄグラフィック演算装置を複数の３Ｄグラフィック演算装置から選択すること、３Ｄグラフィックを仮想マシンに対して描画するために選択した３Ｄグラフィック演算装置を割り当てること、を含むがこれらに限らない。上記に加えて、他の技法も特許請求の範囲、発明を実施するための形態、および図面に記載されている。

本開示の１つまたは複数の様々な態様が、本明細書で引用した態様をもたらすための回路および／またはプログラミングを含みうるがこれらに限られず、当該回路および／またはプログラミングが事実上、システム設計者の設計上の選択に応じて本明細書で引用した態様をもたらすように構成された、ハードウェア、ソフトウェア、および／またはファームウェアの任意の組合せであることができることは当業者には理解されよう。

以上は要約であり、したがって当然、簡略化、一般化、および細部の省略が含まれている。本要約が例示的なものにすぎず、決して限定を意図するものではないことは当業者には理解されよう。

コンピュータ・システムの高レベルなブロック図である。 仮想マシン・サーバの高レベルなブロック図である。 仮想マシン・サーバの高レベルなブロック図である。 仮想デスクトップ・サーバの高レベルなブロック図である。 仮想デスクトップ・サーバの高レベルなブロック図である。 仮想デスクトップ・サーバの高レベルなブロック図である。 データセンタの高レベルなブロック図である。 仮想マシンの間でＧＰＵの使用を調整する動作手続を示す図である。 追加の動作を含む、図８の動作手続を示す図である。 仮想マシンの間でＧＰＵの使用を調整する動作手続を示す図である。 追加の動作を含む、図１０の動作手続を示す図である。 仮想マシンの間でＧＰＵを調整するための動作手続を示す図である。 追加の動作を含む、図１２の動作手続を示す図である。

本発明では、１つまたは複数のコンピュータ・システムを使用してもよい。図１および以下の議論は、本発明を実装できる適切なコンピューティング環境の簡潔で一般的な説明を提供しようとするものである。

本明細書で使用する回路という用語は、ハードウェア割込みコントローラ、ハード・ドライブ、ネットワーク・アダプタ、グラフィック・プロセッサ、ハードウェア・ベースのビデオ／オーディオ・コーデックのようなハードウェア・コンポーネント、およびかかるハードウェアを動作させるために用いるファームウェアを含むことができる。回路という用語はまた、マイクロ・プロセッサ、特定用途向け集積回路、およびプロセッサ、例えば、命令の読取と実行を行い、ファームウェアおよび／またはソフトウェアにより構成された、マルチコアの汎用演算装置のコアを含むことができる。プロセッサ（複数可）を、メモリ、例えば、ＲＡＭ、ＲＯＭ、ファームウェア、および／または大容量記憶からロードされる命令により構成して、機能（複数可）を実施するように当該プロセッサを構成するよう動作可能なロジックを具体化することができる。例示的な実施形態では、回路がハードウェアとソフトウェアの組合せを含む場合、実装者は、ハードウェアで実行できる機械可読なコードに後にコンパイルされるロジックを具体化する、ソース・コードを書き込むことができる。ハードウェア実装の機能とソフトウェア実装の機能には殆ど差異がないところまで最先端技術が発展していると当業者は理解できるので、本明細書で説明した機能を実現するためにハードウェアかソフトウェアのどちらを選択するかは設計上の選択にすぎない。換言すれば、ソフトウェア・プロセスを均等なハードウェア構造に変換でき、ハードウェア構造自体を均等なソフトウェア・プロセスに変換できると当業者は理解できるので、ハードウェア実装とソフトウェア実装のどちらを選択するかは実装者に委ねられている。

図１を参照すると、例示的なコンピュータ・システム１００が示されている。コンピュータ・システム１００は、プロセッサ１０２、例えば実行コアを含むことができる。１つのプロセッサ１０２を示しているが、他の実施形態ではコンピュータ・システム１００が複数のプロセッサ、例えば、プロセッサ基板ごとに複数の実行コアおよび／または各々が複数の実行コアを有しうる複数のプロセッサ基板を有してもよい。図で示すように、様々なコンピュータ可読記憶媒体１１０を、様々なシステム・コンポーネントをプロセッサ１０２に接続する１つまたは複数のシステム・バスにより相互接続することができる。システム・バスは数種のバス構造のうち任意のものであってもよい。当該バス構造には、メモリ・バスまたはメモリ・コントローラ、周辺バス、および様々なバス・アーキテクチャのうち任意のものを用いるローカル・バスが含まれる。例示的な実施形態では、コンピュータ可読記憶媒体１１０は、例えば、ＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）１０４、例えば電気機械ハード・ドライブ（ｅｌｅｃｔｒｏｍｅｃｈａｎｉｃａｌ ｈａｒｄ ｄｒｉｖｅ）、固体ハード・ドライブ、等のような記憶装置１０６、例えば、ＦＬＡＳＨ ＲＡＭまたはＲＯＭのようなファームウェア１０８、例えばＣＤ−ＲＯＭ、フロツピ・ディスク、ＤＶＤ、ＦＬＡＳＨドライブ、外部記憶装置、等のような取外し可能記憶装置１１８を含むことができる。磁気カセット、フラッシュ・メモリ・カード、および／またはデジタル・ビデオ・ディスクのような他種のコンピュータ可読記憶媒体を使用できることは当業者には理解されよう。

コンピュータ可読記憶媒体１１０は、プロセッサ実行可能命令１２２、データ構造、プログラム・モジュールおよび、実行可能命令のようなコンピュータ１１０に対する他のデータの、不揮発性記憶および揮発性記憶を提供することができる。ＢＩＯＳ（ｂａｓｉｃ ｉｎｐｕｔ／ｏｕｔｐｕｔ ｓｙｓｔｅｍ）１２０は、例えば起動時にコンピュータ・システム１００内部の要素間での情報転送を支援する基本ルーチンを含み、ファームウェア１０８に格納することができる。オペレーティング・システムおよび／またはアプリケーション・プログラムを含めて、幾つかのプログラムを、ファームウェア１０８、記憶装置１０６、ＲＡＭｌ０４、および／または取外し可能記憶装置１１８に格納してもよく、プロセッサ１０２により実行してもよい。

コマンドおよび情報をコンピュータ１００により入力装置１１６を介して受け取ってもよい。当該入力装置１１６には、キーボードおよびポインティング・デバイスを含めることができるがこれらに限らない。他の入力装置には、マイクロフォン、ジョイスティック、ゲーム・パッド、スキャナ、等を含めてもよい。これらおよび他の入力装置はしばしば、システム・バスに接続されるシリアル・ポート・インタフェースを介してプロセッサ１０２に接続されるが、パラレル・ポート、ゲーム・ポート、またはＵＳＢ（ｕｎｉｖｅｒｓａｌ ｓｅｒｉａｌ ｂｕｓ）のような他のインタフェースにより接続してもよい。ディスプレイまたは他種のディスプレイ装置も、グラフィック演算装置１１２の一部であるかまたはグラフィック演算装置１１２に接続できるビデオ・アダプタのようなインタフェースを介して、システム・バスに接続することができる。ディスプレイに加えて、コンピュータは一般に、スピーカおよびプリンタ（図示せず）のような他の周辺出力装置を備える。図１の例示的なシステムはまた、ホスト・アダプタ、ＳＣＳＩ（Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅ）バス、およびＳＣＳＩバスに接続された外部記憶装置を備えることができる。

コンピュータ・システム１００を、リモート・コンピュータのような１つまたは複数のリモート・コンピュータへの論理接続を用いてネットワーク環境で動作させてもよい。リモート・コンピュータは、別のコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア・デバイスまたは他の共通ネットワーク・ノードであってもよく、一般に、コンピュータ・システム１００に関して上述した要素の多くまたは全部を含むことができる。

ＬＡＮまたはＷＡＮのネットワーク環境で使用するとき、コンピュータ・システム１００をネットワーク・インタフェース・カード１１４を介してＬＡＮまたはＷＡＮに接続することができる。ＮＩＣｌ１４は、内部または外部にあってもよく、システム・バスに接続することができる。ネットワーク環境では、コンピュータ・システム１００に関して図示したプログラム・モジュール、またはその一部を、リモートのメモリ記憶装置に格納してもよい。ここで説明したネットワーク接続は例であって、コンピュータ間の通信リンクを確立する他の手段を使用してもよいことは理解されよう。さらに、本開示の多数の実施形態がコンピュータ化システムに特に良く適していると想定しているが、本明細書では何ら本開示をかかる実施形態に限定する意図はない。

図２を参照すると、仮想マシンの生成に使用できる例示的な仮想化プラットフォームが示されている。本実施形態では、ハイパバイザ・マイクロカーネル２０２を、コンピュータ・システム２００のハードウェアを制御し当該ハードウェアへのアクセスを調停するように構成することができる。ハイパバイザ・マイクロカーネル２０２は、子パーティション１乃至子パーティションＮ（Ｎは１より大きい整数）のような、パーティションと呼ばれる実行環境を生成することができる。ここで、子パーティションとは、ハイパバイザ・マイクロカーネル２０２によりサポートされる基本的な隔離単位である。ハイパバイザ・マイクロカーネル２０２は、或るパーティション内のプロセスを隔離して別のパーティションのリソースにアクセスしないようにすることができる。各子パーティションを、ハイパバイザ・マイクロカーネル２０２の制御下にある、例えばメモリ、デバイス、プロセッサ・サイクル、等のような１組のハードウェア・リソースにマップすることができる。１実施形態では、ハイパバイザ・マイクロカーネル２０２は、スタンド・アロンのソフトウェア製品、オペレーティング・システムの一部であることができ、マザーボードのファームウェア、特殊集積回路、またはそれらの組合せに組み込むことができる。

ハイパバイザ・マイクロカーネル２０２は、物理コンピュータ・システムにおけるゲスト・オペレーティング・システムのメモリのビューを制限することによって、パーティション化を強制することができる。ハイパバイザ・マイクロカーネル２０２が仮想マシンをインスタンス化すると、ハイパバイザ・マイクロカーネル２０２は、システム物理メモリ（ＳＰＭ）のページ、例えば、開始アドレスと終了アドレスを伴う固定長のメモリ・ブロックを、ゲスト物理メモリ（ＧＰＭ）のような仮想マシンに割り当てることができる。ここで、ゲストの制限されたシステム・メモリのビューがハイパバイザ・マイクロカーネル２０２により制御される。ゲスト物理メモリという用語は、仮想マシンの視点からメモリのページを記述する省略的な方法であり、システム物理メモリという用語は、物理システムの視点からメモリのページを記述する省略的な方法である。したがって、仮想マシンに割り当てたメモリのページには、ゲスト物理アドレス（仮想マシンが用いるアドレス）とシステム物理アドレス（ページの実アドレス）が存在することになる。

ゲスト・オペレーティング・システムが、ゲスト物理メモリを仮想化してもよい。仮想メモリは、オペレーティング・システムがメモリをオーバコミットできるようにし、アプリケーションが連続的な作業用メモリに単独でアクセスできるようにする、管理技法である。仮想化環境では、ゲスト・オペレーティング・システムが１つまたは複数のページ・テーブルを使用して、仮想ゲスト・アドレスとして知られる仮想アドレスをゲスト物理アドレスに変換することができる。本例では、メモリ・アドレスがゲスト仮想アドレス、ゲスト物理アドレス、およびシステム物理アドレスを有してもよい。

図示した例では、親パーティション・コンポーネントが、Ｘｅｎのオープン・ソースのハイパバイザのドメイン０に類似のものと考えることもでき、ホスト２０４を含むことができる。ホスト２０４はオペレーティング・システム（または１組の構成ユーティリティ）であることができ、ホスト２０４を、仮想化サービス・プロバイダ２２８（ＶＳＰ）を用いることにより子パーティション１乃至Ｎで実行されているゲスト・オペレーティング・システムにリソースを提供するように構成することができる。ＶＳＰ２２８は、オープン・ソースのコミュニティでは一般にバックエンド・ドライバと呼ばれ、仮想化サービス・クライアント（ＶＳＣ）（オープン・ソースのコミュニティでは一般にフロントエンド・ドライバと呼ばれ、または、準仮想化デバイスと呼ばれる）によりハードウェア・リソースに対するインタフェースを多重化するために使用することができる。図に示すように、仮想化サービス・クライアントはゲスト・オペレーティング・システムのコンテキスト内で実行される。しかし、これらのドライバは、それらにゲストではなくハイパバイザを提供できる点で、ゲスト内の残りのドライバとは異なる。例示的な実施形態では、仮想化サービス・クライアント２１６および２１８と通信するために仮想化サービス・プロバイダ２２８により使用されるパスを、仮想化パスと考えることができる。

図に示すように、エミュレータ２３４、例えば、仮想化ＩＤＥデバイス、仮想化ビデオ・アダプタ、仮想化ＮＩＣ、等を、ホスト２０４内部で実行するように構成することができ、それらはゲスト・オペレーティング・システム２２０および２２２に利用可能なリソースにアタッチされる。例えば、ゲストＯＳが、デバイスのレジスタが存在するはずの場所にマップされたメモリ・ロケーションまたはメモリ・マップされたデバイスにタッチすると、マイクロカーネル・ハイパバイザ２０２が当該要求をインターセプトして、ゲストが書き込もうとした値を関連するエミュレータに渡すことができる。ここで、本例でのリソースを、仮想デバイスが配置された場所と考えることができる。このようにエミュレータを使用することを、エミュレーション・パスと考えることができる。エミュレーション・パスは、仮想化パスと比較して非効率的である。なぜならば、当該エミュレーション・パスでは、デバイスをエミュレートするために、ＶＳＰとＶＳＣの間でメッセージを渡すよりも多くのＣＰＵリソースを必要とするからである。例えば、エミュレーション・パスを介して値をディスクに書き込むために利用されるレジスタにマップされる、メモリに対する何百ものアクションを、ＶＳＣからＶＳＰへ仮想化パスで渡される１つのメッセージに縮減することができる。

各子パーティションは１つまたは複数の仮想プロセッサ（２３０および２３２）を含むことができる。ゲスト・オペレーティング・システム（２２０および２２２）は、当該１つまたは複数の仮想プロセッサ（２３０および２３２）で実行されるスレッドを管理し、スケジュールすることができる。一般に、仮想プロセッサとは、物理プロセッサの表現に特定のアーキテクチャを与える、実行可能命令および関連する状態情報である。例えば、或る仮想マシンが、インテルｘ８６プロセッサの特徴を有する仮想プロセッサを有してもよく、別の仮想プロセッサがＰｏｗｅｒＰＣプロセッサの特徴を有してもよい。本例での仮想プロセッサを、仮想プロセッサを実現する命令がプロセッサにより支援されるように、コンピュータ・システムのプロセッサにマップすることができる。したがって、複数のプロセッサを含む実施形態では、仮想プロセッサをプロセッサにより同時に実行することができ、一方で、例えば、他のプロセッサがハイパバイザの命令を実行することができる。仮想プロセッサとパーティション内のメモリの組合せを、仮想マシンと考えることができる。

ゲスト・オペレーティング・システム（２２０および２２２）は、例えば、Ｍｉｃｒｏｓｏｆｔ（登録商標）、Ａｐｐｌｅ（登録商標）、オープン・ソースのコミュニティ、等からのオペレーティング・システムのような、任意のオペレーティング・システムであることができる。ゲスト・オペレーティング・システムは、ユーザ／カーネルの動作モードを含むことができ、スケジューラ、メモリ・マネージャ、等を含みうるカーネルを備えることができる。一般的に、カーネル・モードは、少なくとも特権プロセッサ命令へのアクセスを付与する、プロセッサ内の実行モードを含むことができる。各ゲスト・オペレーティング・システムは、ターミナル・サーバ、ｅコマース・サーバ、電子メール・サーバ、等のようなものに格納されたアプリケーション、およびゲスト・オペレーティング・システム自体を有しうる、関連するファイル・システムを有することができる。ゲスト・オペレーティング・システムは仮想プロセッサで実行するためのスレッドをスケジュールすることができ、かかるアプリケーションのインスタンスを実現することができる。

次に図３を参照すると、図２で上述したものに対する代替的な仮想化プラットフォームが示されている。図３は図２と同様なコンポーネントを示すが、この例示的な実施形態では、ハイパバイザ３０２は、マイクロカーネル・コンポーネントと、仮想化サービス・プロバイダ２２８およびデバイス・ドライバ２２４のような図２のホスト２０４におけるコンポーネントと類似したコンポーネントを備えることができ、管理オペレーティング・システム３０４が、例えば、ハイパバイザ３０２を構成するために使用される構成ユーティリティを含んでもよい。本アーキテクチャでは、ハイパバイザ３０２は図２のハイパバイザ・マイクロカーネル２０２と同一または類似の機能を実施できるが、本アーキテクチャでは、ハイパバイザ３０４を、子パーティション内で実行されるゲスト・オペレーティング・システムにリソースを提供するように構成することができる。図３のハイパバイザ３０２は、スタンド・アロンのソフトウェア製品、オペレーティング・システムの一部であることができ、マザーボードのファームウェアに組み込むことができ、または、ハイパバイザ３０２の一部を特殊集積回路により実現することができる。

次に図４を参照すると、仮想デスクトップ・サーバ４００の高レベルなブロック図が示されている。１実施形態では、仮想デスクトップ・サーバ４００を、仮想デスクトップ・セッション（ＶＤＳ）をクライアント、例えば、スマートフォンのようなモバイル装置、図１に示したコンポーネントと類似のコンポーネントを有するコンピュータ・システム、等に展開するように構成することができる。簡潔に述べると、仮想デスクトップ技術により、ユーザは仮想マシン内で実行されているゲスト・オペレーティング・システムとリモートに対話することができる。リモート・デスクトップ・セッションと異なり、仮想デスクトップ・セッションでは、１人のユーザのみがゲスト・オペレーティング・システムにログインし、ユーザはゲスト・オペレーティング・システムを完全に制御することができる。例えば、ユーザは管理者として実行し、ゲストに対して完全な権限を有する。図示した例では、仮想デスクトップ・サーバ４００は図２または図３のコンピュータ・システム２００または３００と類似したコンポーネントを有することができる。仮想化プラットフォーム４０２は、図２および図３で上述した仮想化インフラ・コンポーネントの論理的な抽象化である。下記のセクションで仮想化プラットフォーム４０２「内部」として説明する機能を、図２または図３に示した１つまたは複数の要素で実装することができる。例えば、３Ｄグラフィック・サービス・マネージャ４０４は、下記の段落でより詳細に説明されるが、これを図２のホスト２０４で実装することができる。より具体的な例では、３Ｄグラフィック・サービス・マネージャ４０４を、親パーティションで実行されているホスト・オペレーティング・システムで実装することができる。

仮想デスクトップ・セッションを開始するには、ゲスト・オペレーティング・システムを仮想マシン内部でインスタンス化する必要がある。例示的な実施形態では、仮想デスクトップ・マネージャ、例えば、プロセッサ実行可能命令のモジュールが要求に応答して（ゲスト・オペレーティング・システム４２８をブートできる）仮想マシン４１４を起動することができる。仮想デスクトップ・マネージャは、プロセッサで実行することができ、仮想化プラットフォーム４０２、例えばマイクロカーネル・ハイパバイザ２０２に指示してメモリをパーティションに割り当てることができる。仮想化プラットフォーム４０２は、仮想デバイスを仮想マシン４１４のメモリ内部で実行し構成することができ、ＶＭ４１４に割り当てたメモリにブート・ローダ・プログラムをロードすることができる。ブート・ローダ・プログラムは（次にプロセッサで実行できる）仮想プロセッサで実行することができ、ゲスト・オペレーティング・システム４２８を仮想マシン４１４内部にロードすることができる。セッション・マネージャ４０８をゲスト・オペレーティング・システム４２８によりロードすることができ、セッション・マネージャ４０８は、オペレーティング・システム・コア４１０のようなカーネル・モード部分を含みうるランタイム・サブシステム４２６のような環境サブシステムをロードすることができる。１実施形態における環境サブシステムを、サービスのサブセットをアプリケーション・プログラムに公開し、アクセス・ポイントをカーネル４２０に提供するように構成することができる。ゲスト・オペレーティング・システム４２８がロードされると、ブート・ローダ・プログラムは終了し、仮想マシン４１４の制御をゲスト・オペレーティング・システム４２８に引き渡す。ゲスト・オペレーティング・システム４２８は、図４に示した様々なモジュールを実行することができ、仮想デスクトップ・セッションをホストするように自分自身を構成することができる。例えば、ゲスト・オペレーティング・システム４２８は、リモート・プレゼンテーション・エンジン４０６、セッション・マネージャ４０８、等にブート時に起動させる、レジストリ値を含むことができる。

ゲスト・オペレーティング・システム４２８の実行を開始した後の何らかの時点で、ゲスト・オペレーティング・システム４２８はクライアントから接続要求を受信することができる。受信する接続要求を最初にリモート・プレゼンテーション・エンジン４０６により処理することができ、リモート・プレゼンテーション・エンジン４０６を、接続メッセージをリッスンするように構成することができる。接続メッセージが受け取られると、リモート・プレゼンテーション・エンジン４０６はスタック・インスタンスを生成することができる。リモート・プレゼンテーション・エンジン４０６は、当該セッションに対するプロトコル・スタック・インスタンスを実行することができ、（下記の段落でより詳細に説明する）仮想化プラットフォーム４０２により描画される３Ｄグラフィック・ユーザ・インタフェースをリモート・ディスプレイ・サブシステム４１８により受信して、上記プロトコル・スタック・インスタンスを介してクライアントに送信することができる。一般に、ユーザ・インタフェースの出力を関連するクライアントに転送し、当該関連するクライアントから受信したユーザ入力をオペレーティング・システム・コア４１０に転送するように、プロトコル・スタック・インスタンスを構成することができる。簡潔に述べると、オペレーティング・システム・コア４１０を、スクリーン出力を管理し、キーボード、マウス、および他のデバイスからの入力を収集するように構成することができる。

ユーザの資格情報、例えばユーザ名／パスワードの組合せを、リモート・プレゼンテーション・エンジン４０６により受け取って、セッション・マネージャ４０８に渡すことができる。セッション・マネージャ４０８は当該資格情報をログオン手続に渡すことができる。当該ログオン手続は、当該資格情報を認証サブシステム４２４に転送して検証することができる。認証サブシステム４２４は、ユーザの資格情報が妥当であり仮想デスクトップ・セッションを開始できること、即ち、ユーザがゲスト・オペレーティング・システム４２８にログインできることを判定することができる。

認証サブシステム４２４はまた、システム・トークンを生成することができる。ユーザがプロセスまたはスレッドを実行するためのセキュリティ証明書を有しているか否かを判定するためのプロセスの実行を当該ユーザが試みるときはいつでも、当該システム・トークンを使用することができる。例えば、プロセスまたはスレッドがアクセスの取得、例えばオブジェクト、例えばファイル、設定、またはアプリケーションのオープン、クローズ、削除、および／または修正を試みるとき、当該スレッドまたはプロセスをセキュリティ・サブシステム４２２により認証することができる。セキュリティ・サブシステム４２２は、上記オブジェクトに関連付けられたアクセス・コントロール・リストに対してセキュリティ・トークンをチェックし、システム・トークン内の情報とアクセス・コントロール・リストの比較に基づいてスレッドがパーミッションを有するか否かを判定することができる。スレッドが認証されたとセキュリティ・サブシステム４２２が判定する場合は、スレッドが上記オブジェクトにアクセスすることを許可することができる。

図４の説明を続けると、１実施形態では、オペレーティング・システム・コア４１０がグラフィック・ディスプレイ・インタフェース（ＧＤＩ）４１６および入力サブシステム４１２を備えることができる。例示的な実施形態では、入力サブシステム４１２を、仮想デスクトップ・セッション向けのプロトコル・スタック・インスタンスを介してユーザ入力をクライアントから受け取り、当該入力をオペレーティング・システム・コア４１０に送信するように構成することができる。幾つかの実施形態では、ユーザ入力が、絶対的および／または相対的なマウス移動コマンド、マウス座標、マウス・クリック、キーボード信号、ジョイスティック移動信号、等を示す信号を含むことができる。ユーザ入力、例えば、アイコンに対するマウスのダブルクリック、をオペレーティング・システム・コア４１０により受信することができ、当該ダブルクリックに関連付けられた座標にアイコンが配置されていると判定するように入力サブシステム４１２を構成することができる。次いで、入力サブシステム４１２を、アイコンに関連付けられたアプリケーションに関するプロセスを実行できるランタイム・サブシステム４２６に通知を送信するように構成することができる。

図５を参照すると、仮想マシン（４１４、４１４Ｂ、および／または４１４Ｃ）に対して３Ｄグラフィックを描画し、３Ｄ ＧＰＵ５０４、５０４Ｂ、および／または５０４Ｃのようなグラフィック演算装置に関して仮想マシンの負荷分散を行うように仮想デスクトップ・サーバ４００を構成するために使用できる、追加のコンポーネントが示されている。この図示した実施形態では、仮想デスクトップ・サーバ４００は、三次元グラフィカル・ユーザ・インタフェースを示すイメージを、クライアント５２０、５２０Ｂ、および／または５２０Ｃのようなクライアントにストリーミングすることができる。簡潔に述べると、各クライアントに、仮想デスクトップ・セッションを実行するように構成したゲスト・オペレーティング・システムを実行する仮想マシン（４１４、４１４Ｂ、または４１４Ｃ）を関連付けることができる。クライアント５２０、５２０Ｂ、および／または５２０Ｃは、図１に示したコンポーネントと類似するコンポーネント、モバイル装置、および／またはシン・クライアントを有するコンピュータ・システムを備えることができる。例えば、シン・クライアントが、汎用的なハードウェアおよび、当該ハードウェア、ユーザ入力および出力を管理しインターネットに接続するように構成されたモノリシックなウェブ・ブラウザを有してもよい。本例では、シン・クライアントがユーザ・インタフェース５２２、例えばディスプレイ、およびマウスのようなユーザ入力装置を備えてもよい。

仮想デスクトップ・サーバ４００を、起動時に３Ｄグラフィックを描画するように構成することができる。例えば、仮想デスクトップ・サーバ４００を実行するとき、３Ｄグラフィック・サービス・マネージャ４０４のような３Ｄグラフィック・サービス・マネージャのインスタンスを開始することができる。３Ｄグラフィック・サービス・マネージャ４０４は、下記の段落でより詳細に説明するが、プロセッサで実行することができ、受信する仮想デスクトップ・セッション接続を待機することができる。簡潔に述べると、３Ｄグラフィック・サービス・マネージャ４０４を、どこに各仮想マシンを割り当てるかを判定し、性能情報に基づいて仮想マシンを移動させることによって、グラフィック演算装置に関して仮想マシンの負荷分散を行うように構成することができる。

仮想マシンに対する３Ｄサービスを開始する要求を受信する前に、３Ｄグラフィック・サービス・マネージャ４０４を、システム内の各グラフィック演算装置に問い合わせてその機能を特定し、その機能を示す情報をテーブルに格納するように構成することができる。後に機能情報を使用して、グラフィック演算装置の使用を調整することができる。例示的な実施形態では、グラフィック演算装置の機能は、サーフェイス・テクスチャの共有をサポートするかまたは最小バージョンの３ＤグラフィックＡＰＩ（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍ ｉｎｔｅｒｆａｃｅ）をサポートする能力のような、１組の機能、即ち、ハードウェア機能を含むことができる。さらに、グラフィック演算装置の機能が、グラフィック演算装置のハードウェア識別子、プロパティのリスト、および３Ｄグラフィック演算装置が制御するグラフィックＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、即ち、３Ｄグラフィック演算装置を収容するアダプタに埋め込んだメモリの量、を含むことができる。例えば、グラフィック・ランダム・アクセス・メモリを使用して、スクリーン・イメージのビットマップ、（３Ｄグラフィックの深度座標を管理する）Ｚバッファ、テクスチャ、頂点バッファ、およびコンパイルされたシェーダ・プログラムを格納することができる。例示的な実施形態では、グラフィック・メモリは、ビデオＲＡＭ、ダイナミック・ランダム・アクセス・メモリ、または、ＤＤＲ（ｄｏｕｂｌｅ ｄａｔａ ｒａｔｅ）２、およびグラフィックＤＤＲ（ＧＤＤＲ３、ＧＤＤＲ４、および／またはＧＤＤＲ５）といったＤＤＲ技術を基礎とするランダム・アクセス・メモリのような、高速のまたはマルチポートのメモリであることができる。

仮想デスクトップ・セッション接続を受け取ったときに３Ｄグラフィック・サービス・マネージャ４０４に通知することができ、３Ｄグラフィック・サービス・マネージャ４０４は、（下記の段落でより詳細に説明する）グラフィック描画モジュールのインスタンスを開始し、３Ｄコンポーネントをゲスト・オペレーティング・システム４２８にロードするための信号を３Ｄ−ＧＰＵサービス・プロバイダ５１２に送信することができる。簡潔に述べると、３Ｄグラフィック・サービス・マネージャ４０４は、仮想マシンごとにグラフィック描画モジュールのインスタンスをロードし、グラフィック描画モジュールをどのＧＰＵで実行するかを判定し、グラフィック描画モジュールに判定されたグラフィック演算装置のデバイス識別子を渡すことができる。グラフィック描画モジュールは次いで、３Ｄ ＧＰＵにバインドし、その関連する仮想マシンの代わりに３Ｄ ＧＰＵに対して描画することができる。図示した例では、グラフィック描画モジュール５０６は仮想マシン４１４に対応する。仮想マシン４１４に対してグラフィカル・ユーザ・インタフェースを生成するために用いる頂点データ、テクスチャ、等を、仮想マシン４１４からグラフィック描画モジュール５０６に入力することができる。これは、仮想化プラットフォーム４０２によって、グラフィカル・ユーザ・インタフェースを生成するプロセスとして扱われる。大抵の３Ｄグラフィック演算装置は、数個のプロセスに対して数個のグラフィカル・ユーザ・インタフェースを一度に同時に生成するように設計されているので、多数のグラフィック描画モジュールが実行されているインスタンスでは、ＧＰＵが容易に過負荷となりリセットされうることは、当業者には理解されよう。

初期化手続を続けると、３Ｄ−ＧＰＵサービス・プロバイダ５１２は、３Ｄグラフィック・サービス・クライアント５１４をゲスト・オペレーティング・システム４２８内で生成させることができる。例えば、仮想マシン４１４内の仮想マザーボードのメモリ・アドレスにより、ＩＯデバイスにマップされる特定のアドレスにインターセプトを設定することができる。ゲスト・オペレーティング・システム４２８が開始すると、プラグインプレイ・モジュールを実行し、当該プラグインプレイ・モジュールがＩＯにマップされたメモリ・アドレスを問い合わせることができる。ハイパバイザ、例えば図２のハイパバイザ２０２は、当該読出しをインターセプトして、プラグインプレイ・モジュールに３Ｄグラフィック・サービス・クライアント５１４をロードさせるデバイス識別子で応答することができる。３Ｄグラフィック・サービス・クライアント５１４は、１つまたは複数のメモリ・ページを共有としてマップすることで３Ｄ−ＧＰＵサービス・プロバイダ５１２に対する通信チャネルを構成し、当該マップを３Ｄ−ＧＰＵサービス・プロバイダ５１２に渡すことができる。当該メモリ・ページ内部に、メッセージ・パッシング通信チャネル５１６を確立することができる。原則として、メッセージ・パッシング通信チャネル５１６は、３Ｄ ＧＰＵサービス・プロバイダ／クライアントがメッセージを読書きできる共有メモリ領域である。

３Ｄグラフィック・サービス・クライアント５１４はまた、仮想デバイス・ドライバ５１８を生成させることができる。仮想デバイス・ドライバ５１８はまた、仮想マシン４１４と仮想化プラットフォーム４０２の間で共有されるグラフィック・アパーチャ５２６を確立することができる。例示的な実施形態では、仮想デバイス・ドライバ５１８は、１群のゲスト・メモリ・ページを割り当て、接続要求とメモリ・ページのアドレスを含む信号を３Ｄグラフィック・サービス・クライアント５１４に送信することができる。グラフィック描画モジュール５０６は、当該接続要求と当該メモリ・ページのアドレスを受信することができる。グラフィック描画モジュール５０６は、ハイパバイザに当該１群のメモリ・ページ内にグラフィック・アパーチャ５２６を生成するように指示する信号をハイパバイザに送信することができる。ハイパバイザは当該ページをシステムの物理アドレスにマップし、当該メモリの範囲内部にあるグラフィック・アパーチャ５２６を実行することができる。本例では、仮想デバイス・ドライバ５１８を、ＤＭＡバッファをゲスト・メモリ・アドレスの範囲に書き込むように構成することができる。データがゲスト・メモリ・アドレスの範囲に書き込まれると、グラフィック・アパーチャ５２６がＤＭＡバッファをグラフィック描画モジュール５０６に転送する。

例示的な実施形態では、仮想デバイス・ドライバ５１８は、ゲスト・オペレーティング・システム４２８には３Ｄ可能なグラフィック演算装置のデバイス・ドライバとして表すことで、例えばＡＰＩ（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍ ｉｎｔｅｒｆａｃｅ）５２４のインスタンスをロードすることによって、ゲスト・オペレーティング・システム４２８が３Ｄグラフィックをサポートするように自分自身を構成することができる。仮想デバイス・ドライバ５１８を、ＡＰＩ５２４とインタフェースするように構成することができる。ＡＰＩ５２４により、３Ｄアプリケーション５２８は３Ｄグラフィックを生成することができる。３Ｄアプリケーション５２８、例えば、オペレーティング・システムのグラフィカル・ユーザ・インタフェース、アプリケーション／ビデオゲームに対するユーザ・インタフェース、等はＡＰＩ５２４に命令を発行することができる。ＡＰＩ５２４はＭｉｃｒｏｓｏｆｔ（登録商標）のＤｉｒｅｃｔＸのようなＡＰＩであることができる。簡潔に述べると、３ＤグラフィックＡＰＩ５２４は、グラフィック・アプリケーション、例えば、ビデオゲームと、ドライバ（この場合、仮想デバイス・ドライバ５１８）との間の抽象化層を提供する。一方では、ＡＰＩ５２４は仮想デバイス・ドライバ５１８が公開するグラフィック演算装置のインタフェースに低レベルのインタフェースを提供し、他方では、アプリケーションによって呼び出せる３Ｄグラフィック・コマンドのライブラリを提供する。ＡＰＩ５２４は、３Ｄグラフィック・コマンドのライブラリを、仮想デバイス・ドライバ５１８が公開するインタフェースにマップすることができ、したがって、ゲーム開発者が全てのグラフィック・ドライバの詳細を理解しなくてもよいようにすることができる。

動作に際して、ＡＰＩ５２４はプリミティブ、例えば頂点と定数で表現された他の形状に対するビルディング・ブロックとしてコンピュータ・グラフィックにおいて用いられる基本的な幾何学形状を生成することができ、当該頂点を複数のＤＭＡ（ｄｉｒｅｃｔ ｍｅｍｏｒｙ ａｃｃｅｓｓ）バッファに格納することができる。ＡＰＩ５２４がバッファに書き込むと、仮想デバイス・ドライバ５１８はＤＭＡバッファに格納されたデータを再フォーマットし、それらを１つまたは複数のＧＰＵトークンにパッケージ化し、グラフィック・アパーチャ５２６を介して当該ＧＰＵトークンをグラフィック描画モジュール５０６に送信することができる。同様に、ＡＰＩ５２４がコマンドを発行すると、ＡＰＩ５２４をＤＭＡバッファに挿入し、ＡＰＩ５２４をトークンでグラフィック描画モジュール５０６に転送することができる。

グラフィック描画モジュール５０６は当該トークンを受け取り、ＤＭＡバッファを抽出し、当該トークンを、仮想化プラットフォーム４０２に関連付けられたメモリのページに格納することができる。例示的な実施形態では、グラフィック描画モジュール５０６が、ＤＭＡバッファ内のコマンドとプリミティブを、３Ｄグラフィック・ドライバ５１０が処理できるＡＰＩコンストラクトに変換し、当該コマンドを、仮想化プラットフォーム４０２内のＤＭＡバッファのアドレスとともに、グラフィック・カーネル５０８に発行することができる。

グラフィック・カーネル５０８は、仮想デスクトップ・サーバ４００内部のグラフィック演算装置での実行をスケジュールするように構成できるが、コマンドとＤＭＡバッファのアドレスを受け取って、当該コマンドをいつ３Ｄグラフィック・ドライバ５１０に発行するかを決定することができる。様々なＤＭＡバッファからのプリミティブを描画するとき、グラフィック・カーネル５０８は描画コマンドを３Ｄグラフィック・ドライバ５１０に送信することができる。３Ｄグラフィック・ドライバ５１０は、プロセッサで実行することができ、当該コマンドを実行してＤＭＡバッファ内のデータを処理するようにグラフィック演算装置５０４に指示することができる。

グラフィック演算装置５０４を実行し、グラフィック演算装置５０４が、メモリ内のイメージ・フレームを示すビットマップ、例えば画素値の配列を生成することができる。グラフィック描画モジュール５０６は、当該ビットマップを捕捉し、当該ビットマップを圧縮モジュールに渡し、次いでグラフィック・アパーチャ５２６を介してリモート・プレゼンテーション・エンジン４０６に渡すことができる。リモート・プレゼンテーション・エンジン４０６は当該ビットマップを、１つまたは複数の情報パケットを介してクライアント５２０に送信することができる。

幾つかの事例では、１つまたは複数のグラフィック描画モジュールにより送信されるデータ・ストリームにより、グラフィック演算装置をリセットさせることができる。例えば、グラフィック演算装置が過負荷となっている、即ちＧＰＵがあまりに多くのイメージを描画しなければならない場合では、グラフィック演算装置がタイムアウトする可能性があり、ＧＰＵはリセットされることになる。これにより、３Ｄグラフィック・ドライバ５１０がリセットされ、次いでグラフィック・カーネル５０８がこのＧＰＵへの接続をリセットすることとなり、当該ＧＰＵにバインドされた任意のグラフィック描画モジュールが終了することになる。

例示的な実施形態では、３Ｄグラフィック・サービス・マネージャ４０４を、仮想デスクトップ・サーバ４００内部のグラフィック演算装置に対する負荷を調整してリセットが発生する可能性を減らすように構成することができる。例えば、図６を参照すると、５つの仮想マシン（４１４乃至４１４Ｆ。ここで本例では、仮想マシン４１４を仮想マシン４１４Ａと考えることができる。）を含む仮想デスクトップ・サーバ４００の別の高レベルなブロック図が示されている。各仮想マシンは、仮想化プラットフォーム４０２で実行されている関連する描画プロセス（５０６乃至５０６Ｆ）を有することができる。図に示すように、各グラフィック描画モジュール（５０６乃至５０６Ｆ）を、グラフィック演算装置にバインド、例えばアタッチすることができる。例えば、仮想マシン４１４、４１４Ｄ、および４１４Ｅが３Ｄ ＧＰＵ５０４にバインドされ、仮想マシン４１４Ｂが３Ｄ ＧＰＵ５０４Ｂにバインドされ、仮想マシン４１４Ｃおよび４１４Ｆが３Ｄ ＧＰＵ５０４Ｃにバインドされる。３Ｄグラフィック・サービス・マネージャ４０４が各仮想マシンを実行中に移動することができ、示した例における点線は、仮想マシン４１４を３Ｄ ＧＰＵ５０４から３Ｄ ＧＰＵ５０４Ｂに移動する具体的な例を示している。

３Ｄグラフィック・サービス・マネージャ４０４を、ラウンドロビン・アルゴリズムおよび／または動的配置アルゴリズムを用いてＧＰＵを調整するように構成することができる。例えば、ラウンドロビン・アルゴリズムを用いて、グラフィック演算装置と、仮想マシンからグラフィックを描画するために当該グラフィック演算装置を割り当てるか否かを判定するための情報とを見つけることができる。グラフィック演算装置が過負荷であると当該情報が示す場合は、ラウンドロビン・アルゴリズムは次のＧＰＵを発見し、同一の動作を実行することができる。追加または代替として、３Ｄグラフィック・サービス・マネージャ４０４を、当該情報を使用してグラフィック演算装置を選択し、各グラフィックを逐次的に検査することなく仮想マシンから当該グラフィックを描画するように構成することができる。

例示的な実施形態では、仮想マシンをＧＰＵ、例えば３Ｄ ＧＰＵ５０４に割り当てるために用いる情報が、３Ｄグラフィック演算装置に利用可能なグラフィック・メモリの推定量を含むことができる。利用可能なグラフィック・メモリの推定量を使用して、ＧＰＵがタイムアウトして接続がリセットされるか否かを予測することができる。本例では、３Ｄグラフィック・サービス・マネージャ４０４を、利用可能なグラフィック・メモリの推定量を使用して閾値を設定するように構成することができる。３Ｄグラフィック・サービス・マネージャ４０４が仮想マシンの割当て要求を受信すると、３Ｄグラフィック・サービス・マネージャ４０４は、仮想マシンが使用を試みるグラフィック・メモリの量、または、少なくとも、仮想マシンに対して画像を適切に描画し、推定した量を閾値、例えばグラフィック演算装置に利用可能なグラフィック・メモリの推定量と比較し、仮想マシンが利用するグラフィック・メモリの推定量が閾値未満である場合にグラフィック描画プロセスをＧＰＵに割り当てるために使用するために必要な量を推定することができる。

具体的な例では、３Ｄグラフィック演算装置５０４が４ギガバイトのキャッシュを制御し、３Ｄグラフィック・サービス・マネージャ４０４が、仮想マシン４１４Ｅが１ギガバイトのメモリを使用すると推定し、ＧＰＵにより制御される利用可能なグラフィック・メモリの推定量に対して閾値が設定され、仮想マシン４１４が利用するグラフィック・メモリの推定量が１ギガバイトであり、仮想マシン４１４Ｄが利用するグラフィック・メモリの推定量が５１２メガバイトであると仮定する。本例では、３Ｄグラフィック・サービス・マネージャ４０４は、仮想マシン４１４Ｅに対して利用される推定量（１ギガバイト）を推定された利用可能な量（およそ２．５ギガバイト）と比較して、ＧＰＵが仮想マシンに対処できると判定することができる。３Ｄグラフィック・サービス・マネージャ４０４は仮想マシンをＧＰＵに割り当て、仮想マシン４１４Ｅに対して利用される推定量を差し引いて、ＧＰＵに対する推定された利用可能な量（およそ１．５ギガバイト）を取得して、当該値をテーブルに格納することができる。

例示的な実施形態では、閾値を、ＧＰＵが制御する利用可能なグラフィック・メモリの推定量に設定することができる。別の例示的な実施形態では、当該閾値を、グラフィック演算装置を長時間監視し、グラフィック演算装置がリセットしたときにどれくらい多くの利用可能なグラフィック・メモリが利用可能であると推定されるかを判定することによって設定することができる。例えば、グラフィック演算装置がリセットされる確率を、性能データから計算し、利用可能なグラフィック・メモリの推定量と関連付けることができる。例示的な実施形態では、利用可能なグラフィック・メモリの推定量を閾値として設定することができる。他の例示的な実施形態では、この利用可能なグラフィック・メモリの推定量にスカラ値を乗じて、拡大した利用可能なグラフィック・メモリの推定量を閾値として使用することができる。例えば、利用可能なグラフィック・メモリの推定量の８０％を閾値として設定することができる。

例示的な実施形態では、３Ｄグラフィック・サービス・マネージャ４０４は、仮想マシンが使用できるグラフィック・メモリの量を情報に基づいて推定することができる。当該情報には、画素の次元、色深度、仮想マシンに対するディスプレイの数、スループット、圧縮率、仮想マシンに対して描画されるサーフェスの推定量、頂点を生成するために必要なプリミティブを格納するために必要なメモリの量、頂点に適用されるテクスチャを格納するために必要なメモリ、選択されたアンチエイリアシング効果をオブジェクトに適用するために必要なメモリ、等が含まれるがこれらに限らない。３Ｄグラフィック・サービス・マネージャ４０４を、仮想マシンが開始しているとの指示を受け取ったことに応答して当該仮想マシンが使用することとなるグラフィック・メモリの量を推定するように構成することができる。本例では、利用されるグラフィック・メモリの量を推定するために使用される情報の一部または全部を仮想マシンに関連付けられた構成ファイルに格納することができる。別の実施形態では、仮想マシンが実行時に使用するグラフィック・メモリの推定量を、３Ｄグラフィック・サービス・マネージャ４０４によって監視し、使用することができ、後の仮想デスクトップ・セッション中に使用するために構成ファイルに格納することができる。

以上に加えて、例示的な実施形態では、他の情報を使用して仮想マシンを適切なＧＰＵに割り当てることができる。例えば、既にＧＰＵに割り当てた仮想マシンの数を使用して、ＧＰＵが過負荷であるか否かを予測することができる。ＧＰＵに割り当てた仮想マシンの数を長時間監視することができ、バインドした仮想マシンの数を、グラフィック演算装置がリセットされるときに記録することができる。図６を参照すると、３Ｄグラフィック・サービス・マネージャ４０４が値をテーブルに含めることができる。当該値は、３Ｄ ＧＰＵ５０４に３つの仮想マシンがアタッチされ、３Ｄ ＧＰＵ５０４Ｂに１つの仮想マシンがアタッチされ、３Ｄ ＧＰＵ５０４Ｃに２つの仮想マシンがアタッチされていることを反映する。３Ｄグラフィック演算装置のうち１つがリセットされた場合は、３Ｄグラフィック・サービス・マネージャ４０４は、３Ｄグラフィック演算装置がクラッシュしたときにどれだけ多くの仮想マシンがアタッチされていたかを当該テーブルから決定することができる。様々な種類のグラフィック演算装置がリセットされる確率を、長時間にわたって捕捉した性能データから計算し、アタッチされた仮想マシンの推定量に関連付けることができる。例示的な実施形態では、３Ｄグラフィック・サービス・マネージャ４０４がグラフィック・メモリの推定量を使用してＧＰＵを選択し、利用可能なグラフィック・メモリの推定量が、アタッチされた仮想マシンの数より高い重みを有することができる。

同一または別の例示的な実施形態では、仮想マシンをＧＰＵに割り当てるか否かを判定するために３Ｄグラフィック・サービス・マネージャ４０４が使用する情報が、グラフィック演算装置がコマンドに応答するために要する平均時間長、即ち待ち時間、を記述する情報を含むことができ、グラフィック演算装置にストレスがかかっているかどうかを判定するために使用することができる。１実施形態では、３Ｄグラフィック・サービス・マネージャ４０４が平均的な待ち時間をテーブルに格納でき、クラッシュの際に、３Ｄグラフィック・サービス・マネージャ４０４はコマンドの平均待ち時間を閾値と比較することができる。平均待ち時間が閾値未満である場合は、３Ｄグラフィック・サービス・マネージャ４０４を、仮想マシンをＧＰＵに割り当てるように構成することができる。

当該閾値を管理者等により設定することができ、当該閾値は、使用されるグラフィック演算装置に依存することができる。例示的な実施形態では、様々な種類のＧＰＵに、仮想マシンを、その数を増加させつつロードする実験を行うことができる。より多くの仮想マシンを追加する際、待ち時間を記録して、長時間にわたるリセット数を待ち時間が短いときの同一期間にわたるリセット数と比較することによって、リセットの確率を計算することができる。高確率のリセットに関する監視された待ち時間を使用して閾値を設定することができる。例示的な実施形態では、監視された待ち時間を閾値として設定することができる。他の例示的な実施形態では、監視された待ち時間にスカラ値を乗ずることができ、拡大した待ち時間を使用することができる。例えば、監視された待ち時間の８０％を閾値として使用することができる。

例示的な実施形態では、待ち時間を、グラフィック・カーネル５０８が確認応答（「ＡＣＫ」）を受信するまでコマンドをＧＰＵに発行する時間から測定することができる。各ＡＣＫを受信した後、グラフィック・カーネル５０８は、当該要求に関連付けられた待ち時間を３Ｄグラフィック・サービス・マネージャ４０４に送信することができる。３Ｄグラフィック・サービス・マネージャ４０４は、ＧＰＵに対する平均待ち時間を反映する値を、テーブルにおいて更新することができる。

別の例示的な実施形態では、待ち時間を、仮想デバイス・ドライバ５１８がダイレクト・メモリ・アクセスのトランザクションを開始したときから測定することができる。例えば、ＡＰＩ５２４がプリミティブをＤＭＡバッファに書き込んでもよく、当該プリミティブを仮想デバイス・ドライバ５１８により捕捉し、グラフィック描画モジュール５０６に送信することができる。ＡＰＩ５２４は最終的にコマンドを発行することができる。仮想デバイス・ドライバ５１８が当該コマンドを受信すると、仮想デバイス・ドライバ５１８はタイマを開始することができる。仮想デバイス・ドライバ５１８は当該コマンドをグラフィック描画モジュール５０６に送信することができ、グラフィック描画モジュール５０６が次いでコマンドをグラフィック・カーネル５０８に送信することができる。グラフィック・カーネル５０８は当該コマンドを３Ｄグラフィック・ドライバ５１０に送信することができ、３Ｄグラフィック・ドライバ５１０が、３Ｄグラフィック演算装置５０４にＤＭＡバッファ内のプリミティブを処理させることができる。３Ｄ ＧＰＵ５０４はＡＣＫを生成することができ、当該ＡＣＫを仮想デバイス・ドライバ５１８に戻し、仮想デバイス・ドライバ５１８がタイマを停止することができる。仮想デバイス・ドライバ５１８は次いで待ち時間を、メッセージ・パッシング通信チャネル５１６を介して３Ｄグラフィック・サービス・マネージャ４０４に送信することができる。３Ｄグラフィック・サービス・マネージャ４０４は、仮想マシンに対する平均待ち時間を反映する値を、テーブルにおいて更新することができる。

例えば、仮想デバイス・ドライバ５１８は、トランザクションの待ち時間を含むメッセージを３Ｄグラフィック・サービス・クライアント５１４に送信することができる。３Ｄ ＧＰＵサービス・プロバイダ５１２は、当該メッセージを受信し、当該メッセージを３Ｄグラフィック・サービス・マネージャ４０４に送信することができ、３Ｄグラフィック・サービス・マネージャ４０４がテーブルを更新することができる。本例では、トランザクションの待ち時間を使用して、仮想マシン４１４が発行するＤＭＡトランザクションの平均待ち時間を決定することができる。当該平均待ち時間は、３Ｄ ＧＰＵ５０４のリソースがオーバコミットされているか否かを反映する。

仮想マシンを生成した際に当該仮想マシンの負荷分散を行うことに加えて、例示的な実施形態では、３Ｄグラフィック・サービス・マネージャ４０４を、現在の状態に応答して、仮想マシンを或る３Ｄ ＧＰＵから別の３Ｄ ＧＰＵに（その関連するグラフィック描画モジュールを再バインドすることで）移動するように構成することができる。例えば、図６は、３Ｄ ＧＰＵ５０４から３Ｄ ＧＰＵ５０４Ｂへ移動されているグラフィック描画モジュール５０６を示す。この例示的な実施形態では、３Ｄグラフィック・サービス・マネージャ４０４を、コンテキスト・スイッチを行って仮想化プラットフォーム４０２を実行するとき、仮想マシンの開始要求を検出したとき、および／または所定の時間が経過し割込みが発生したとき、に実行することができる。

この例示的な実施形態では、３Ｄグラフィック・サービス・マネージャ４０４を、何れかのＧＰＵが過負荷となっているかどうか、例えばリセットの危険性があるかどうかを判定し、（移動動作により、ＧＰＵを過負荷にするリスクが減り、他のＧＰＵをリセットさせるリスクを受け入れ難いほどは増大させない場合には）仮想マシンを移動するように構成することができる。例えば、３Ｄグラフィック・サービス・マネージャ４０４を、各３Ｄ ＧＰＵにバインドされた仮想マシンの数、３Ｄ ＧＰＵごとに利用可能なグラフィック・メモリの量、各３Ｄ ＧＰＵにバインドされた各仮想マシンにより開始されたＤＭＡトランザクションの平均待ち時間、各グラフィック描画モジュールが３Ｄ ＧＰＵを使用する割合、各グラフィック描画モジュールに関連付けられたスループット、および／またはグラフィック・カーネル・コマンドの平均待ち時間、を決定するように構成することができる。３Ｄ ＧＰＵが過負荷であるとこの情報が示す場合には、３Ｄグラフィック・サービス・マネージャ４０４を、どの仮想マシンに最もストレスがかかっているかを示すように構成することができる。次いで３Ｄグラフィック・サービス・マネージャ４０４は、ストレスのかかった仮想マシンを別のグラフィック演算装置に割り当てることができる。この動作手続の割当て部分は、上述の割当てプロセスと同様である。

例示的な実施形態では、３Ｄグラフィック・サービス・マネージャ４０４は、移動コマンドを新たなＧＰＵのデバイス識別子とともにグラフィック描画モジュール、例えばグラフィック描画モジュール５０６に送信することによって、移動動作を開始することができる。本例では、グラフィック描画モジュール５０６が当該コマンドを受け取って、新たな識別子に関連付けられたＧＰＵ、例えば３Ｄ ＧＰＵ５０４Ｂを見つけることができる。本例では、グラフィック描画モジュールを、任意の内部バッファをコピーし、３Ｄ ＧＰＵ５０４Ｂにバインドし、３Ｄ ＧＰＵ５０４へのマッピングを取り外すように構成することができる。バインド動作を完了した後、グラフィック描画モジュールは、移動が発生したことを３Ｄグラフィック・サービス・マネージャ４０４に通知することができ、グラフィック・サービス・マネージャ４０４はそのテーブルを更新して、グラフィック描画モジュール５０６が３Ｄ ＧＰＵ５０４Ｂにアタッチされていることを反映することができる。

図７を参照すると、例示的な実施形態では、移動動作を使用して、仮想マシンを別の仮想デスクトップ・サーバ（４００Ｂ〜４００Ｄ）に移動することができる。当該図に示すように、各仮想デスクトップ・サーバ（４００〜４００Ｄ）は、１組の１つまたは複数のグラフィック演算装置（７０４〜７０４Ｄ）と３Ｄグラフィック・サービス・マネージャ（４０４〜４０４Ｄ）のインスタンスを備えることができる。また、データセンタ７００を制御するように構成できる管理システム７０２が示されている。管理システム７０２は、場合によっては、データセンタ７００内の全ての他の３Ｄグラフィック・サービス・マネージャ（４０４〜４０４Ｄ）を制御できる、（任意であると考えられることを示すために点線で示した）マスタ３Ｄグラフィック・サービス・マネージャ７０６を備えることができる。

各仮想マシンを特定する一意な情報を使用して移動動作を実現することができる。例えば、各仮想マシンを開始したとき、ＶＭが開始したサーバで実行されている３Ｄグラフィック・サービス・マネージャ、例えば３Ｄグラフィック・サービス・マネージャ４０４が、データセンタ７００内部の仮想マシンに対して一意な識別子を生成することができる。当該一意な識別子は、仮想マシンが描画を行っているグラフィック演算装置の種類、当該仮想マシンが使用するグラフィック・メモリの推定量、等を含むことができる。例示的な実施形態では、仮想マシン４１４にストレスがかかり適切なＧＰＵがサーバで利用できない場合には、３Ｄグラフィック・サービス・マネージャ４０４は当該一意な識別子をデータセンタ内部の各仮想デスクトップ・サーバに送信し、または場合によっては、管理システム７０２に送信することができる。

当該一意な識別子が各仮想デスクトップ・サーバに送信される例では、グラフィック・サービス・マネージャ（４０４〜４０４Ｄ）は、仮想マシンをグラフィック演算装置に割り当てることができるか否かを、前述の段落で説明した情報に基づいて判定することができる。グラフィック・サービス・マネージャ、例えばグラフィック・サービス・マネージャ４０４Ｃが、仮想マシン４１４を処理できると判定する場合には、仮想デスクトップ・サーバ４００を、仮想マシン４１４を仮想デスクトップ・サーバ４００Ｃに移動するように構成することができる。

上記一意な識別子がマスタ３Ｄグラフィック・サービス・マネージャ７０６に送信される例では、マスタ３Ｄグラフィック・サービス・マネージャ７０６を、データセンタ７００内部の各３Ｄグラフィック・サービス・マネージャ（４０４〜４０４Ｄ）から全ての性能情報を含むように構成することができ、マスタ３Ｄグラフィック・サービス・マネージャ７０６が、仮想マシンをデータセンタ７００内部の何れかのグラフィック演算装置に割り当てることができるか否かを前述の段落で説明した情報に基づいて判定することができる。

以下は、動作手続を示す一連の流れ図である。理解を容易にするため、当該流れ図は、最初の流れ図が、全体の「大局的な」観点からの実装を表し、それに続く流れ図が点線で示したさらなる追加および／または詳細を提供するように構成されている。さらに、点線で示した動作手続は任意と考えられることは当業者には理解されよう。

図８を参照すると、動作８００、８０２、８０４、および８０６を含む、仮想マシン間のグラフィック・プロセッサの使用を調整するための動作手続が示されている。動作８００は、動作手続の開始を示し、動作８０２は、３Ｄグラフィックを第１の３Ｄグラフィック演算装置で描画するための１群の仮想マシンを割り当てることを示す。例えば、図６を参照すると、例示的な実施形態では、３Ｄグラフィック・サービス・マネージャ４０４がグラフィック演算装置で描画するための１群の仮想マシン、例えば３Ｄグラフィックを３Ｄグラフィック演算装置５０４で描画するための仮想マシン４１４、仮想マシン４１４Ｄ、および仮想マシン４１４Ｅを割り当てることができる。この具体的な例では、各仮想マシン（４１４〜４１４Ｆ）に、例えば図２のホスト２０４内部の、アプリケーション・プログラム・インタフェースの呼出しを介して３Ｄグラフィック演算装置５０４にバインドできる、仮想プラットフォーム４０２で実行されるグラフィック描画モジュール（５０６、５０６Ｄ、および５０６Ｅ）を関連付けることができる。本例では、グラフィック描画モジュール（５０６、５０６Ｄ、および５０６Ｅ）を、コマンドを示すプリミティブおよびＡＰＩコンストラクトを含むＤＭＡバッファを収集し、場合によっては当該コマンドを３Ｄグラフィック・ドライバ５１０が処理できるコマンドに変換し、当該コマンドを、ＤＭＡバッファを含むメモリのページとともにグラフィック・カーネル５０８に発行するように構成することができる。

図８の説明を続けると、動作８０４は、当該第１の３Ｄグラフィック演算装置がコマンドの応答に要した時間に少なくとも基づいて、第１の３Ｄグラフィック演算装置がオーバコミットされていると判定することを示す。例えば、例示的な実施形態では、３Ｄグラフィック・サービス・マネージャ４０４をプロセッサ上で実行し、３Ｄグラフィック演算装置５０４がオーバコミットされている、例えば３Ｄグラフィック演算装置５０４が全てのその要求を処理するために十分なリソースを有さず、そのためにリセットすることができ、グラフィック描画モジュール（５０６、５０６Ｄ、および５０６Ｅ）が終了しうると、判定することができる。この具体的な例では、当該判定を、グラフィック演算装置、例えば３Ｄ ＧＰＵ５０４がグラフィック・カーネル５０８にＡＣＫで応答するために要した平均時間に少なくとも基づいて行うことができる。本例では、３Ｄグラフィック・サービス・マネージャ４０４が制御するテーブルを、ハードウェアがグラフィック・カーネルのコマンドに応答するために要した待ち時間で更新することができ、３Ｄ ＧＰＵ５０４に対して平均を計算することができる。当該平均を閾値の待ち時間の値と比較することができ、当該平均が当該閾値より大きい場合は、３Ｄグラフィック・サービス・マネージャ４０４を、３Ｄ ＧＰＵ５０４がオーバコミットされていると判定するように構成することができる。

図８の説明を続けると、動作８０６は、第１の３Ｄグラフィック演算装置がオーバコミットされているとの判定に少なくとも応答して、上記１群の仮想マシンから第１の仮想マシンを第２のグラフィック演算装置に移動することを示す。例えば、図６を再度参照すると、例示的な実施形態では、３Ｄグラフィック・サービス・マネージャ４０４を、第１の仮想マシン、例えば仮想マシン４１４を第２のグラフィック演算装置、例えば３Ｄ ＧＰＵ５０４Ｂに移動するように構成することができる。１例では、仮想マシン４１４を３Ｄ ＧＰＵ５０４Ｂに移動するには、グラフィック描画モジュール５０６を３Ｄ ＧＰＵ５０４から３Ｄ ＧＰＵ５０４Ｂに移動する必要がある。例えば、３Ｄグラフィック・サービス・マネージャ４０４は移動コマンドを３Ｄ ＧＰＵ５０４Ｂのデバイス識別子とともにグラフィック描画モジュール５０６に送信することができる。グラフィック描画モジュール５０６は当該コマンドを受信し、内部バッファをコピーし、３Ｄ ＧＰＵ５０４Ｂにバインドすることができる。バインド動作が完了した後、グラフィック描画モジュール５０６は３Ｄ ＧＰＵ５０４へのマッピングを取り外し、完了信号を３Ｄグラフィック・サービス・マネージャ４０４に送信することができる。３Ｄグラフィック・サービス・マネージャ４０４はテーブルを更新して、仮想マシン４１４が３Ｄ ＧＰＵ５０４Ｂにバインドされていることを反映することができる。先に進むと、グラフィック描画モジュール５０６は描画コマンドを３Ｄ ＧＰＵ５０４Ｂへ発行することができ、平均コマンド待ち時間を３Ｄグラフィック・サービス・マネージャ４０４により監視することができる。

次に図９を参照すると、追加の動作／改良９０８〜９１６を含む図８の動作手続が示されている。動作９０８は、第２のグラフィック演算装置が制御する利用可能なグラフィック・メモリの推定量が閾値より大きいと判定したことに応答して、第１の仮想マシンを第２のグラフィック演算装置に移動することを示す。例えば、図６を参照すると、例示的な実施形態では、３Ｄグラフィック・サービス・マネージャ４０４を、移動すべき３Ｄ ＧＰＵ５０４にバインドされる仮想マシン、例えば仮想マシン４１４を選択するように構成することができる。本例では、仮想マシン４１４を３Ｄ ＧＰＵ５０４Ｂに移動するとの判定を、３Ｄ ＧＰＵ５０４Ｂに利用可能なグラフィック・メモリの推定量が閾値より大きいとの判定に少なくとも基づいて行うことができる。当該判定が、仮想マシン４１４に対してグラフィックを描画するために利用されるグラフィック・メモリの推定量に基づくこともできる。この場合、３Ｄグラフィック・サービス・マネージャ４０４を、３Ｄ ＧＰＵ５０４が過負荷であるという判定と３Ｄ ＧＰＵ５０４Ｂが仮想マシン４１４を収容できるとの判定に応答して、仮想マシン４１４を移動するように構成することができる。

図９の説明を続けると、動作９１０は、第１の仮想マシンが開始したダイレクト・メモリ・アクセスのトランザクションの平均待ち時間に基づいて、第１の３Ｄグラフィック演算装置がオーバコミットされていることを判定することが示されている。本例では、３Ｄグラフィック・サービス・マネージャ４０４が仮想マシン４１４を移動させることができる。なぜならば、仮想マシン４１４に関連付けられたＤＭＡトランザクションの平均待ち時間が、例えば、３Ｄ ＧＰＵ５０４にバインドされた全ての他のグラフィック描画モジュール（５０６Ｄおよび５０６Ｅ）よりも大きいからである。本例では、３Ｄグラフィック・サービス・マネージャ４０４を、先ずグラフィック・カーネル５０８が発行するコマンドの平均待ち時間を決定し、次いで、ＤＭＡトランザクションの当該平均待ち時間を使用して、仮想マシン４１４が当該ＧＰＵに関連付けられた最も高負荷の仮想マシンであると判定するように、構成することができる。

動作９１２に移ると、第２のグラフィック演算装置に割り当てた第２の仮想マシンに対するダイレクト・メモリ・アクセスのトランザクションの平均待ち時間が閾値未満であると判定したことに応答して、第１の仮想マシンを移動することが示されている。例示的な実施形態では、３Ｄグラフィック・サービス・マネージャ４０４を、３Ｄ ＧＰＵ５０４Ｂにバインドされた１つまたは複数の仮想マシンに対するＤＭＡトランザクションの平均応答時間が閾値未満であると判定したことに応答して、仮想マシン４１４を３Ｄ ＧＰＵ５０４Ｂに移動すると判定するように構成することができる。例えば、３Ｄグラフィック・サービス・マネージャ４０４が、仮想マシン４１４Ｂに対するＤＭＡトランザクションの平均応答時間を含むテーブルをチェックすることができる。３Ｄグラフィック・サービス・マネージャ４０４は、当該平均待ち時間を閾値と比較して、当該平均待ち時間が閾値未満であると判定することができる。これは、仮想マシン４１４Ｂ内部の負荷が低いことを示し、３Ｄ ＧＰＵ５０４Ｂの負荷が低いことを推論的に示す。この場合、３Ｄグラフィック・サービス・マネージャ４０４を、本判定に少なくとも基づいてグラフィック描画モジュール５０６を移動するように構成することができる。

動作９１４を参照すると、第２のグラフィック演算装置に割り当てられた仮想マシンの数が閾値未満であると判定したことに応答して、第１の仮想マシンを移動することが示されている。例示的な実施形態では、３Ｄグラフィック・サービス・マネージャ４０４を、３Ｄ ＧＰＵ５０４Ｂにバインドされた仮想マシンの数が閾値数未満であると判定したことに応答して、仮想マシン４１４を３Ｄ ＧＰＵ５０４Ｂに移動すると判定するように構成することができる。本例では、３Ｄグラフィック・サービス・マネージャ４０４を、３Ｄ ＧＰＵ５０４Ｂに現在バインドされている仮想マシンの数（図示した例では１）を示す値をそのテーブルから読み出し、現在バインドされている仮想マシンの数が閾値数、即ち性能データおよび／または管理者の好みに基づく値より少ないように構成することができる。この場合、３Ｄグラフィック・サービス・マネージャ４０４を、少なくとも当該判定に基づいてグラフィック描画モジュール５０６を移動するように構成することができる。

動作９１６を参照すると、第１のグラフィック演算装置と第２のグラフィック演算装置の機能を決定することが示されている。例えば、１実施形態では、３Ｄグラフィック・サービス・マネージャ４０４を、コンピュータ・システム内の各３Ｄグラフィック演算装置の機能を決定するように構成することができる。例えば、以前の例を続けると、３Ｄグラフィック・サービス・マネージャ４０４を、３Ｄグラフィック演算装置５０４、５０４Ｂ、および５０４Ｃの機能を決定するように構成することができる。本例では、当該機能を使用して、グラフィック演算装置が仮想マシンに対する３Ｄグラフィックを処理できるかどうかを判定することができる。例えば、３Ｄグラフィック・サービス・マネージャ４０４を、グラフィック・カードが共有のサーフェスとテクスチャをサポートするかどうか、グラフィック・カードが例えば或るバージョンのＤｉｒｅｃｔＸ（登録商標）を少なくともサポートするかどうか、グラフィック演算装置に関連付けられたグラフィック・メモリの量、等をチェックするように構成することができる。本例では、当該情報を使用して、仮想マシン間のグラフィック演算装置の使用を調整するために使用できるテーブルを埋めることができる。

次に図１０を参照すると、動作１０００、１００２、１００４、１００６、および１００８を含む、仮想マシン間のグラフィック演算装置の使用を調整するための動作手続が示されている。動作１０００を参照すると、動作１０００で当該動作手続が開始し、動作１００２は、第１のグラフィック演算装置と第２のグラフィック演算装置の機能を受信することを示す。例えば、図５を参照すると、例示的な実施形態では、３Ｄグラフィック・サービス・マネージャ４０４を実行し、３Ｄグラフィック・サービス・マネージャ４０４が第１の仮想マシン、例えば仮想マシン４１４を３Ｄグラフィック演算装置、例えば３Ｄ ＧＰＵ５０４に割り当てる要求を受信することができる。本例では、当該要求は、クライアント５２０のようなクライアントが仮想デスクトップ・セッションを要求したことを示す信号であることができる。

図１０の説明を続けると、動作１００４は、第１の仮想マシンに対して３Ｄグラフィックを描画するために利用されるグラフィック・メモリの量を推定することを示す。例えば、１実施形態では、３Ｄグラフィック・サービス・マネージャ４０４が、仮想マシン４１４が３Ｄグラフィックを描画するために利用できるグラフィック・メモリの量、例えば、仮想マシンに対するグラフィックの適切な描画を少なくとも可能とするグラフィック・メモリの量を推定することができる。例えば、当該推定を、仮想マシン４１４に関連付けられた構成ファイルから取得した情報に基づいて行うことができる。当該情報は、例えば、最後に実行されていたときに仮想マシン４１４が使用したグラフィック・メモリの平均量を示す。別の例示的な実施形態では、仮想マシンに対してグラフィックを描画するために必要なグラフィック・メモリの推定量を、画像を表示するために必要なメモリの最小量を記述する情報から推定することができる。別の例示的な実施形態では、グラフィック・メモリの当該推定量が、プリミティブをキャッシュするために必要なメモリの推定量、等に基づくことができる。

動作１００６は、第１の３Ｄグラフィック演算装置でグラフィックを描画するように割り当てられた１群の仮想マシンが発行したダイレクト・メモリ・アクセスのトランザクションに関連付けられた待ち時間の値が第１の閾値未満であり、３Ｄグラフィックを描画するために利用されるグラフィック・メモリの推定量が第２の閾値未満であると判定したことに応答して、第１の３Ｄグラフィック演算装置を複数の３Ｄグラフィック演算装置から選択することを示す。例えば、３Ｄグラフィック・サービス・マネージャ４０４が、３Ｄ ＧＰＵ５０４にバインドされた仮想マシンごとのＤＭＡトランザクションの待ち時間の値を示す情報を格納することができる。例えば、仮想マシン４１４Ｄと４１４Ｅを、３Ｄグラフィック・サービス・マネージャ４０４が仮想マシン４１４を３Ｄ ＧＰＵに割り当てる要求を受け取ったときに３Ｄ ＧＰＵ５０４にバインドしてもよい。本例では、３Ｄグラフィック・サービス・マネージャ４０４が当該テーブルから待ち時間の値を取得し、当該待ち時間の値を閾値と比較することができる。本例では、３Ｄグラフィック・サービス・マネージャ４０４はまた、仮想マシン４１４に対して３Ｄグラフィックを描画するために利用されるグラフィック・メモリの推定量を閾値と比較することができる。仮想マシン４１４Ｄおよび４１４Ｅの平均待ち時間が閾値未満であり仮想マシン４１４に対して３Ｄグラフィックを描画するために利用されるグラフィック・メモリの推定量が第２の閾値未満である場合には、３Ｄグラフィック・サービス・マネージャ４０４は３Ｄ ＧＰＵ５０４を選択することができる。

例示的な実施形態では、第２の閾値、即ち、３Ｄグラフィックを描画するために利用されるグラフィック・メモリの推定量に関連付けられた閾値は、３Ｄ ＧＰＵ５０４が制御するグラフィック・メモリの総量、ならびに、仮想マシン４１４Ｄおよび４１４Ｅに対して３Ｄグラフィックを描画するために利用されるグラフィック・メモリの推定量に基づくことができる。例えば、仮想マシン４１４Ｄおよび４１４Ｅが開始したとき、３Ｄグラフィック・サービス・マネージャ４０４が、仮想マシン４１４Ｄおよび４１４Ｅに対して３Ｄグラフィックを描画するために利用されるグラフィック・メモリの推定量を計算し、その値をテーブルに格納しておくことができる。３Ｄグラフィック・サービス・マネージャ４０４が仮想マシン４１４Ｄおよび４１４Ｅの各々に対して３Ｄ ＧＰＵ５０４を選択したとき、３Ｄグラフィック・サービス・マネージャ４０４は、それに関連する、３Ｄグラフィックを描画するために利用されるグラフィック・メモリの推定量を、ＧＰＵ５０４が制御する利用可能なグラフィック・メモリの推定量から差し引き、その値をテーブルに格納しておくことができる。次にこの値を第２の闘値として使用することができ、または、当該第２の閾値が当該値に少なくとも部分的に基づくことができる。

動作１００８は、第１の３Ｄグラフィック演算装置で３Ｄグラフィックを描画するための第１の仮想マシンを割り当てることを示す。例えば、図６を再度参照すると、例示的な実施形態では、３Ｄグラフィック・サービス・マネージャ４０４を、グラフィック描画モジュール５０６をインスタンス化し、３Ｄグラフィック演算装置５０４にバインドするコマンドをグラフィック描画モジュール５０６に送信するように構成することができる。グラフィック描画モジュール５０６は、当該コマンドを受信して、３Ｄグラフィック演算装置５０４にバインドすることができる。グラフィック描画モジュール５０４が３Ｄグラフィック演算装置５０４にバインドし、通信チャネルが仮想マシン４１４とグラフィック描画モジュール５０６の間で確立された後、グラフィック描画モジュール５０６は頂点のＤＭＡバッファを受け取って、それらを３Ｄグラフィック演算装置５０４で描画することができる。

図１１を参照すると、追加の動作１１１０〜１１１８を含む図１１の動作手続が示されている。動作１１１０は、第１の仮想マシンに対して３Ｄグラフィックを描画するために利用されるグラフィック・メモリの量を、少なくとも、当該１群内の仮想マシンごとに画素の次元を特定する情報から推定することを示す。例えば、１実施形態では、仮想マシンごとに３Ｄグラフィックを描画するために利用されるグラフィック・メモリの量が、当該仮想マシンに関連付けられた画素の次元に基づくことができる。例えば、仮想マシンがインスタンス化されたとき、当該仮想マシンに対して望ましいディスプレイ解像度のような情報を含む構成ファイルを受信することができる。３Ｄグラフィック・サービス・マネージャ４０４は、当該情報を受け取って、当該情報を使用して当該仮想マシンに対して３Ｄグラフィックを描画するために利用されるグラフィック・メモリの量を推定することができる。

例えば、画素の次元は、モニタで表示できる各次元における相違なる画素の数を記述する。モニタは２次元の表面であるので、当該次元として２つの次元のみが使用される（高さと幅）。例示的な実施形態では、画素の次元に画素の深度を乗じて８で除すことができる。その結果、画像を所望のディスプレイ解像度で描画するために利用できるグラフィック・メモリの量が記述される。

図１１の説明を続けると、動作１１１２は、第１の仮想マシンに対して３Ｄグラフィックを描画するために利用されるグラフィック・メモリの量を、少なくとも、第１の３Ｄグラフィック演算装置が使用する圧縮率を特定する情報から推定することを示す。例えば、１実施形態では、圧縮率、即ち圧縮画像のサイズと未圧縮画像のサイズの間の割合を用いて、仮想マシンに対して画像を適切に描画するためにどれくらい多くのグラフィック・メモリを仮想マシンが使用するかを推定することができる。例えば、３Ｄグラフィック演算装置を、圧縮されたテクスチャを用いてそのサイズを減ずるように構成することができる。３Ｄグラフィック・サービス・マネージャ４０４がハードウェアに問い合わせると、３Ｄグラフィック・サービス・マネージャ４０４はテクスチャ圧縮が可能であるか否かおよびどの圧縮率が達成されるかを判定することができる。３Ｄグラフィック・サービス・マネージャ４０４はこの情報を使用して、仮想マシンが使用するグラフィック・メモリの量を推定することができる。

動作１１１４を参照すると、動作１１１４は、第１の仮想マシンに対して３Ｄグラフィックを描画するために利用されるグラフィック・メモリの量を、少なくとも、第１の仮想マシンに対して描画すべきサーフェスの推定数を特定する情報から推定することを示す。例えば、１実施形態では、仮想マシンが描画を試みるサーフェスの推定数を使用して、仮想マシンに対して３Ｄグラフィックを適切に描画するために仮想マシンが使用することとなるグラフィック・メモリの量を推定することができる。

動作１１１６を参照すると、動作１１１６は、グラフィック・カーネルが発行した少なくとも１つのコマンドの待ち時間が第３の閾値未満であると判定したことに応答して、第１の３Ｄグラフィック演算装置を複数の３Ｄグラフィック演算装置から選択することを示す。例えば、図６を参照すると、例示的な実施形態では、３Ｄグラフィック・サービス・マネージャ４０４をプロセッサで実行し、３Ｄグラフィック・サービス・マネージャ４０４は、少なくとも、グラフィック演算装置、例えば３Ｄ ＧＰＵ５０４が、グラフィック・カーネル５０８が発行した少なくとも１つのコマンドにＡＣＫで応答するために要した時間が閾値未満であると判定したことに応答して、３Ｄグラフィック演算装置５０４で描画するための仮想マシン４１４を割り当てることができる。本例では、３Ｄグラフィック・サービス・マネージャ４０４が制御するテーブルを、ハードウェアがグラフィック・カーネルのコマンドに応答するために要した待ち時間で更新することができ、例示的な実施形態では、当該待ち時間を使用でき、または、平均を３Ｄ ＧＰＵ５０４に対して計算することができる。当該平均を使用する例では、当該平均を閾値の待ち時間の値と比較し、当該平均が当該閾値より大きい場合は、３Ｄグラフィック・サービス・マネージャ４０４を、３Ｄ ＧＰＵ５０４がオーバコミットされていると判定するように構成することができる。

次に動作１１１８を参照すると、動作１１１８は、第１の３Ｄグラフィック演算装置に現在割り当てられている仮想マシンの数が第４の閾値未満であると判定したことに応答して、第１の３Ｄグラフィック演算装置を複数の３Ｄグラフィック演算装置から選択することを示す。３Ｄグラフィック・サービス・マネージャ４０４を、３Ｄグラフィック演算装置５０４にバインドされた仮想マシンの数が閾値数未満であると判定したことに応答して、仮想マシン４１４に対してグラフィックを描画するための３Ｄグラフィック演算装置５０４を選択すると判定するように構成することができる。本例では、３Ｄグラフィック・サービス・マネージャ４０４を、３Ｄグラフィック演算装置５０４に現在バインドされている仮想マシンの数（図示した例では２）を示す値をそのテーブルから読み出し、現在バインドされた仮想マシンの数が閾値数、即ち性能データおよび／または管理者の好みに基づく数未満であると判定するように構成することができる。

図１２を参照すると、図１２は、動作１２００、１２０２、１２０４、１２０６、および１２０８を含む動作手続を示す。動作１２００で当該動作手続が開始し、動作１２０２は、少なくとも、仮想マシンに対してグラフィックを描画するために利用されるグラフィック・メモリの量を推定することを示す。例えば、１実施形態では、３Ｄグラフィック・サービス・マネージャ４０４が、仮想マシン、例えば仮想マシン４１４がインスタンス化されているとの指示を受信することができ、３Ｄグラフィック・サービス・マネージャ４０４が動作手続を開始して、それを実行するためのグラフィック演算装置、例えば３Ｄグラフィック演算装置５０４を選択することができる。本例では、当該動作手続が、仮想マシン４１４に対してグラフィックを適切に描画するために使用されるグラフィック・メモリの量を推定することを含むことができる。例えば、グラフィック・メモリの推定量を、仮想マシンには実行時にどれだけメモリが集約的となるかを示すものとして使用することができる。

利用されるグラフィック・メモリの量を前述のように推定することを、画像を表示するために必要なメモリの最小量に基づいて行うことができる。別の例示的な実施形態では、グラフィック・メモリの推定量が、頂点を生成するために必要なプリミティブを格納するために必要なメモリの推定量、頂点に適用されるテクスチャ、頂点がどの色であるべきか、アンチエイリアス技法をオブジェクトに適用するためのメモリ、等に基づくことができる。１例では、この推定が静的である、即ち、期待される利用に基づいて管理者が設定することができ、または、この推定が動的であることができる。例えば、仮想マシン４１４が利用または利用を試みるグラフィック・メモリの量を、長時間にわたって、即ち、仮想デスクトップ・セッションにわたって監視することができ、当該推定値を用いて当該推定を改良することができる。

次に動作１２０４を参照すると、動作１２０４は、グラフィック・メモリの推定量を、複数の３Ｄグラフィック演算装置が制御する利用可能なグラフィック・メモリの推定量と比較することを示す。例えば、３Ｄグラフィック・サービス・マネージャ４０４を、仮想マシン４１４が利用するグラフィック・メモリの推定量を仮想デスクトップ・サーバ４００にアタッチされたグラフィック演算装置ごとに利用可能なグラフィック・メモリの推定量と比較するように構成することができる。本例では、３Ｄグラフィック・サービス・マネージャ４０４は、前もって、グラフィック演算装置を収容するグラフィック・カード内に統合されたグラフィック・メモリの量を取得し、当該情報をテーブルに格納しておくことができる。さらに、仮想マシンがグラフィック演算装置にバインドされる度に、３Ｄグラフィック・サービス・マネージャ４０４を、仮想マシンが使用するグラフィック・メモリの推定量を、合計値から差し引き、その値をテーブルに格納するように構成することができる。ここで、３Ｄグラフィック・サービス・マネージャ４０４は、仮想マシン４１４が必要とするグラフィック・メモリの推定量を、３Ｄ ＧＰＵ５０４、３Ｄ ＧＰＵ５０４Ｂ、および３Ｄ ＧＰＵ５０４Ｃで利用可能なグラフィック・メモリの推定量と比較することができる。

図１２の説明を続けると、動作１２０６は、当該比較に従って、仮想マシンに対して３Ｄグラフィックを描画するための３Ｄグラフィック演算装置を複数の３Ｄグラフィック演算装置から選択することを示す。例えば、３Ｄグラフィック・サービス・マネージャ４０４は、仮想マシンをバインドするＧＰＵ、例えば３Ｄ ＧＰＵ５０６を、少なくとも当該比較の結果に基づいて選択することができる。例えば、以前の例を続けると、３Ｄグラフィック・サービス・マネージャ４０４は、３Ｄ ＧＰＵ５０４が仮想マシン４１４をホストできることを、３Ｄ ＧＰＵ５０４が十分なグラフィック・メモリを有すると推定されるという事実に少なくとも部分的に基づいて判定することができる。次に動作１２０８を参照すると、動作１２０８は、仮想マシンに対して３Ｄグラフィックを描画するための選択された３Ｄグラフィック演算装置を割り当てることを示す。例えば、図６を再度参照すると、例示的な実施形態では、３Ｄグラフィック・サービス・マネージャ４０４を、グラフィック描画モジュール５０６をインスタンス化し、３Ｄグラフィック演算装置５０４にバインドするコマンドをグラフィック描画モジュール５０６に送信するように構成することができる。グラフィック描画モジュール５０６は、当該コマンドを受け取って、３Ｄグラフィック演算装置５０４にバインドすることができる。

図１３を参照すると、追加の動作１３１０〜１３２２を含む図１３の動作手続が示されている。動作１３１０は、少なくとも、仮想マシンが開始したダイレクト・メモリ・アクセスのグラフィック・トランザクションの平均待ち時間に基づいて、３Ｄグラフィック演算装置がオーバコミットされていることを判定したことに応答して、仮想マシンを第２のグラフィック演算装置に移動することを示す。例えば、図６を参照すると、例示的な実施形態では、３Ｄグラフィック・サービス・マネージャ４０４をプロセッサで実行し、３Ｄグラフィック・サービス・マネージャ４０４が、３Ｄグラフィック演算装置５０４がオーバコミットされている、例えば、３Ｄグラフィック演算装置５０４がその全ての要求に応える十分なリソースがなくリセットされ、グラフィック描画モジュール（５０６、６１２、および６１４）が終了することとなると判定することができる。この具体的な例では、当該判定は、仮想マシン４１４が開始したＤＭＡグラフィック・トランザクションの平均待ち時間に基づくことができる。本例では、仮想マシンの平均待ち時間を閾値と比較することができ、３Ｄグラフィック・サービス・マネージャ４０４を、３Ｄ ＧＰＵ５０４のリソースがオーバコミットされていることを少なくともこの情報に基づいて判定するように構成することができる。当該判定に応答して、３Ｄグラフィック・サービス・マネージャ４０４を、グラフィック描画モジュール５０６を３Ｄ ＧＰＵ５０４Ｂまたは５０４Ｃのような別のＧＰＵに移動するように構成することができる。

図１３の説明を続けると、動作１３１２は、グラフィック・カーネルが３Ｄグラフィック演算装置に発行したグラフィック・コマンドの平均待ち時間に少なくとも基づいて、３Ｄグラフィック演算装置がオーバコミットされていることを判定したことに応答して、仮想マシンを第２のグラフィック演算装置に移動することを示す。例えば、例示的な実施形態では、グラフィック・カーネル５０８がＡＣＫを受信する前にコマンドを発行するために要した平均時間の長さを記述する情報を使用して、３Ｄ ＧＰＵ５０４がオーバコミットされているかどうかを判定することができる。本例では、３Ｄグラフィック・サービス・マネージャ４０４が制御するテーブルを、グラフィック・カーネルのコマンドの待ち時間で更新することができ、平均を３Ｄ ＧＰＵ５０４に対して計算することができる。当該平均を閾値の待ち時間の値と比較し、当該平均が当該閾値より大きい場合は、３Ｄグラフィック・サービス・マネージャ４０４を、３Ｄ ＧＰＵ５０４がオーバコミットされていると判定するように構成することができる。当該判定に応答して、３Ｄグラフィック・サービス・マネージャ４０４を、グラフィック描画モジュール５０６を３Ｄ ＧＰＵ５０４Ｂまたは５０４Ｃのような別のＧＰＵに移動するように構成することができる。

動作１３１４を参照すると、選択された３Ｄグラフィック演算装置に現在割り当てられている仮想マシンの数が閾値未満であると判定することを示す。３Ｄグラフィック・サービス・マネージャ４０４を、３Ｄ ＧＰＵ５０４Ｂにバインドされた仮想マシンの数が閾値数未満であると判定したことに応答して仮想マシン４１４を３Ｄ ＧＰＵ５０４Ｂに移動すると決定するように構成することができる。本例では、３Ｄグラフィック・サービス・マネージャ４０４を、３Ｄ ＧＰＵ５０４Ｂに現在バインドされている仮想マシンの数（図示した例では１）を示す値をそのテーブルから読み出し、現在バインドされている仮想マシンの数が閾値数、即ち、性能データおよび／または管理者の好みに基づく数より少ないと判定するように構成することができる。この場合、３Ｄグラフィック・サービス・マネージャ４０４を、少なくとも当該判定に基づいてグラフィック描画モジュール５０６を移動するように構成することができる。

動作１３１６を参照すると、動作１３１６は、複数の３Ｄグラフィック演算装置における各３Ｄグラフィック演算装置のハードウェア機能を決定することを示す。例えば、１実施形態では、３Ｄグラフィック・サービス・マネージャ４０４を、コンピュータ・システム内の各３Ｄグラフィック演算装置の機能を決定するように構成することができる。例えば、以前の例を続けると、３Ｄグラフィック・サービス・マネージャ４０４を、３Ｄグラフィック演算装置５０４と３Ｄグラフィック演算装置Ｂ６１６の機能を決定するように構成することができる。本例では、当該機能を使用して、グラフィック演算装置が仮想マシンに対する３Ｄグラフィックを処理できるかどうかを判定することができる。例えば、３Ｄグラフィック・サービス・マネージャ４０４を、グラフィック・カードが共有のサーフェスとテクスチャをサポートするかどうか、グラフィック・カードが例えば或るバージョンのＤｉｒｅｃｔＸ（登録商標）を少なくともサポートするかどうか、グラフィック演算装置に関連付けられたグラフィック・メモリの量、等をチェックすると決定することができる。本例では、当該情報を使用して、仮想マシン間のグラフィック演算装置の使用を調整するために使用できる、３Ｄグラフィック・サービス・マネージャ４０４が制御するテーブルを埋めることができる。

動作１３１８を参照すると、動作１３１８は、仮想マシンに対して３Ｄグラフィックを描画するために利用されるグラフィック・メモリの量を、少なくとも、仮想マシンに対する画素の次元を特定する情報から推定することを示す。例えば、１実施形態では、仮想マシンごとにグラフィックを描画するために利用されるグラフィック・メモリの量が、当該仮想マシンに関連付けられた画素の次元に基づくことができる。例えば、仮想マシンがインスタンス化されたとき、当該仮想マシンに対する所望のディスプレイ解像度のような情報を含む構成ファイルを受信することができる。３Ｄグラフィック・サービス・マネージャ４０４は、当該情報を受け取って、当該情報を使用してこの仮想マシンに対して３Ｄグラフィックを描画するために利用されるグラフィック・メモリの量を推定することができる。

動作１３２０を参照すると、動作１３２０は、仮想マシンに対して３Ｄグラフィックを描画するために利用されるグラフィック・メモリの量を、少なくとも、選択された３Ｄグラフィック演算装置が使用する圧縮率を特定する情報から推定することを示す。例えば、１実施形態では、圧縮率、即ち圧縮画像のサイズと未圧縮画像のサイズの間の割合を用いて、仮想マシンに対して画像を適切に描画するためにどれくらい多くのグラフィック・メモリを仮想マシンが使用するかを推定することができる。例えば、第１の３Ｄグラフィック演算装置を、圧縮されたテクスチャを用いてそのサイズを減ずるように構成することができる。３Ｄグラフィック・サービス・マネージャ４０４がハードウェアに問い合わせると、３Ｄグラフィック・サービス・マネージャ４０４はテクスチャ圧縮が可能であるか否かおよびどの圧縮率が達成されるかを判定することができる。３Ｄグラフィック・サービス・マネージャ４０４はこの情報を使用して、仮想マシンが使用するグラフィック・メモリの量を推定することができる。

動作１３２２は、仮想マシンに対して３Ｄグラフィックを描画するために利用されるグラフィック・メモリの量を、少なくとも、当該仮想マシンに対して描画すべきサーフェスの推定数を特定する情報から推定することを示す。例えば、１実施形態では、仮想マシンが描画を試みるサーフェスの推定数を使用して、仮想マシンに対して３Ｄグラフィックを適切に描画するために仮想マシンが使用するグラフィック・メモリの量を推定することができる。例えば、サーフェスは、３Ｄグラフィック内のオブジェクトを表現する１つの方法であり、バッファに格納される。

以上の詳細な説明では、種々の例および／または動作図を通じてシステムおよび／またはプロセスの様々な実施形態を説明した。かかるブロック図および／または種々の例が１つまたは複数の機能および／または動作を含む限り、かかるブロック図または種々の例における各機能および／または動作を、個別におよび／または集合的に、広範囲のハードウェア、ソフトウェア、ファームウェア、または事実上それらの任意の組合せで実装できることは当業者には理解されよう。

本明細書に記載の本発明の特定の態様を図示および説明したが、本明細書の教示事項に基づいて、本明細書に記載の主題およびその広範囲の態様から逸脱しない変更および修正を行ってもよく、したがって添付の特許請求の範囲が、その範囲において、全てのかかる変更および修正を、それらが本明細書に記載の本発明の真の趣旨と範囲内にあるように包含するものであることは当業者には明らかであろう。

Claims (15)

1. 仮想マシン間でグラフィック・プロセッサの利用を調整するように構成されたコンピュータ・システムであって、
   プロセッサと、
   第１の３Ｄグラフィック演算装置と、
   第２の３Ｄグラフィック演算装置と、
   前記コンピュータ・システムが動作するときに少なくとも前記プロセッサと通信するメモリであって、前記メモリは、実行時に前記プロセッサに、
   第１の３Ｄグラフィック演算装置で３Ｄグラフィックを描画するための１群の仮想マシンを割り当てさせ、
   前記第１の３Ｄグラフィック演算装置がオーバコミットされていることを、少なくとも、前記第１の３Ｄグラフィック演算装置がコマンドに応答するために要する時間に基づいて判定させ、
   少なくとも前記第１の３Ｄグラフィック演算装置がオーバコミットされていると判定したことに応答して、第１の仮想マシンを前記１群の仮想マシンから第２のグラフィック演算装置に移動させる
   コンピュータ可読命令を格納する、メモリと、
   を備えたことを特徴とするコンピュータ・システム。
2. 実行時に前記プロセッサに前記第１の仮想マシンを前記第２のグラフィック演算装置に移動させる前記コンピュータ可読命令は、実行時に前記プロセッサに、前記第２のグラフィック演算装置が制御する利用可能なグラフィック・メモリの推定量が閾値より大きいと判定したことに応答して、前記第１の仮想マシンを前記第２のグラフィック演算装置に移動させるコンピュータ可読命令をさらに含むことを特徴とする請求項１に記載のコンピュータ・システム。
3. 実行時に前記プロセッサに前記第１の３Ｄグラフィック演算装置がオーバコミットされていると判定させる前記コンピュータ可読命令は、実行時に前記プロセッサに、前記第１の３Ｄグラフィック演算装置がオーバコミットされていると、前記第１の仮想マシンが開始したダイレクト・メモリ・アクセスのトランザクションの平均待ち時間に基づいて判定させるコンピュータ可読命令をさらに含むことを特徴とする請求項１に記載のコンピュータ・システム。
4. 実行時に前記プロセッサに前記第１の仮想マシンを前記第２のグラフィック演算装置に移動させる前記コンピュータ可読命令は、実行時に前記プロセッサに、前記第２のグラフィック演算装置に割り当てられた第２の仮想マシンに対するダイレクト・メモリ・アクセスのトランザクションの平均待ち時間が閾値未満であると判定したことに応答して、前記第１の仮想マシンを移動させるコンピュータ可読命令をさらに含むことを特徴とする請求項１に記載のコンピュータ・システム。
5. 実行時に前記プロセッサに前記第１の仮想マシンを前記第２のグラフィック演算装置に移動させる前記コンピュータ可読命令は、実行時に前記プロセッサに、前記第２のグラフィック演算装置に割り当てられる仮想マシンの数が閾値未満であると判定したことに応答して、前記第１の仮想マシンを移動させるコンピュータ可読命令をさらに含むことを特徴とする請求項１に記載のコンピュータ・システム。
6. 前記コンピュータ可読命令は、実行時に前記プロセッサに、前記第１のグラフィック演算装置および前記第２のグラフィック演算装置の機能を決定させるコンピュータ可読命令をさらに含むことを特徴とする請求項１に記載のコンピュータ・システム。
7. 仮想マシン間でグラフィック演算装置の利用を調整するためのコンピュータ可読命令を含むコンピュータ可読記憶媒体であって、前記コンピュータ可読記憶媒体は、実行時に前記プロセッサに、
   第１の仮想マシンを第１の３Ｄグラフィック演算装置に割り当てる要求を受信させ、
   前記第１の仮想マシンに対して３Ｄグラフィックを描画するために利用されるグラフィック・メモリの量を推定させ、
   前記第１のグラフィック演算装置でグラフィックを描画するために割り当てられた１群の仮想マシンが発行したダイレクト・メモリ・アクセスのトランザクションに関連付けられる待ち時間の値が第１の閾値未満であると判定したことと、３Ｄグラフィックを描画するために利用されるグラフィック・メモリの推定量が第２の閾値未満であると判定したこととに応答して、前記第１の３Ｄグラフィック演算装置を複数の３Ｄグラフィック演算装置から選択させ、
   前記第１の３Ｄグラフィック演算装置で３Ｄグラフィックを描画するための前記第１の仮想マシンを割り当てさせる
   命令を含むことを特徴とするコンピュータ可読記憶媒体。
8. 前記コンピュータ可読命令は、実行時に前記プロセッサに、前記第１の仮想マシンに対して３Ｄグラフィックを描画するために利用されるグラフィック・メモリの量を、少なくとも、前記１群内の仮想マシンごとの画素の次元を特定する情報から推定させることを特徴とする請求項７に記載のコンピュータ可読記憶媒体。
9. 前記コンピュータ可読命令は、実行時に前記プロセッサに、前記第１の仮想マシンに対して３Ｄグラフィックを描画するために利用されるグラフィック・メモリの量を、少なくとも、前記第１の３Ｄグラフィック演算装置が使用する圧縮率を特定する情報から推定させることを特徴とする請求項７に記載のコンピュータ可読記憶媒体。
10. 前記コンピュータ可読命令は、実行時に前記プロセッサに、前記第１の仮想マシンに対して３Ｄグラフィックを描画するために利用されるグラフィック・メモリの量を、少なくとも、前記第１の仮想マシンに対して描画するためのサーフェスの推定数を特定する情報から推定させることを特徴とする請求項７に記載のコンピュータ可読記憶媒体。
11. 実行時に前記プロセッサに前記第１の３Ｄグラフィック演算装置を選択させる前記コンピュータ可読命令は、実行時に前記プロセッサに、グラフィック・カーネルが発行した少なくとも１つのコマンドの待ち時間が第３の閾値未満であると判定したことに応答して、前記第１の３Ｄグラフィック演算装置を前記複数の３Ｄグラフィック演算装置から選択させるコンピュータ可読命令を含むことを特徴とする請求項７に記載のコンピュータ可読記憶媒体。
12. 実行時に前記プロセッサに前記第１の３Ｄグラフィック演算装置を選択させる前記コンピュータ可読命令は、実行時に前記プロセッサに、前記第１の３Ｄグラフィック演算装置に現在割り当てられている仮想マシンの数が第４の閾値未満であると判定したことに応答して、前記第１の３Ｄグラフィック演算装置を前記複数の３Ｄグラフィック演算装置から選択させるコンピュータ可読命令を含むことを特徴とする請求項７に記載のコンピュータ可読記憶媒体。
13. 前記コンピュータ可読命令は、実行時に前記プロセッサに、前記第１の３Ｄグラフィック演算装置がオーバコミットされていることを、少なくとも、前記第１の仮想マシンが開始したダイレクト・メモリ・アクセスのグラフィック・トランザクションの平均待ち時間に基づいて判定したことに応答して、前記第１の仮想マシンを第２のグラフィック演算装置に移動させることを特徴とする請求項７に記載のコンピュータ可読記憶媒体。
14. 前記コンピュータ可読命令は、実行時に前記プロセッサに、前記第１の３Ｄグラフィック演算装置がオーバコミットされていることを、少なくとも、グラフィック・カーネルが前記第１の３Ｄグラフィック演算装置に発行したグラフィック・コマンドの平均待ち時間に基づいて判定したことに応答して、前記第１の仮想マシンを第２のグラフィック演算装置に移動させることを特徴とする請求項７に記載のコンピュータ可読記憶媒体。
15. 前記コンピュータ可読命令は、実行時に前記プロセッサに、複数の３Ｄグラフィック演算装置内の各３Ｄグラフィック演算装置のハードウェア機能を決定させることを特徴とする請求項７に記載のコンピュータ可読記憶媒体。

Images